Disclaimer
As pointed out first by FoundHaddock891, the suggested solution in the story below can not work. However my system works now. While there is a reason for that I do not have any clue. Do not play around with this setting as reverting it does not bring change.
I do advise to update your community content and keep your system in a good shape as per drivers and windows and so on. Although I did not change anything else in my system I have maintained the game, community content and Windows. I have no control over changes on that end. So it must be something else that prevents it from crashing now and gives me this unexperienced stability and performance. Peace.
Hi everyone!
Plagued by CTDs with my new AMD card to a point at which it was unplayable, I started investigating. I got to a point at which I would have loved to return my new AMD RX 6900 XT and buy myself a car for it. Little did I know!
System:
My system specs:
Rio Toro Enigma G2 850W
MSI MEG ACE Z390
64GB dual channel Kingston KHX3600C18D4/32GX(currently running XMP2 3GHz@CAS16)
Crucial CT1000P1SSD8 (M.2 NVMe SSD) for system
a mix of SATA HDDs and SSDs for storage
GPUs tested on this system:
MSI RTX 3090 Gaming X Trio
Gigabyte RTX 2080 Ti Windforce (not the OC version but a whopping 120 MHz auto overclock on air cooling)
XFX RX 6900 XT
Anamnesis:
unusually restraining mainthread. one core constantly maxed out thus limiting graphics options.
tons of CTDs with AMDs card yet not with Nvidiaās super consistent driver.
So, especially with the AMD card I experienced serial errors of this kind:
Example:
FlightSimulator.exe
Summary
Stopped working
Date
ā29.ā04.ā2021 21:10
Status
Report sent
Description
Faulting Application Path: D:\SteamLibrary\steamapps\common\MicrosoftFlightSimulator\FlightSimulator.exe
Problem signature
Problem Event Name: APPCRASH
Application Name: FlightSimulator.exe
Application Version: 1.15.8.0
Application Timestamp: 00000000
Fault Module Name: VCRUNTIME140.dll
Fault Module Version: 14.28.29913.0
Fault Module Timestamp: 6041a7e8
Exception Code: c0000005
So, it is always Exception code c0000005.
Debugging with Microsoft Visual Studio reveals an application stop due to continuously attempting to write to unallocated memory. However, I have no recorded history of this.
Solution:
Restlessly looking for solutions, I stumbled upon a system option which appears useless at first sight. In msconfig.exe there is the option to reduce the number of cores recognized by Windows. By default it is unchecked. Who would like a CPU with less cores, right? In fact, enabling it unlocked my systems.
This option is not only suitable to reduce the number of cores used but you can also determine how many cores are used. So, if a previous software installation or any sort of idiotic(or particularly useful) system option has reduced this number you can just set it back to full value. Which is what I did, in an effort to make sure full reserves are available to Windows. I cannot imagine why both my systems have been configured in this way. However, by enabling all cores I seem to have fixed this issue and gained massively. I suspect, because the DX11 thread, rather one of the four or the one which maxes out, still maxes out while running MSFS but now gets less bothered by Windowsā other tasks.
Application
Only discovered it last night and still testing but hereās what you do:
- run msconfig.exe
- Select the Boot tab
- open āAdvanced Optionsā¦ā
- Check āNumber of processorsā and select ALL of them (16 for an 8-physical core i9 with HT)
- Reboot
Conclusion
It is a driver issue, but not as you thought. The assumption is that not all cores were enabled and available for Windows to distribute load to dynamically. The idea is that Nvidiaās driver doesnāt estimate performance based on CPU model and cores leading to unbiased expectation in a scenario where a lower performance is delivered. Whereas AMDs driver might do this disregarding the actual core count managed by Windows.
I dare to say that the AMD driver really is a bit more elaborate and makes better use of system resources, especially cores/threads. If not all cores were used, leading to a lower performance and ultimately crashing drivers, and the vcruntime140.dll, and basically hitting out at every other running application. Like OBS, browsers, add-ons and so forth. Which I could all stabilize btw. I was unable to fix the driverās exaggerated expectations thus making it the weakest link in the chain. Consequently, it was always the driver which failed and not something else.
The fact that Nvidia is less affected proves their system stability. But performance limits did not come from the Nvidia card or driver. The Nvidia driver handled the system even when handicapped without crash.
The observation is that the mainthread is performing even better with the AMD card&driver than with my old 2080Ti Nvidia card&driver installed.
I never saw 90 FPS in 21:9 1440p before. Now I do. Okay, not since I switched back to near Ultra settings. And I never saw 90 FPS in the big cities. But this is what youād expect. However, now my GPU determines the rate at which I go most of the time. I have high hopes that this might keep the system from running into trouble with memory allocation and CTDs as these are essentially multitasking errors caused by a lack of system resources.
My observation matches the experience other people made, that AMDās cards are performing better in low-end systems. Essentially, it is exactly what we are looking at in MSFS. Itās a CPU bound scenario in the more stressful areas of the model planet. Especially when you are running a different count of CPU cores than actually present. As this number can only be lower.
I am expecting this check-up to appear on the troubleshooting page on MSFSā zendesk soon.
edit: now testing different XMP profiles for my memory again but only to optimize performance before even considering overclocking
Cheers!