Couatl CTD

[Jayden212]

Hi there,
The couatl had CTD after v 2.9.0. Any ideas for it? Thanks for any help!

[virtuali]

The couatl had CTD after v 2.9.0. Any ideas for it? Thanks for any help!

As explained so many times, 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 see the 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.

[HeicoH]

@Umbrto: ("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")

As I told many times: this statement IS NOT TRUE.

I can reproduce the following:

Couatl writes into the memory space of the sim, which causes the sim to crash, but Couatl still runs.

Couatl itself doesn't recognize that it wrote into the sim's memory space. Couatl then recognizes the sim crash and stops. That's why in the Couatl log you will find the sim crash first, after that the stop of Couatl.

You can easily find out that when you have the activities of both the sim and Couatl monitored by a specialized 3rd party program.

[virtuali]

As I told many times: this statement IS NOT TRUE.

You can tell it as many times as you want, you are still wrong.

I can reproduce the following:

No, you can't.

Couatl writes into the memory space of the sim, which causes the sim to crash, but Couatl still runs.

No, it doesn't. What evidence you have to backup this statement ?

Couatl itself doesn't recognize that it wrote into the sim's memory space.

I don't know what you are trying to say here but, an external .EXE CANNOT write into another process "without recognizing it" or "by mistake".

In order to do something like that, it needs to make specific Windows API calls that must be done following a very precise protocol, like getting the address of the MSFS process, and use APIs like NtReadVirtualMemory to write into it. This how the Dynamic LOD works, for example.

But since there's NOTHING in the whole Couatl source code that does anything that remotely resembles this, it's just NOT POSSIBLE that Couatl could possibly write in the simulator own memory "by mistake". We don't even try to READ from the sim memory, which would be safe, but we don't need to do that.

That's why in the Couatl log you will find the sim crash first, after that the stop of Couatl.

No, it's because the sim crashed first, and made Couatl crash because, since it's not a managed .NET application, it MUST clean up its own memory when it closes but, since if MSFS crashes abruptly, the SIMCONNECT_QUIT command never arrives, so Couatl doesn't know it's time to clean up its memory, which results in the Event recorded.

You can easily find out that when you have the activities of both the sim and Couatl monitored by a specialized 3rd party program.

No, you can't, because Couatl doesn't do any "activity" that would result writing into the sim own process memory.