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.
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 ?
Couatl internally relies on Python and SimConnect, using Microsoft Visual C++ Runtimes and occasionally .NET-bound libraries through the bglmanx64 bridge.
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.
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.
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.
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.
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
Recent Posts
