A new nvidia game ready driver is out now.
Maybe some good news for us?
( It worked in the first year with this gpu. So in theory it should work again. Of course only when its driver related)
I am upping this thread because I ran into the same problem:
-MSFS crashes a few seconds after the main menu appears with this error stated by event viewer:
āDisplay driver nvlddmkm stopped responding and has successfully recovered.ā
followed by:
āFaulting application name: FlightSimulator.exe, version: 1.25.9.0, time stamp: 0x00000000
Faulting module name: FlightSimulator.exe, version: 1.25.9.0, time stamp: 0x00000000ā
The only fix is enabling the Debug Mode inside the Nvidia Control Panel. With the debug mode enabled, the sim runs fine. Make sure to close any overclocking software such as GPU Tweaker, they might refresh the frequencies and overwrite the settings by the Debug Mode.
I also tried to deactivate the Debug Mode once inflight, but the sim crashes as well.
My GPU is the Asus Dual GeForce RTX 2070 Super Evo OC, so yes it is overclocked by default.
I did a clean windows 11 install, I tried old Nivdia drivers and the lastest one.
Perhaps my GPU is defective, but no other games or 3D software give me crashes. I can even run 3D Mark stress test without issue.
Now I need to try to lower the frequencies with MSI Afterburner, but I am just glad the Debug Mode works.
@DrivenImpala805 Maybe you could try a slightly larger underclock? I guess it can vary between specific units
@Lynkk I donāt think a gpu can be deemed faulty if it only causes issues with one application. MSFS just seems to be extremely sensitive to OC, including some factory ones.
Tried with Debug mode. That works.
Whatās strange is this: when I put debug mode and try to spawn on the Concorde ; immediate CTD.
So for the PMDG 737 - I have to have debug mode on.
For the Concorde - I have to have debug mode off.
Good news if you believe in Unicorns. Truthfully, if the driver release notes donāt mention Flight Simulator, chances are slim to none that it will be affected in any positive way.
In the Fenix knowledge database there is a topic āStopping Crash To Desktop Issueā.
Iāve tried their steps and just did a flight with debug mode OFF and no further underclocking and it did not crash. Maybe you can try it.
- Exit all Windows based programs.
- Click on the Windows Start button, type regedit in the Search box and double-click regedit.exe from the results above.
- If you are prompted for an administrator password or confirmation, type the password or provide confirmation.
- Browse to and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers
- On the Edit menu, click New, and select the QWORD (64-bit) value from the drop-down menu. Make sure you create a Qword (64bit) key for Windows 64 bit OS and NOT a Bword (32 bit) key because that wil not give the right result.
- Type āTdrLevelā as the Name and click Enter.
- Double-click TdrLevel and set the value as 0 (it is set to that by default, but double check) and click OK.
- Close the registry editor and restart your computer for the changes to take effect.
did you realy know what you do with these ?
If not, you can find here what you DISABLE with this setting:
Here is the explanation from the dev team:
The problem: a thing called Timeout Detection and Recovery (TDR) checker monitors the computerās hardware, particularly the GPU.
When the GPU stops responding with the computer for 2 seconds TDR checker restarts the driver.
The TDR checker was good on paper but did not work in the real world as a GPU can stop responding when it is working hard.
Here is the solution that worked for us, it requires an extra sub key entry into the Windows registry, so please only implement if you feel OK with editing your registry!
As long as it may help, I donāt care. Itās try and error.
disabling this, just hides a the root cause 
( e.g. ram, gpu, ā¦ )
@MichaMMA Getting memory access violations using one single app, that doesnāt even push the GPU to itās limits, does not indicate faulty hardware.
What is going on here is some messy handshaking being done between the sim and some GPUs, and itās drivers.
As long as the TdrLevel (or any of those mentioned before) workaround works, then Iām happpy. At least until the devs can finally work it out.
@Housefrau3355 Iāll test it later today and report back.
1 Like
driver issue can of course also a reasonā¦ therefore exist this tdr feature
We know that from ATI users while ago, where lots of them have to increase the timeout value ( which is may be better, as disable the whole feature ).