CTD Every flight, couatl64_MSFS.exe

[Mejjo]

Hi there

I have a fresh windows install, fresh MSFS install and only have 2 addons installed ( Fenix A320 and GSX Pro )

Every flight i have a CTD within 30 - 60 minutes of the flight. In the event log there is only one error showing on the CTD and that is couatl64_MSFS.exe.

I have reinstalled GSX pro but i really don't know what more i could possibly try? Has anyone else started to get this?

[virtuali]

Every flight i have a CTD within 30 - 60 minutes of the flight. In the event log there is only one error showing on the CTD and that is couatl64_MSFS.exe.

By definition, GSX/Couatl CANNOT CRASH THE SIM, since it runs completely external to the simulator, under a separate .EXE ( the Couatl engine ), and by definition, an regular .EXE like that doesn't have ANY access to the simulator process or memory, this is enforced at the Windows level.

What CAN happen, instead, it's the sim crashing for other reasons, and bring GSX down with it, this is to be expected and can easily mislead you thinking the "cause" was GSX ( maybe you see GSX crashing in the Windows Event Viewer), when it was the other way around.

[gu1du4]

I read your reply and responded to the MSFS2024 team who are arguing that GSX/Couatl is crashing the SIM.
My issue is that in MSFS2024 every flight i have a CTD within 30 minutes, and I'm running only Fenix + GSX addons.
On MSFS2020, everything works perfectly, zero crashes.
Any news on this topic? Did it got resolved in some other way?

[virtuali]

I read your reply and responded to the MSFS2024 team who are arguing that GSX/Couatl is crashing the SIM.

What do you mean with "the MSFS2024 team" ? Some support guy that, just because many users were reporting crashes with GSX because they were also mislead thinking GSX could crash the sim, assumed it might be true ?

Because, this is what the MSFS SDK actually say about external .EXE:

https://docs.flightsimulator.com/msfs2024/html/6_Programming_APIs/SimConnect/SimConnect_SDK.htm?rhhlterm=design%20considerations&rhsearch=design%20considerations

The recommended method of writing an add-on is to build it out-of-process as an application (an .exe file) rather than in-process (a WASM module). This is because out-of-process applications provide more stability, if they crash they typically will not crash Microsoft Flight Simulator 2024, and they are easier to build, test and debug.

Of course the SDK can't say anything different, since this is a basic Windows foundation about process isolation. HOWEVER, that doesn't mean it's "impossible" for a Simconnect .EXE to "cause" a CTD but, here, you must understand the difference between cause and effect. If a certain Simconnect API has a bug, ANY app that calls into it will "cause" a crash, but that doesn't mean the app calling Simconnect is "at fault" or must be "fixed", it's an issue in the sim, because that is REALLY causing the CTD, it's the Sim itself, when it receives a perfectly legit and documented call that is supposed to work, and it's MS/Asobo responsibility to be sure it does.

In some cases, like the Navdata API, there might be issues in the data ITSELF that would in turn possibly cause CTDs in the sim (happened several times, even WITHOUT GSX, some errors in the Navdata cause the sim to crash), and this might also mislead you "it was GSX", JUST because you happened to call it in an area where the Navdata had a problem, GSX asked for it, and Simconnect itself made the sim crash.

Again, GSX by itself, cannot crash the sim, this is not open to discussion, but there might be issues that a perfectly normal call to Simconnect made by GSX might EXPOSE a bug either in the Simconnect API itself or in the Navdata (and the way Simconnect internally deals with bad data), and I can see how you can assume "it was GSX", but it wasn't. Clearly, GSX cannot work without the airport data, and the only official way to do that in MSFS is using the Navdata API.