CTDs

[Punit]

Hello Team,

I have been facing a couple of CTDs and everytime I check on Event Manager I see the faulting application path which directs to couatl64\couatl64_MSFS.exe

CTDs are not random they happen only during these following situations,

1) Normal loading screen when you start MSFS.
2) After landing you park gate and request for deboarding.

In both scenarios, the faulting application path is couatl64\couatl64_MSFS.exe

Request you to pls let me what's going on. I regularly update the GSX with offline installer and with FSDT Universal Installer as well. My current version is 2.5.9.

[virtuali]

I have been facing a couple of CTDs and everytime I check on Event Manager I see the faulting application path which directs to couatl64\couatl64_MSFS.exe

This has been discussed so many times on the forum, you are being mislead by the event viewer and are assuming that, just because you see Couatl crashed, it was the cause of your MSFS crash, but it's not.

The couatl engine, as an .EXE, doesn't have ANY access to the Flightsimulator.exe process, meaning it cannot possibly cause a crash. This is granted by the OS at the lowest level, and programs that don't attach to a process like debuggers ( and Couatl surely doesn't ) and/or are not lower level services or drivers, simply cannot crash other apps.

On the other hand, when Flight simulator crashes for any other reason, it will abruptly disconnect its communication with the Couatl program, which is waiting for a proper "quit" command ( which hasn't arrived, because the sim crashed ), to exit cleanly.

So, what really happened here, is that MSFS crashed for another completely unrelated reason, and it MADE Couatl crash too, because of the unexpected disconnection, and you are being mislead assuming Couatl has something to do with it, because you are seeing it referenced in the event viewer.

As discussed in this other post:

https://www.fsdreamteam.com/forum/index.php/topic,29540.msg191735.html#msg191735

If you checked the timestamps of the Event, it's likely you'll see that Flightsimulator.exe crashed BEFORE Couatl64_MSFS.exe, which means it was the simulator that made GSX crash, not the other way around.

[abxzaug]

Hello Team,

i have search to a solution for this problem (i search this since FSX..) , i have no find a solution. Iam a tecnician and can tell you:
GSX PRO installed, CTD's (multiple): 
C:\Program Files (x86)\Addon Manager\couatl64\couatl64_MSFS.exe

"The couatl engine, as an .EXE, doesn't have ANY access to the Flightsimulator.exe process, meaning it cannot possibly cause a crash"

GSX PRO uninstall = no CTD's.

Okay, i think its a problem that more people have in the community, what will you do to help us?
Thank you very much!
br gernot

[virtuali]

"The couatl engine, as an .EXE, doesn't have ANY access to the Flightsimulator.exe process, meaning it cannot possibly cause a crash"

GSX PRO uninstall = no CTD's.GSX PRO uninstall = no CTD's.

I can only confirm this, which is not open to debate, really. An external .EXE CANNOT crash another one, if it's not attached to it as a Debugger, and Couatl surely isn't.

Now, why do you think uninstalling GSX has "fixed" your CTD, misleading you to say it's a GSX problem or something we can do to fix it? There are several reasons why, a CTD is not CAUSED by GSX, but it might appear to be "fixed" by uninstalling GSX, without this being a proof GSX is the problem:

- There's a known limit on the overall number of Simobjects in a scene and, when it's reached, first objects start to disappear at random, then the fps goes down and the sim eventually will crash. GSX is NOT the biggest contributor to the increased number of objects, and when you are flying its contribution is exactly ZERO. The biggest contributor to the number of objects is AI Traffic so if THIS is the cause of your crash, you would have obtained the same result by disabling traffic or removing whatever AI traffic package you use.

- There might be a problem with the video driver (and if you use DX12 Beta, which is called Beta for a reason, DX12-specific issues) where displaying what is an otherwise fully legal and correct object in GSX, might crash the sim because of a bug in graphic driver, either in the sim itself or in the driver. Those CAN crash the sim but again, there's nothing we can do to fix it, unless somebody would find exactly what otherwise SDK-complaining kind of object cause this crash but, even in this case, it should be fixed by Asobo/MS. Again, if few other products use this hypothetical perfectly legal method, you might be misled it's "caused" by GSX, because you don't have any other add-on that use it, and it's "fixed" by uninstalling GSX.

These first two would only cover cases where you are USING GSX, because when you are flying, GSX doesn't create any objects, it's just checking your location regularly, to present a list of the nearby airports. This involves calling the Navdata API, which of course is an official part of the SDK but, again, few add-ons require it or use it.

Bugs in the Navdata API CAN crash the sim, which is confirmed by reading the SU13 release notes:

https://www.flightsimulator.com/release-notes-sim-update-13-1-34-16-0-available-now/

Requesting some data using the NavData API shouldn’t freeze the sim anymore

GSX obviously MUST use the Navdata API to work, otherwise it wouldn't be able to make a list of nearby airports to select a gate before landing, so it does it during the whole flight. So yes, a bug in the Navdata API (which is NOT a "GSX bug") CAN crash the sim, and you can easily mislead assuming it's "GSX's fault", because removing GSX will "fix" the crash because there are no other add-ons left calling the Navdata API.

Those issues might also be dependent on the navigation data itself, because if they always happened, it would happen to EVERYONE, not just a few users. Assuming the crashes are caused by bugs in the Navdata, it would be helpful to know if you use add-ons for it, like Navigraph or anything else, and it would be useful to know if they happen in specific areas. In FSX/P3D, we have a confirmed case of crashes in flight, which also resulted in users "being sure" it was GSX "because they go away if I uninstall it", but it turned out it was a third-party replacement dataset which contained corrupted data, so it caused a crash when queried by GSX so, it's possible this might be something similar.

In all these cases where the Navdata API is involved, the cause is not GSX (you would have crashes even with another add-on using it), and to reply to the "what will you do to help us?" The only thing we can do is to collect enough evidence of how and when this happens and report it to Asobo because it might be possible that not ALL the issues with the Navdata API have been fixed with SU13.