There may be hope!
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 order 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, which still maxes out while running MSFS, now gets less bothered by Windows' other tasks.
Only discovered it last night and still testing but here's what you do:
1. run msconfig.exe
2. Select the Boot tab
3. open "Advanced Options..."
4. Check "Number of processors" and select ALL of them (16 for an 8-physical core i9 with HT)
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. However, now my GPU determines the rate at which I go. 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.
Actually, I realize that with AMDs drivers and the Radeon 6900 XT the Mainthread is performing even better than with my old 2080Ti Nvidia card installed. This matches the observations 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 soon.
I do not gent the point yet.
My system is anyway properly starting up recognising all 16 threads, why should I specify it again manually?
I tried it and doesn't make any difference to my FPS or stop my CTD
NEW Ryzen 5 5600x (No Overclocking)
NEW RX6800xt (No Overclocking)
NEW M.2 SSD 1TB
NEW 32Gb (3600Mz) RAM XMP Enabled and disabled (Makes no difference)
NEW Mobo: Gigabyte X570 Aorus Pro
PSU: 850 Watt EVGA 850 GQ, 80+ GOLD
VR HP Reverb G2
All MSFS Setting on low to Med
MSFS Render Scale 80%
OpenXr Custom Render Scale 50%
No Mods loaded
Fresh install of Windows & MSFS
Windows update include KB5001330 (Patched)
Same for me.
I tried my "almost stability" using March Drivers and managing manually the "overcloking of the AMD sw keeping as max values the factory values of the GPU (in my case accoridng to ASUS TUF values).... but this is definitely out of any sense!
I'd like to clarify that the above description is not a solution. In fact, it does absolutely nothing. The CPU core selection can only be used to decrease the number of cores recognized by the system. Proof is that if you saw all of your cores being used in task managers performance tab before there is no point in "actrivating" them and this additional option is more likely to cause load or problems down the line than enhance anything.
That said, it is my conclusion that the problem lies in poor game optimization and streamlined drivers. AMD's drivers may be very modern and optimized to run Vulkan or DX12 titles, they are just not very bullet proof with DX11 and in particular the implementation of the complex systems with several sources of large quantities of data being merged in MSFS. While Asobo is working on their issues with the DX11 implementation, the software is still far from being bug free in an environment which doesn't support this amount of errors in the code - namely the AMD drivers as opposed to Nvidia's drivers for an environment. I recon this is what the devs of Asobo eluded to when stating that DX12 is going to solve a large number of issues for a lot of users. Apart from the main thread being spread over more than 4 cores thanks to getting rid of DX11 and some calculations even being removed from the main thread to achieve a better balance.
The transition to DX12 with MSFS is expected in 2021 to make the game available on MS' XBOX console. Time will tell whether it will be stable. Hopes are high.
Btw has anyone done any stbility testing since Sim Update IV? What's your observations?
I like to add that 6900XT brought nothing but trouble. I bought MSFS since Jan and was playing it with 5700XT flawlessly, for example I could complete Nevada bush trip in one night without a single crash.
Even since I replaced my 5700XT (big mistake) with 6900XT, MSFS means crash, crash, and crash! Did I mention crash!? It crashes almost randomly, but mostly when I approach dense area/airport, or when I look to the side. It's a complete nightmare to say the least!
Yes....I tried everything. It constantly crashes!!! Such a shame this thing.
I "reduced" the amount of crashes going back to the March drivers, but anyway it crashes frequently (just a few less times). Let me say I can finish sometime a flight...
Still do not understand how they are not able to provide good drivers for such GPU. Is a new one,a powerful one, an expensive one and in practice I would have less issues using my really old nvidia 1060!!!!
I have managed to reduce CTD in Reverb G2 VR by a lot, I have an Asus TUF 6900XT, in its default settings, it's actually factory overclocked to 2500MHz, I reduced it to 2249 (closest to 2250 AMD published), and cranked up the fan curve.
I also went into my motherboard's settings for my CPU, the so-called default settings are actually also overclocked, it let the CPU draw as much power as it could, for as long as the CPU wants, I set it to draw 200W max for 33 seconds, and 160W afterwards (which is still more than Intel's official TDP 95W). Now I have a chance to finish some very long bush trip leg, even if it crashes, I would probably be at the end of the leg and could fly by memory to end it. You see, before I did all these changes, I always get the excepttion:0x0000005 error, but afterwards, I got some other errors like VCRUNTIME.dll, and KERNELBASE.dll, but no more exception:0x0000005, and much less frequency as well.
I think MSFS still have some issues with either AMD or WMR, but I am really at the end of my rope. So for the time being, I would probably stick with Quest 2 for VR flight. I jsut hope that someone fixes this issue before Quest 2 torture me blind!
I've nailed it down to just 1 error all the time, VCRUNTIME104_1.dll exception 0x000005, path is the one in Windowsapp folder, the one we cannot fix, uninstall VCruntime redistribution only uninstall the one in C:\Windows\System32.
I have un-overclocked my Asus TUF, and put my 9900K CPU back to default TDP, increased page file size to 100GB (I have 64GB RAM), reverted OpenXR developer settings to default, re-installed MSFS itself without installing any extra contents, applied TDR fix, restored pre-assign display for WMR to minimize short pauses, change everything in AMD Radeon software to default.
Another thing I need to experiment on is that I suspect that connection issue or rolling cache might have something to do with VCRuntime104_1.dll crash. I was trying out settings on a very long bush trip leg, and I noticed if I stick with the same route precisely, I get a longer flight after each CTD. But if I got used to the route and deviate to run shortcuts, I would get CTD much earlier at first, and again, could fly longer and longer after each CTD. But I don't know what I can do to test this theory to collect concrete evidence.
Do you have 2 8pin PCIe power cables connected to the GPU or only one with the extension?
I was having problems with only 1 cable, now with 2 everything is great