Couatl cannot crash the sim.
An external .EXE cannot crash another .EXE, this is something basic about how the Windows OS works, an .EXE don't have any access to the memory space of another .EXE, unless it attached itself to it posing as a Debugger, and Couatl doesn't do anything like that.
What is possible is the opposite. If the sim crashes for other reasons, it will MADE Couatl crash, because in order to exit cleanly, Couatl needs to receive a specific command via Simconnect the sim has quit. If the sim crashes abruptly, it won't send the normal quit message to it, which would trigger some extra memory cleanup Couatl must do on itself, which if not done, will result in Couatl crashing. Not that this matters much after the sim crashed because Windows itself will clean up the memory.
That's why you might see an event related to Couatl.exe in the Event Viewer: it was made to crash because the sim crashed for other reasons, so you can be easily misled thinking Couatl was the cause, but it's not. It cannot, because as a regular .EXE, it doesn't have any way to make the sim crash. But the sim can crash it.
The Windows Event Viewer has timestamps, showing exactly when every event happened. I'm fairly sure that, if you check the time for the crash in Flightsimulator.EXE, it will show a timestamp a few seconds earlier than Couatl64_MSFS.EXE, clearly proving it was MSFS which caused the crash, and Couatl64_MSFS.exe crashed because of that, not the other way around.
In any case, I suggest trying today's update, because we added a lot of checks on return values from the Simconnect Navdata API, because we found issues with it are the most common causes of crashes users might THINK are caused by GSX (because they might go away if uninstalled, but just because there's no other add-on calling the Simconnect Navdata API), are in fact caused by bad data coming in, because it's the very act of *querying* the data that makes the sim unstable.
