As a software developer, this “Before - After” logic drives me crazy. It is a known fact that Asobo is adapting the FSX code base where they can use it, and writing massive amounts of new code that has given us the realistic weather, virtual VFR reality, worldwide terrain, worldwide airports, and so much more.
Stated another way, this is no longer FSX, and every new update will add more and more stress on your computer (CPU, memory, motherboard, storage) and your graphics card.
The conclusion from those facts is that what worked before may not work after an update. Add in the determination to run everything in 4K ultra, the mods, tweaks, and insistence on keeping them in the community folder after an update, and it’s a sure bet that we’ll have TONS of complaints about CTDs, AP bugs, instrument bugs – well, you know the rest.
I have a troubleshooting principle I call “Known Good Configuration”. Why introduce variables rather than eliminate them? Applied here, it means that before you complain about a problem that might be due to a combination of OC and sim stress, why not eliminate variables after an update?
-
Remove any overclocking of your CPU, memory, or GPU for right now.
-
Clear your community folder (including liveries, Navigraph data, and ALL mods).
-
Remove any tweaks to Asobo default files.
-
Do not use any third party products or add-ons, even if obtained from the MarketPlace.
-
Run everything on High instead of ultra to test the new update.
If it still CTDs, then now you can be pretty certain it’s an Asobo bug. If it doesn’t, then now you’re in a troubleshooting mode to try to find out what is causing the problem. And I would suggest that you leave overclocking until the end, because we know that most mods affect frame rates as do third party aircraft and airports. In other words, they add stress to the CPU and GPU.
If adding everything (other than OC) back in does not cause CTDs, then hello – you know what’s causing the problem, don’t you?