Looking for anyone who’s hit a similar crash, since I’m trying to figure out if this is a known/shared issue rather than something local to my install.
The pattern
I’ve had a handful of CTDs (0xC0000005 access violations) over the past few months. Two of them, four months apart and across two sim builds, show the exact same “Purpose” field in AsoboReport-Crash.txt: QmidLoader. Both also happened under very similar conditions:
Deep into a long cruise (5-6+ hours in), over sparse terrain (open ocean / desert)
On two completely different aircraft from two differ
ent developers (iniBuilds A350 and PMDG 777)
No warning signs beforehand — stable memory, stable frame times, no LOD stress, nothing unusual in the minutes leading up to it
All WASM modules (including the aircraft’s own) showed “Ready”/“Idle” at the time — not mid-calculation, not in an error state
The raw callstacks (RawCallstackWin64) from both crashes have the same structural shape — same set of frame indices present/missing, same relative spacing between offsets — just shifted because of the different build versions. Everything points to the same underlying code path, somewhere in the terrain tile streaming system (Qmid = Quad Map ID, presumably).
I’ve also had one CTD tied to a Coherent GT UI crash (during an ATC approach change) and one crash where the report itself came back completely empty — so not all of my CTDs are the same bug, but the two QmidLoader ones look like a clear match.
System (for reference, to help rule things out)
Ryzen 7 9800X3D, RTX 4070, 32GB RAM at stock JEDEC speed, no overclocking
No WHEA errors anywhere in Windows’ reliability history
sfc /scannow clean
Steam install, verified
What I’m asking
Has anyone else seen “QmidLoader” in their own AsoboReport-Crash.txt (check %APPDATA%\Microsoft Flight Simulator 2024\AsoboReport-Crash.txt after a crash, or AsoboReport-OldCrashes for older ones)?
Especially interested in hearing from people who crash during long, uneventful cruise segments over open water/desert/poles — if this is a shared pattern, it’d help to have more than my own two data points when raising it with support/devs.
I already have a support ticket open, but given how rare/non-deterministic this seems to be (roughly 1 crash per 2-3 months despite heavy, regular flying including many long-hauls with zero issues), a vanilla repro is tough to pin down on my own. Any shared reports would help build a clearer picture.
I’ve done some more digging since my original post, including analysing the available Windows crash dumps rather than relying only on the Asobo crash reports.
The most interesting result is that my July and September crashes appear to be the same underlying crash mechanism, despite occurring on different MSFS builds. Both are 0xC0000005 invalid pointer reads inside FlightSimulator2024.exe, and WinDbg shows both crashes reaching the same sequence of MSFS machine code with a remarkably similar CPU/register state.
So there does seem to be a repeatable MSFS code path involved. However, I can’t determine from the available minidumps what originally caused that pointer/state to become invalid. Also, I no longer think QmidLoader alone is enough to conclude this is specifically a terrain/QMID bug — that was probably too strong an assumption in my original post.
My August CTD appears to be different (a NULL pointer access, with CoherentGTImpl_Z in the Asobo report), so I’m also fairly confident that not all of my 0xC0000005 crashes are the same issue.
On the system side, I haven’t found evidence pointing towards hardware instability: RAM is running at stock JEDEC speed with EXPO off, there is no recurring WHEA pattern, pagefile is system-managed, and there were no GPU/display/WHEA errors around the September CTD. Memory and VRAM usage were also well within limits and differed considerably between crashes.
So at this point I still don’t have a root cause, but I have narrowed it down considerably: July and September look like the same recurring MSFS invalid-pointer crash, while August appears to be a separate issue. The remaining question is what triggers MSFS to enter that bad state in the first place — the sim itself, an add-on/API interaction, or a particular combination of circumstances.
I’ll update this thread again if I get another crash/full dump.
Hello im having same issue. its been happening very frequently now, the CTDs, and its just ruin the game experience for me. I running WinDbg and im getting same thing you are, the QMidLoader thing, 0xc000005 and the "INVALID_POINTER_READ " error.
I really hate this issue and it didnt used to be here before, i think its just come from the last Sim update (or it making the issue really frequent). Anyways before it last CTDed (which was yesterday night), i originally thought it was caused by Winctrl wasm issue as i kept on seeing it “Failed” in the previous ctd logs, so i removed the folder, but the issue still persists. and at this point its probably a Sim memory management issue cuz so many Other people having it. Also at the time of all my ctds, my memory are all within their limits .
Thanks for sharing your WinDbg analysis because that makes it very interesting. I compared it with my own crash dump and the match is striking.
Both crashes were on MSFS 1.8.16.0 and show:
FiberProc
0xC0000005
Purpose="QmidLoader"
INVALID_POINTER_READ
Fault offset: 0x3F50859
Faulting instruction: mov eax,dword ptr [rcx]
Even the relevant register values and raw callstack offsets match.
I also have a July crash on an older MSFS build that appears to fail in the same machine-code routine.
This looks like more than just two unrelated generic 0xC0000005 crashes. Hopefully the matching 0x3F50859 crash signature can help identify this issue further.
Yeah, it can be worth it to try different drivers. However, it is very difficult to determine if a driver is actually the culprit (bases on the crash reports) and my crashes happened on different driver versions.
I have been getting recurrent CTDs in MSFS 2024 with Exception Code 0xc0000005, and the crashes seem to occur during relatively long flights rather than during loading or shortly after takeoff.
My current system:
CPU: AMD Ryzen 5 7600
RAM: 32 GB DDR5-6000 CL30
GPU: MSI GeForce RTX 5070 Ti 16 GB
Simulator: MSFS 2024
Version: 1.8.16.0 (SU6.1)
DirectX: DX12
The most recent crash occurred on a Concorde flight from LFPG to GOOY. The flight had been running for approximately 1 hour and 30 minutes when the simulator suddenly closed.
Interestingly, Windows does not identify nvlddmkm.sys, d3d12.dll or another NVIDIA/DirectX component as the faulting module. It identifies FlightSimulator2024.exe itself.
I have also experienced another serious CTD on a previous MMMX (Mexico City) to LEBL (Barcelona) long-haul flight, this time using the Aerosoft A340-600. The crash occurred during cruise, around FL370, while flying over the North Atlantic area, around CYYT. REX Atmos was active at the time.
Yes I also noticed that. I did have a piece of software that was using mobiflight module. I decided to delete that (it was not usefull anyway) and I didn’t have a crash since, but also not done a lot of flights. So I need to do some more testing
As a quick update, I have now flown the exact same route twice, LFPG–GOOY, without REX Atmos installed, and I haven’t experienced any CTDs or other issues on either flight.
This makes me suspect that REX Atmos could potentially be involved, although I obviously need to do more testing before drawing any conclusions.
.