If this is purely a software issue, as you’ve stated, can you provide an explanation why the majority of users never encounter this error?
I get that you’re frustrated about this issue, but taking offense to a moderator addressing the fact that hardware likely plays a significant role in this error isn’t going to be productive.
I meant not to offend anyone simply i would like to understand their reply (one on over 1000 posts) who states that it is hardware related, imho it cannot be stated that it is hw related as before SU9 on same hw config did not happened to anyone
may be for intresst for compare.. XMP may be the biggest difference of what users reported. I use XMP mode, but the XMP profile of my RAM is mainly same as the fastest JEDEC standard profile (1), so no OC here.
I OC my CPU with “sync all cores” - setting and my 2080TI is factory OC’ed ( the highest pre-OC model ).
I have many sound-devices, but for MSFS I use in meanwhile the onboard realtek digital out ( toslink) with a driver date from 12/2019 from MS. But I killed all of that Asus sound-tools, I banned nahimic service from my system, etc.
System ( win10pro ) wide vcruntime is in meanwhile at 14.31.31103 and .Net seems 4.7.2 .. if that relates..
.net updated to last version, c++ runtimr only 2003 for msi afterburner and 2015 -2019 sound realtek only, maybe windows? I have win11
that I thought too, but we have reports from win10 users too..
EDIT: what exactly are these for versions ?
you find the versions eg. within the device-manager → audio-devices and audio-controller → properties → details page → choose driver-verison from list. ( if you have installed the realtek package, you can also see it within programme-features ).. I assume its somewhat with 6.xxxx ? ( but I realy hope in win11 are per default newer drivers installed 
)
Is it possible that the internet connectivity for users might be a factor in whether they get these CTD or not and how often they get them?
Let’s say that a log of say AI traffic issues is stored somehow in memory and the data structure used to hold this log is not prevented from exceeding its capacity. If you have a rock-solid Internet connection then you would have less chance of filling this data structure, but if it has a time when it runs slow or has massive demand, that might change.
Lot’s of assumptions here, i know, but can anyone think of a way to temporarily reduce/remove the reliance on an internet connection, to see if the issue goes away?
yesterday I had same in mind, as I helped a friend with its router. While settings I remember that here some providers configure the router per default so, that one time per day the IP was renewed and I remember that some users here let the PC “flight” over-night ( I know, strange that I think about the msfs forum while helping a friend ). Package lost might be similar, but I’am realy not sure whether this realy cause these kind of error-message, which is realy a bit “special”.
Realtek (R) Audio driver version 6.0.9244.1
A temporary loss of an internet connection might, if my theory holds any water, increase the number of issues.
hmmm, here’s an idea, didn’t Asobo introduce some measures to prevent AI traffic causing slowdown/crashes at some point in the not-too-distant past. I wonder if they put some temporary debugging code in to track AI/live aircraft and then forgot to remove it, and it is this code that is exceeding the limits of a data structure???
I must stop drifting off on these crazy theories.
As far as overclocks go I think the cpu is the least likely, this is a memory error afterall. I have a simple PBO ‘enabled’ OC which comfortably gives me a 4.59GHz boost instead of 4.36 without.
No problems or CTDs. My 14CL Trident-Zs are on slightly relaxed Jedec timings as I have all four slots occupied.
Agree. In my case GPU clocks and memory clocks. Hopefully it will be useful to others experiencing the same issue. And if there’s anyone with this issue that has 4 DDR5 sticks installed, I’d remove two of those and re-test. Or run Memtest86 with all 4 installed.
You’re probably right, but the memory controller lies on the processor for modern processors. If the memory controller is bad, it can look and act like a bad RAM problem. Prime95 can test the memory controller by using a certain FFT size. I don’t remember off the top of my head, but a quick Google search should do it.
However, at least in the case of Ryzen, a bad memory controller will throw WHEA events. That’s usually the first sign of an unstable Infinity fabric overclock for Ryzens.
I thought of that but as most modern controllers can comfortably handle 4000MHz plus I think it less likely. From what I’ve seen 3200-3600 is most widely used in MSFS.
With XMP on my DDR5 will run at 6000MHz. XMP off: Been able to complete GA flights from to Singapore to Bhutan without the CTD now. For the last ~2.5hr flight I used a custom clock of 5800MHZ. No CTD.
Once I know which RAM frequency is stable, the next step is to increase GPU clocks.
A sensible approach to MSFS, how refreshing! 
What’s your point?
That more people should do as you do and actually take the trouble to find out what their hardware is capable of (within the confines of MSFS).
The error message about MSFS not being able to read memory:
refers to virtual memory locations within the flightsimulator.exe memory space, not real hardware memory locations. Windows translates these virtual addresses to the real hardware memory addresses so that flightsimulator.exe can execute the code and retrieve the data it is asking for. Flightsimulator.exe doesn’t know the real memory addresses nor should it care. It is Windows responsibility, one of its main jobs to do, is to efficiently and correctly manage memory for all the programs running on a system.
The error message does not indicate that it is a hardware problem. Windows is very good at reporting and managing hardware errors.
The error message usually indicates a coding error. MSFS defines certain virtual memory addresses for the data it uses. If some code tries to use data in a virtual memory location it hasn’t defined, Windows has no real memory address for that virtual memory location. Windows deliberately blocks the attempt and terminates the program.
To fix this problem the crash dump is needed along with the source code and a good debugger. Then the code need to be patched and then distributed hopefully in SU10.
sound like the current one for win11..
@HawkMoth9135 also if network-hick-ups can cause problem, we should not forget the other applications which similar error message. Therefore I’am not so sure whether this can be realy relevant here.
yep.. and these controller is OC’ed too with XMP and if there other cpu-relevant-OC’s, may be it have an effect. But as mentioned my favorite was allways the RAM XMP mode, I only mentioned cpu for compare
yep.. mentioned same somewhere in the topic :).. but still: how we explain the crash of Navigraph while MSFS was not running ? Two applications with the same bug ? 
If the “broken” code in MSFS and Navigraph use the same API or the same library, then the same error should happen when the code is executed by either program. (Or could happen depending on how the function is called.)
