Products Support > GSX Support MSFS

couatl64_MSFS2024.exe randomly crashing in the background

<< < (3/6) > >>

Daveo:
I get these crashes alot also around Germany EDHL EDDH area with 2024.
Have not flown around the U.K. much lately.

Have not seen anything NET related in Event Viewer.



Faulting application name: Couatl64_MSFS2024.exe, version: 5.0.0.6020, time stamp: 0x68a72d4d
Faulting module name: ucrtbase.dll, version: 10.0.19041.3636, time stamp: 0x81cf5d89
Exception code: 0xc0000409
Fault offset: 0x000000000007286e
Faulting process ID: 0x9a4
Faulting application start time: 0x01dc50b52553de9a
Faulting application path: E:\Addon Manager\couatl64\Couatl64_MSFS2024.exe
Faulting module path: C:\WINDOWS\System32\ucrtbase.dll
Report ID: 5e667e53-aad0-4307-b825-b1ab0217609d
Faulting package full name:
Faulting package-relative application ID:

thegreek:
Thanks for sharing your log.
That’s actually the same issue we’re all seeing, your crash just stops one step earlier in ucrtbase.dll, while in some cases it continues and triggers a second exception in clr.dll (.NET runtime) before the simulator eventually crashes with dxgi.dll.

Both originate from the same internal stack buffer overrun inside Couatl64, which explains why some users see only ucrtbase.dll and others see clr.dll as well.
So even if the .NET module isn’t directly part of GSX, it’s still affected once the process memory becomes corrupted after the initial overflow.

At least this is my assumption based on the crash data we’ve seen so far.

Daveo:
It wouldn't be too bad if 2024 had a save function that worked where you could pick up off an autosave.
Why this does not exist I have no idea.

virtuali:

--- Quote from: thegreek on November 08, 2025, 12:11:55 am ---The statement that “Couatl64.exe is a native app not using .NET” does not fully explain the logs.
Windows Event Viewer clearly identifies clr.dll (Common Language Runtime) as the faulting module, which can only appear if a managed (.NET) component or runtime dependency is being loaded.
--- End quote ---

The statement was correct: Couatl64.exe IS a native x64 app that doesn't make ANY .NET call, it's an unmanaged C++ app that doesn't use anything other than the win64 API. However, it's calling into the QLM/Soraco libraries using for licensing, and those libraries use .NET so, a generic problem with your .NET configuration might cause this.

The thing that leads to believe some external interference or a generic .NET problem, is that we NEVER check license "continuously". A license check for GSX or an airport is made only ONCE, when the program starts, and never again for the whole session so, the crash in the crl.dll happens later in the flight ?


--- Quote ---Couatl internally relies on Python and SimConnect, using Microsoft Visual C++ Runtimes and occasionally .NET-bound libraries through the bglmanx64 bridge.
--- End quote ---

That's not the case. the bglmanx64.dll is NOT a "bridge" with the sim.

It doesn't run in it, and doesn't do anything in the sim, it's not connected with it through Simconnect and it's also not  .NET app either and it's not even linked or loads the QLM/Soraco libraries.

In MSFS, the couatl .exe loads the bglmanx64.dll ONLY to get a list of known products, so it won't have to replicate its code, so it works as just an utility to share code, and it has NO interaction whatsoever with the sim. This is completely different that what it used to be in FSX/P3D, where bglmanx64.dll is really running in the sim as a Simconnect app.



--- Quote ---MSFS 2024 SU4 introduced asynchronous SimConnect calls and new internal caching for Atmosphere / Airspeed SimVars (see changelog: “Fixed concurrent accesses …”).
It appears GSX may still perform synchronous or unsynchronized writes to these SimVars, which results in the .NET and C-Runtime exceptions in Couatl64 and ultimately leads to the DXGI crash in the simulator.
--- End quote ---

GSX never tries to write to any of these variables. In general, GSX very rarely writes to ANY variables in the sim, the only time it does that, momentarily, is during Pushback, where it takes control of the airplane, but I don't think anybody ever reported a crash DURING Pushback, which is the only time GSX actually *writes* on some variables.

Most of the time, GSX sends EVENTS to the sim, which is the proper and safe way to change the status of the simulation without any risk. Events like TOGGLE JETWAY, for example.


--- Quote ---This issue is reproducible and independent of antivirus software.It would be very helpful if the dev team could investigate the Couatl64 → clr.dll crash path directly, as it consistently precedes every dxgi.dll CTD.
--- End quote ---

It might be reproducible for you, but I run MSFS 2024 like 10 hours per day, and I never seen such crashes, not in the sim, not the the couatl engine. All reports I see indicate a crash after some time, which incidentally is the time where GSX DOES LESS.

In fact, if you are in cruise, it doesn't do ANYTHING, other check READING your position, speed and altitude, to know when its time to reactivate itself to check for nearby airports. And here's the ONLY thing that might be what I think it's the real cause of the crashes: the Navdata API.

- When you are on ground, GSX makes a single call to it, to load the airport you are in and get data about parking spots, taxiways, runway, jetways.

- When you are in flight, GSX calls into the Navdata PERIODICALLY, to know which airports are nearby., so you can open the menu and pre-select a gate for landing. These calls are done ONLY if you are below 10k feet and you have the "Disable in cruise" option disabled.

1) When you cross over 10k feet, GSX UNSUBSCRIBES to the Navdata. This means the sim should stop sending an updated list of nearby airports.

2) When you are again below 10k feet, GSX SUBSCRIBES again to the Navdata, so it would regularly get updated airports in the area while you flying.


It would be interesting to notice if those reproducible issues (which I can't reproduce), happened in case #1, only case #2 or both. Because, if you put together all facts:

- Nobody seems to report crashes when just parked on ground, and this is when GSX does the most stutt EXCEPT calling into the Navdata (it only did it once).

- It seems that those affects reports crashes "after takeoff", which is not very clear but, it might be when you are flying, but not yet over 10k maybe ?

If we could confirm that crashes happens only between after takeoff and below 10K, then we can be reasonably sure the problem is the Navdata API OR the Navdata *itself* and we already got multiple cases in the past where even a single duplicate Navaid crashed the sim even without GSX installed, and in one case the error was in the stock Navdata, another case it was in the Navigraph Navdata, but the real reason was the sim not gracefully handling duplicated data, and this was fixed later but, we can't be 100% sure that ALL issues related to Navdata have been completely found or solved

thegreek:
Thanks Umberto for the clarification earlier.
To rule things out properly, I did a full set of tests over the last two days:

1. Full clean Navigraph reinstall:
I uninstalled all Navigraph components, removed every related folder (ProgramData, AppData, Community), rebooted, and then reinstalled only the current AIRAC cycle through the Navigraph Hub.
The installation completed without any errors.

2. Result:
The crashes with Couatl64_MSFS2024.exe → clr.dll (0xc0000005, offset 0x657c) continued to occur repeatedly during the flight.
Shortly afterward, this always leads to the usual FlightSimulator2024.exe → dxgi.dll (0xc0000005) and then the full CTD.
So the entire crash chain remained exactly the same even after a clean Navigraph setup.

3. GSX removed completely:
I then ran the exact same flight again (same aircraft, same route, same weather, same DX12/FG setup) with GSX fully removed from the system.
With GSX removed, the entire flight was completely stable with no clr.dll events, no ucrtbase.dll entries and no dxgi.dll CTD.

For that reason I don’t think this is a “GSX vs. Navigraph” conflict.
Both normally work together for many users.
In my case the issue only appears when Couatl64_MSFS2024.exe is active, and disappears entirely when it is removed.

One thing that might be relevant:
I am running MSFS 2024 SU4 Beta (1.6.23.0).
It’s possible that something introduced in SU4 (Navdata API or asynchronous changes) is triggering a scenario that doesn’t happen in the stable version, which would explain why it's harder to reproduce internally.

If helpful, I can provide the full crash reports / WER logs.
The signature is always identical:
Couatl64_MSFS2024.exe → clr.dll (0xc0000005) at offset 0x657c → followed by FlightSimulator2024.exe → dxgi.dll (0xc0000005)

Let me know if there’s anything specific I can provide to help narrow this down.

Best regards

Navigation

[0] Message Index

[#] Next page

[*] Previous page