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.
@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.)
that was the question I wrote some days ago - code-base or same kind of system-issue. If we assume software, then we are back by may be some system-libs which differ to e.g. to my system. The main question is still: why only some users see that error and most users not ? If both application use a lib which cause that, I expect that I see the issue in MSFS too. But because thats not the case, it can be only a more system-near-lib where most users have a different version. It remains exciting
PS: and I realy hope at the end of the day we not searching the whole time again a “antivirus-tool”-issue
Amen! I’m getting the error every 5-6 flights without using Navimap. I try not to fly anything over 2hr because that increases my probability of getting the error. Word on the internet is WU10 has shuttering and people are not happy. It appears MS/Asobo only care about geography and improved cityscapes. They have no care about the playability of the sim. What the point of improving graphics if you can’t fly to see it? I believed I got ripped off by this sim.
That was my point, i mean i know that this sim is something new and all of us are pioneers of something new, what i would really appreciate is an approach from the devs like we are doing, we are gathering togheter trying to find a solution for the problem, why the devs doesn’t ask us if we want to do some tests with them? We both have the same goal, to have a stable sim and enjoy our hobby, i do not want to limit myself as i fly on IVAO and i do tours that have flights that lasts from 30 mins to 10 hours.
Apart from that i still having no errors since i have stopped navigraph from starting with windows
Yeah I’ve been using Vatsim and is embarrassing when you drop off their radar control because of memory cannot be read error. When I get close to my 5th flight I stop using Vatsim.
Thanks for this topic! I had this error once (during installation of MSFS) and I realized it occured after ensbling XMP profile increasing my memory from 3200 to 3733… After reverting haven’t got this error anymore!
Seems like several of us in this exclusive club have got issues with XMP.
As for me, in latest SU10 beta update, sim is still stable with no XMP and GPU clocks reduced. I did have a mem could not be read CTD last flight. MSI afterburner had not loaded with Win11 and thus GPU clocks were back to OC.
So if I wanted to (which I don’t) I guess I could reproduce the CTD.
Good Saturday morning to all, this morning even if I had MSI Afterburner on no Navigraph app opened our error friends showed up in final at KDEN after 3 hours of flight
Be aware that using XMP or memory overclocks in general puts more stress on the memory controller located on the processor. I’m not familiar with your setup on DDR5 and Alder Lake, but is your XMP an overclock? You can find the published DDR5 speed on Intel Ark.
I had to increase the VSOC voltage on my 5950X to 1.1v to get the memory to run at DDR4 3600 Mhz, higher than the advertised 3200 Mhz for Ryzen 5000s. I’m not advocating to boosting voltages… just saying this could be a reason why your XMP profile is giving you issues, although admittedly I would this this would be caught by Memtest.
XMP on my DDR5 is most definitely an overclock. Default 4800, XMP 6000.
I find that disabling XMP along with returning GPU clocks to stock have pretty much resolved my issues. Been flying in SU10 beta for 13 hours total (longest flight nearly 6 hrs) with just one CTD. And that was when GPU returned to factory OC because Afterburner didn’t load with Win11. So I think my findings for my rig is pretty much consistent and reproducible.
And by the way I did run Memtest86 at XMP 6000. Loads of errors. Reducing to 5800 and not a single error. I kept the XMP timings and voltages though.
Yea, I remember when I was fine-tuning my overclock, DDR4 3800 Mhz was unstable, but 3733 Mhz was stable like a rock. I agree with you, set it at 5800 Mhz for now to be stable. You can always tinker with trying 6000 Mhz in the future. It might simply need a DRAM voltage boost, or increasing voltages on the memory controller.
I wouldn’t say I’m glad you found errors, but at least you eliminated one possible variable.
After extensive long testing with Memtest & Y-cruncher. My 4 sticks (64Gb) of TridentZ Neo @ 3603Mhz (XMP) are solid with no errors. However, MSFS gives some random read errors.
Remove 2 sticks and the read errors have not occured. Same Memtest 7 Y-cruncher tests carried out again no errors.
Next step is to reinstall the two sticks and loosen the timings slightly.
Its very strange how more people started having this issue post SU9.
Four DIMM sticks will always put more stress on the memory controller than two sticks. It’s a lot more difficult to overclock (even with XMP) memory with four sticks because of this.
I’ve tried FS2020 with both XMP on and standard clock speeds. Issue is present in both configurations. I’ve done the Windows Memory Diagnostic and no errors reported.
