CTD with MSFS Couatl64_msfs fault 0xC0000374

[gbruyneel]

Hello I am experiencing the following crash:
Faulting application name: couatl64_MSFS.exe, version: 4.8.0.5268, time stamp: 0x6516c577
Faulting module name: ntdll.dll, version: 10.0.22621.2428, time stamp: 0x806d3ecf
Exception code: 0xc0000374
Fault offset: 0x000000000010c849
Faulting process id: 0x0xD0C
Faulting application start time: 0x0x1DA0135386F6DFF
Faulting application path: C:\Program Files (x86)\FsDreamTeam\couatl64\couatl64_MSFS.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 10eb009e-a33e-49ec-93ae-6b9e9aff86d8
Faulting package full name:
Faulting package-relative application ID:
 this make the msfs to crash also.

Any help ?
Thks.

[virtuali]

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.

[gbruyneel]

Thanks for this answer.
I have open a Ticket at MSFS support, and they said is Couatl that cause the issue. I will get back to them with your clear explanation.

Thanks a lot.

[virtuali]

I have open a Ticket at MSFS support, and they said is Couatl that cause the issue

Have you checked the timestamps? If Flightsimulator.exe crashed before Couatl64_MSFS.exe, it should be clear the cause was Flightsimulator.exe that crashed for some reason, and made Couatl crash, not the other way around.

And Microsoft support should know better than anybody that an external .EXE (and that surely doesn't Attach itself as a Debugger, and you really need to trust me about this) can't crash another .EXE, if this was possible, the whole base on which Windows protected mode worked since Windows NT would be in question...

Now, for complete disclosure, in the latest SU13 Update, there has been some fixes to the Navdata API that, according to Microsoft own release notes, could cause crashes:

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 (from Couatl) surely use the Navdata API, GSX couldn't work without it, unless you went back to the legacy Airport Cache method (where GSX read the airport. BGL and it's still possible to enable to diagnostic reasons) so, I'm not saying it's not possible that using GSX couldn't possibly result in a sim crash, I'm saying the cause is not Couatl, since you can't obviously fault it for using an officially supported API that, at least until the previous version, according to Microsoft, could cause a crash in the sim when called.

That's regardless which add-on called it, but since GSX is likely the most popular add-on using the Navdata API, I can see how the guy from Microsoft support might have associated the crash with Couat, saying it's the "cause", when in fact the cause it's Simconnect itself.

That is because, it's surely possible they haven't found ALL possible issues with it, so the fixes in SU13 might have helped in some cases, but not all of them.

One thing you can try is to go back to the airportCache method, by setting this line:

useAirportCache=1

in the %APPDATA%\Virtuali\Couatl_MSFS.INI file.

This way, GSX won't use the Navdata API anymore, it will read the airport. BGL instead, which means it won't work with Marketplace airports. Also, Jetways will not work entirely, because there's some data GSX needs about them which can only be obtained with the Navdata, so I'm not suggesting you keep this mode enabled.

But as a Troubleshooting method, if you notice the crashes stopped when GSX stopped using the Navdata, it might be useful to know that, in fact, not ALL CTDs in the Navdata API SU13 were supposed to fix, have been found yet.