Mine is doing the same after the update. I have an NVidia GeForce RTX3080 but it also happens on my laptop with 4080. Seems like a game issue. There's no error, just shuts down to the desktop.
AMD RX 6000 series driver issues & workarounds
Not getting any crashes on my AMD RX 6000 cards, nor my NVIDIA RTX 3000 or 4000 cards. Don't have any RX 7000 series cards to test, but I'd be surprised if they had issues either.
Have you wiped the shader caches?
I see from EDDiscovery logs, that I have started getting more CTD:s after Update 17, and a lot more after update 17.01. They are similar to what @Zandhond says, a sudden freeze for a few seconds, and then the game closes without any error message. At the same time also the Radeon driver crashes and I get two crash reporting windows: One for AMD and another for Frontier. I have updated the driver twice since U17, always to the latest version, and always in offline, uninstalling the old version first.
I experimented with cosmetic changes to my ship, because the game crashes only when my ship is present. Changing paint job didn't seem to help, but removing all ship kit parts from my current ship, an Orca, clearly made the game more stable, but still after several hours of running, it crashed.
And how do I clear the driver shader cache? And does the shader cache clear when I unistall the GPU driver? I updated the driver just two days ago. Edit: I found the reset shader cache function in the driver software, on the page Gaming / Graphics. I have now done that.
My PC: Ryzen 9 5900X CPU, RX 7900XTX GPU, 850W PSU, 32GB RAM, Windows 10
I experimented with cosmetic changes to my ship, because the game crashes only when my ship is present. Changing paint job didn't seem to help, but removing all ship kit parts from my current ship, an Orca, clearly made the game more stable, but still after several hours of running, it crashed.
What effect to the game does the deleting of that file GPUWorkTable.xml have?
My PC: Ryzen 9 5900X CPU, RX 7900XTX GPU, 850W PSU, 32GB RAM, Windows 10
Last edited:
I have not done anything with the shader cache
I only get the crashes when flying close to planet surfaces. There's some hesitation and once I was flying in a crater and my ship reset itself to stationary, 5Km above the surface. I've played on this GPU for over 2 years, never had an issue before the last update. The laptop with the 4080 is only a few months old and doesn't see a lot of playing time. They both started doing the same things after the update. I'm flying a Dolphin with no ship kit, black paint.
Works for me so far as well. I now need to redo my hud colors though, bleh orange.
I have now done the reset shader cache function in the AMD driver software, and removed the file GPUWorkTable.xml from the ED Odyssey's main directory, if one can call it such. Then I continued playing the game. It crashed to desktop when I was approaching ground the first time, at about 300 m altitude, in slow horizontal flight. There was very noticeable stuttering a few times just before the game froze, when it was apparently loading terrain features. The Radeon driver crashed, too.
What does the error look like for that in event viewer?
In Windows Event Viewer it says, in a Warning class event, the following, which is my own translation:"The display adapter amduw23g stopped responding and recovered." Event id for that is 4101. The next event after that is similar with that. There is a 4 second delay between them.
Sounds like driver is taking too long to generate terrain data and/or populate it's shader cache for said data.
I would max out the terrain work slider in the graphics options, if you have not already. I would also try increasing the Windows TDR delay in the registry by navigating to "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\GraphicsDrivers" and setting the "TrdDelay" DWORD value to "8".
If neither of those resolves the issue, it may be an actual driver incompatibility, or a hardware problem.
I moved the terrain work slider to the right end, but that didn't make the game much more stable. It crashed after about 10 minutes of flying low over terrain, and again there was a display driver timeout.
I am not going to change that Windows registry key just yet, but if nothing else helps, maybe I'll change that.
These display driver timeouts seem to be common for owners of the RX 7900XTX GPU. I made a quick Google search about it, and it looks like it has started in July, and has spread to more users during the fall, like an epidemic. For example here is one report about it on AMD:s own forum. On the right side of that page there are links to more reports of the same issue. And here is a long description of the things someone tried, but without avail.
Last edited:
It's fairly common, as far as errors go, with almost any GPU because any time the GPU scheduler doesn't respond in two seconds it throws an equivalent error and a huge number of causes can be responsible for the driver failing to respond within the allotted time window. It's one of the most non-specific errors there is.
I tested the game again, this time with frame rate limited to 120 FPS. That didn't help to avoid a crash to desktop for long, but I will make that limit lower next time. After the game had closed, I looked more into the Windows logs. There was again the event saying "The display adapter amduw23q stopped responding and recovered".
Approximately 8 min 32 s before that event, there was a Windows log event related to Elite Dangerous, in the Application log, titled:"Event 1001, Windows Error Reporting", with the event name RADAR_PRE_LEAK_64. The following lines are included in this event, under a title, in my own translation, "Signature of the issue":
P1: EliteDangerous64.exe
P2: 298.704.0.0
P3: 10.0.19045.2.0.0
I found a Microsoft Community discussion about that event type. Apparently that event means that Elite Dangerous did not handle memory correctly. I wonder if this event was created due to a memory leak, which then a few minutes later slowed down the display driver?
Approximately 8 min 32 s before that event, there was a Windows log event related to Elite Dangerous, in the Application log, titled:"Event 1001, Windows Error Reporting", with the event name RADAR_PRE_LEAK_64. The following lines are included in this event, under a title, in my own translation, "Signature of the issue":
P1: EliteDangerous64.exe
P2: 298.704.0.0
P3: 10.0.19045.2.0.0
I found a Microsoft Community discussion about that event type. Apparently that event means that Elite Dangerous did not handle memory correctly. I wonder if this event was created due to a memory leak, which then a few minutes later slowed down the display driver?
Might be worth checking system memory and the GPU for stability issues. If it were a memory leak with the game or even the driver, I'd expect these crashes to be afflicting most everyone with a similar GPU.
It worked yesterday without a hitch. Today it crashed again, low flying on a planet in an unkitted Dolphin. This started after the last update, first time I played. I didn't think a lot of the first time but after a couple more it caught my attention. It's not super uncommon that I have to relog when I enter vista genomics (no cue for dialogue) or some other menu function in a station isn't working. Relog fixes it. This isn't that.
Last edited:
Back when I was using my Nvidia GTX 970 I had constant TDRs while playing Elite. Elite was the only program that would TDR the video drivers. When it happened, it was always while approaching a landable planet.
The "solution" was to underclock my card. Apparently, the factory OC was just unstable enough and Elite is (apparently) super sensitive to that instability.
I didn't like that the solution to my problem was "make my video card worse" so, ultimately, I just dealt with it for a while and accepted that if I was approaching a planet there was a good chance my game crashed.
Haven't had any issues after upgrading to the Radeon 6700 XT that I'm currently using (aside from the corrupted orbit lines).
The "solution" was to underclock my card. Apparently, the factory OC was just unstable enough and Elite is (apparently) super sensitive to that instability.
I didn't like that the solution to my problem was "make my video card worse" so, ultimately, I just dealt with it for a while and accepted that if I was approaching a planet there was a good chance my game crashed.
Haven't had any issues after upgrading to the Radeon 6700 XT that I'm currently using (aside from the corrupted orbit lines).
Elite: Dangerous is far more demanding than many assume. Indeed, since Path of Exile was patched, Elite: Dangerous (3.8 and 4.0) is the most power hungry and stressful title I know of, at least GPU wise.
I ran the stress test in the Radeon software, for ten minutes, and it passed, though that test is a bit short. Then I ran the Windows 10 memory test, which runs after a reboot, before OS is loaded, and it also passed without errors.
Tonight I increased the GPU:s voltage limit by 20 mV, and decreased clock frequency limit by 25 MHz in the Radeon software. That seems to help, because EDO just passed a half an hour test of flying low over terrain. I also lowered frame rate limit in the game to 90 FPS, which keeps GPU utilization below 90% most of the time, but I am going to increase that and see if it's ok to do so. If the GPU is still unstable, I will increase voltage more, because there is still headroom in TDP and especially in temperatures. Now the GPU:s voltage varied around 780 mV and clockspeed was at most 2300 MHz. Highest hot spot temperature reading was 76 deg. C. Fan noise level stayed comfortably low, too.
I decreased the GPU:s voltage limit in July and August a few times, in small steps, but it seems I have to take that adjustment back closer to default setting.
Did some protracted testing involving decending to the surface of various planets and flying hundreds of km at low altitudes over them...no crashes or other issues on either the RTX 4090 in my main system nor the RX 6800 XT in my HTPC, both using the newest available drivers.
Neither of these tests are particularly good...they'll both miss fairly blatant instabilities.
If increasing GPU voltage improved stability, then that was almost certainly the underlying issue. 780mV is rather low for 2300MHz on a 7900 XTX.
Neither of these tests are particularly good...they'll both miss fairly blatant instabilities.
If increasing GPU voltage improved stability, then that was almost certainly the underlying issue. 780mV is rather low for 2300MHz on a 7900 XTX.
Indeed. Never claim instability when you are running outside of spec.
If you are ‘juicing’ your system in any way and encounter a crash assume it is your out of norm adjustments first. Overclocking, under volting, changing bus speeds, non qvl ram running at xmp.
Turn all that stuff back to normal and see if problem goes away FIRST, before you accuse bad software.