GSX Couatl scripting engine not shutting down?

[flyinion 280]

I've found a lot of posts on Google about the engine not starting but has anyone had an issue with it not shutting down after closing MSFS?   I just noticed this happening today.  Hadn't been in the sim in a few weeks, all addons including GSX updated, but also just installed the new Advanced version of REX Accuseason and so I was testing presets in that and Steam told me MSFS was already running.  It wasn't, but I'm finding now any time I close MSFS I have to go into Task Manager and close the Couatl Scripting Engine with "end task".  

[Drumcode 1,907]

Which version of GSX? I had issues with GSX version 2.7.4 and Couatl crashing my sim on loading, but once it was updated to 2.7.5 it immediately stopped.

[flyinion 280]

3 hours ago, Drumcode said:

Which version of GSX? I had issues with GSX version 2.7.4 and Couatl crashing my sim on loading, but once it was updated to 2.7.5 it immediately stopped.

I was on 2.7.4 and yeah I think that one I had some weird error on loading the first time and I stupidly clicked "OK" or whatever without reading it before I realized it was an error.  Then today I noticed the not closing issue, checked for an update and installed 2.7.5 but it's still not closing after shutting the sim down.  I might just have to resort to uninstalling/reinstalling I guess.

[flyinion 280]

Well, starting to think GSX has corrupted itself or something.  Just updated to 2.7.6 today and noticed Couatl is still staying active in Task Manager after exiting the sim, so Steam thinks it's still running.

[MDFlier 2,031]

Is the sim still running in task manager? If not, check the application event log to see if flight simulator crashed as it was unloading. One of the last things the simulator does when it shuts down is sending a message to all dependent modules telling them to shut down as well. If the simulator dies before sending those quit messages, then the other apps will remain running.

I do believe that GSX needs a quit message from the sim to cause it to shutdown and unload.  

[flyinion 280]

3 hours ago, MDFlier said:

Is the sim still running in task manager? If not, check the application event log to see if flight simulator crashed as it was unloading. One of the last things the simulator does when it shuts down is sending a message to all dependent modules telling them to shut down as well. If the simulator dies before sending those quit messages, then the other apps will remain running.

I do believe that GSX needs a quit message from the sim to cause it to shutdown and unload.  

Nope the sim is not still actually running.  Closing out Couatl in the task manager reverts the Steam "play" button back to the green "play" state.  There's nothing in the event log except the startup error for afc_bridge that happens when my Bravo is not connected but that's it.

[flyinion 280]

Now I'm really confused on this.  After updating to SU13 I did some more testing.  With just my payware mods installed I loaded up a flight with the Fenix and the scripting engine would exit when returning to main menu.  Exited and added my usual collection of addons back in via addon linker.  Tested again with Fenix, and same behavior.  Then loaded up the FBW latest Dev (which I had been using when I originally posted this issue) and I'm wondering if it's an issue with FBW's GSX integration options because returning to main menu left it running still.

[flyinion 280]

Well, not sure what changed, but updated from 2.7.6 to 2.7.8 fixed it.  Also the Couatl process shows up under MSFS in task manager now instead of a separate process in the list.  Having never looked for it before this issue though I don't know if that was correct behavior previously as .7 they recompiled the engine with SU13's SDK (but this was happening originally on SU12).   Going to guess 2.7.4 or .5 didn't install correctly and it took a couple updates to fix it.  I had even cleared the downloads/install caches for Virtuali before updating to 2.7.6 as per a fix I found on their forum for a thumbnail error that was occurring.  

[El Diablito 330]

This Couatl Scripting Engine has crashed the sim twice on me in 24hrs, all since installing GSX. First crashes in months.

Never a dull moment.

[virtuali 4,446]

10 hours ago, El Diablito said:

This Couatl Scripting Engine has crashed the sim twice on me in 24hrs, all since installing GSX. First crashes in months.

Couatl hasn't crashed the sim. Couatl is an external .EXE and, by definition, external .EXE that are not attaching to another one as Debuggers or making a Windows global hook (and we don't do anything like that), doesn't have any access to the simulator memory, because it's running out of process, so it hasn't have the physical capability to "crash the sim".

Maybe you are assuming Couatl crashed the sim, just because you saw a crash event related to it in the Windows Event Viewer, but that doesn't mean it was the cause.

In fact, it was the other way around: the simulator crashed for any other reason, and made Couatl crash, because the abrupt lack of Simconnect communication prevented Couatl to receive the "Quit" command from Simconnect, so it couldn't do the required memory clean up that native unmanaged x64 applications must do, to prevent crashing themselves.

That is due to the fact it's not a .NET application, which has the .NET framework handling memory allocation and reclaim automatically, it must do it itself, but if the sim crashed abruptly, it can't, so you'll see Couatl has crashed in the Event Viewer, but it was *because* the sim crashed, it didn't *cause* the crash.

We have some code that tries to detect the sim crashing, so we could do memory clean-up in time, so Couatl wouldn't crash even if the sim crashes, users won't see the Couatl crash event and would stop being misled assuming Couatl was the cause. Sometimes this works (the log would indicate the sim has crashed), but not always, because the sim can crash at any time, for example in the middle of a Simconnect data transmission, and these kinds of crashes are almost impossible to detect.

Now, it is possible that, rather than Couatl crashing the sim, the Navdata API (which is part of the sim) might have crashed itself, just because Couatl made a call to it. This has been acknowledged in the SU13 release notes:

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

Quote

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

This shows that it was likely, until SU13, that calling into the Navdata API could freeze/crash the sim, and of course GSX requires the Navdata to work so, it is possible that not ALL known issues with it have been fixed, and this might also depend on which Navdata is used.

To provide for this eventuality, we added a new option in the GSX Settings to Disable GSX in Cruise.

Normally, while in flight, GSX makes a call to the Navdata API when you open its menu in flight, to get a list of the nearby airports and allow you to pre-select a gate before landing.  Enabling this option will stop any communication with the Navdata API unless you are below 10k feet and are flying 250kts or slower so, even if you open the GSX menu during in flight accidentally, with GSX disabled, it won't do anything.

Also, enabling that option might help you with troubleshooting: if you are still getting a crash in flight, and you were flying over 10k feet or faster than 250 kts, you can be 100% sure it wasn't GSX.

 

Edited November 29, 2023 by virtuali

[El Diablito 330]

Thanks for the detailed response.

Yeah, I'm not technically minded at all and I don't know what the sim and other programs are doing behind the scenes. All I know is since I installed GSX the sim has frozen twice and not responded in the details section of task manager.

When I did some digging it showed a program called Couatl scripting engine had stopped working. When I did some more digging I found that adware had been installed at the same time and there were some Heur files linked to Couatl.

I've cleaned everything up now and will test later but whether Couatl is doing nothing to kill the sim mid flight or not, my crashes were linked to it. I'll activate the option to disable mid flight. Your guess might be right as the freeze happened just as I was beginning prep for descent at FL340.

Thanks again.