Couatl misbehavior after FSX exit

[pikalaxalt]

Condition: Couatl remains running after FSX exits.  The next time I launch FSX without restarting Windows, the active instance of Couatl does not connect to the new instance of FSX.  The menu "Addons > Couatl-powered products" does not appear while in this state.  I have to go into Task Manager and kill Couatl from there, then relaunch Couatl from its directory (FSX/fsdreamteam/couatl/couatl.exe).

My SimConnect and FSUIPC are both up-to-date, and I am using FSX Acceleration on Windows 8.1 64-bit.  User Account Control is entirely disabled (i.e. those newfangled Windows 8 apps refuse to run), and I am running FSX as adminstrator on a single-account machine.

[virtuali]

This is very strange, and it shouldn't be happening. There's a feature in the Addon Manager that explicitly checks if for any reason the Couatl.exe is still running, and it explicitly kills it.

Are you sure you are running the latest version of the software ?

And, is your FSX otherwise quitting cleanly ? If, due to other problems, FSX is not shutting down cleanly, perhaps the code in the Addon Manager which is preventing to kill Couatl.exe ( which is not even normally necessary, but it's just an additional safety to prevent exactly what you are describing), is not getting a chance to be executed.

[pikalaxalt]

Hmm, very odd... This time, Couatl exited normally. No settings were changed.

I definitely have the latest Addon Manager, since I recently reinstalled KLAX.

[pikalaxalt]

Alright, the problem has resurfaced without me changing any settings on my end.

[virtuali]

I can only confirm what I've said earlier: it simply shouldn't be happening, because there are lot of checks made precisely to prevent this, and nobody else reported it before.

The only possible explanation, as I've said in my previous message, if due to other problems, FSX is not shutting down cleanly, perhaps the code in the Addon Manager which is preventing to kill Couatl.exe ( which is not even normally necessary, but it's just an additional safety to prevent exactly what you are describing), is not getting a chance to be executed.

This could possibly be caused by a wrong behavior from another add-on, which cause a Simconnect communication problem, which in turns prevents the Addon Manager from getting the proper message that FSX is going to be closed, so it cannot execute the automatic Couatl shutdown.

[pikalaxalt]

It would seem that Couatl is actually exiting correctly, but the instance of Couatl that is started with FSX does not successfully connect to FSX, or disconnects from FSX during the flight situation setup procedure.

I usually launch FSX with the following external addons already open: ActiveSky Next, FSRealTime, vPilot, and occasionally VAFS5.

EDIT: Same symptoms in FSX:SE, but when I restart Couatl outside of FSX:SE, I get a fatal error.

[virtuali]

It would seem that Couatl is actually exiting correctly, but the instance of Couatl that is started with FSX does not successfully connect to FSX, or disconnects from FSX during the flight situation setup procedure.

As I've said, the fact it doesn't connect AND it doesn't disconnect, it's likely caused by another module that is somewhat blocking Simconnect in some way.

I usually launch FSX with the following external addons already open: ActiveSky Next, FSRealTime, vPilot, and occasionally VAFS5.

Try to start FSX first, and then start the add-ons instead.

EDIT: Same symptoms in FSX:SE, but when I restart Couatl outside of FSX:SE, I get a fatal error.

This is a known issue caused by FSX:SE: any executable launched after FSX, will crash on restart. We are trying to get hold of DTG to give hints about it.

[pikalaxalt]

Alright, I just finished a flight and exited FSX using the following procedure:

1) Close VAFS5
2) Disconnect and close vPilot
3) Close FSRealtime
4) Press the red X on the FSX window, then click "Yes" on "Do you really want to exit FSX?"
5) When ActiveSky Next reads "Waiting for simulator", close ActiveSky Next

I'm currently looking at Task Manager, and Couatl Scripting Engine is still running.  So it seems to be a combination of problems with Couatl - failure to exit when FSX exits normally, and failure to connect to a new instance of FSX.

[virtuali]

So it seems to be a combination of problems with Couatl - failure to exit when FSX exits normally, and failure to connect to a new instance of FSX.

There are no problems in Couatl to exit when FSX exits normally, but it's normal that a previous not closes instance wouldn't be able to connect to a new FSX instance because, since another add-on has clearly broken the Simconnect pipe, broken communication pipes cannot be restored with a new session.

Can you try this simple test, and see if Couatl is closing correctly WITHOUT RUNNING ANY OTHER ADDON ?

If it does, than it's clear the problem is caused by another addon, and it should be easy to proceed by exclusion to know which one it is.

[pikalaxalt]

Alright, I will try running FSX without launching any external software and see what happens.  Meanwhile, the behavior of Couatl seems to suggest that it has no fallback mechanism for an unexpected loss of Simconnect.  What would make more sense is for Couatl to receive a Simconnect error (The sim is not connected), check the process list, and if it finds FSX attempt to connect to that instance of FSX, otherwise terminate.

[virtuali]

Meanwhile, the behavior of Couatl seems to suggest that it has no fallback mechanism for an unexpected loss of Simconnect.

Couatl has all the needed fallback mechanism to prevent an unexpected loss of Simconnect. There's a specific message it will print on the Couatl.LOG, saying "Has FSX crashed ?" in this case.

What would make more sense is for Couatl to receive a Simconnect error (The sim is not connected), check the process list, and if it finds FSX attempt to connect to that instance of FSX, otherwise terminate.

That's exactly what it does, but this is the easiest handling, which is obviously implemented. But that would cover only a case where Simconnect WILL issue an error message.

If there are more serious problems, like other add-ons cobbling the Simconnect communication channel, so no messages can go through, no Simconnect error message will even reach Couatl.

WHICH IS WHY, the Addon Manager has an ADDITIONAL safety precaution that, when IT closes ( it's a .DLL, so it WILL close when FSX closes ), it will check if there's still a Couatl.exe running, and it explicitly terminate it.

We used to have more reports of Couatl.exe not closing, but after having added this additional check in the Addon Manager, nobody ever reported it anymore, you are the only one that is reporting this since a very long time.

[pikalaxalt]

The failure of Couatl to exit occurs even when FSX exits without error.

I just ran some tests with my other addons.  It seems no single addon causes the symptoms.

It's possible that Addon Manager is encountering an unhandled exception, and it exits before running the "kill couatl" script.  If that were the case, where would Addon Manager store its panic log?

[virtuali]

The failure of Couatl to exit occurs even when FSX exits without error.

If another addon has caused the block of the communication

I just ran some tests with my other addons.  It seems no single addon causes the symptoms.[/qutoe]

You should run a test WITHOUT your "other addons", how you could possibly say if there's a problem with one, if you don't disable it first ?

It's possible that Addon Manager is encountering an unhandled exception

If with "unhandled exception", you mean Simconnect exceptions, the Addon Manager handles ALL of them which were sent in reply to a Simconnect request IT sent to Simconnect, and it will display a clear dialog box about it, together with a logged message in the log file, which is obviously the correct case, it would be wrong if the Addon Manager would even try to handle exceptions caused by other clients.

Exceptions caused by commands sent by *other* Simconnect clients, instead, should be handled by THOSE products instead so, if THEY are not correctly handling THEIR exceptions, it's possible that Simconnect might get instable or closed for communications, and if that happens, it's possible the Addon Manager code that kills Couatl, which is obviously called in response to the standard Simconnect CLOSE message, might not be executed.

Again, the one and only troubleshooting procedure, is the one I already suggested:

Can you try this simple test, and see if Couatl is closing correctly WITHOUT RUNNING ANY OTHER ADDON ?

This means, setting the <Disabled>True</Disabled> flag on each line of both the EXE.XML and DLL.XML files. Each line, save the bglmanx.dll and the Couatl.exe lines, of course.

[pikalaxalt]

Virtuali, I did run that test with no external addons and default trike, and got a successful exit, which is why I went ahead and performed the test one addon at a time and still failed to reproduce the problem.  It's only when running all the addons together that I experience the problem, however trying to narrow down exactly which addons are minimally required to cause the fault is a combinatorially hard problem.

EDIT: Also, when I tried installing the 2.12.15 update to the SA Addon Manager, couatl.exe was running from the previous FSX session, and the installer failed to close it; I had to override via Task Manager.

[virtuali]

Virtuali, I did run that test with no external addons and default trike, and got a successful exit

This clearly proves the problem wasn't anything in our programs.

which is why I went ahead and performed the test one addon at a time and still failed to reproduce the problem.

This seems to indicate there's not a specific problem between Couatl.exe and another specific addon module.

It's only when running all the addons together that I experience the problem, however trying to narrow down exactly which addons are minimally required to cause the fault is a combinatorially hard problem.

This should be easy to test, instead.

You said you enabled all addons, one by one, but if you enabled them one by one, with each addon singularly enabled, this won't catch the combination issues, that's why you weren't able to reproduce the problem,

What you should do, instead, is to enable all add-ons, one by one, but keeping the previously tested add-on ENABLED, so you are progressively increase the number of modules loaded. This way, it should be fairly easy to catch WHEN the conflict happens.
 

EDIT: Also, when I tried installing the 2.12.15 update to the SA Addon Manager, couatl.exe was running from the previous FSX session, and the installer failed to close it; I had to override via Task Manager.

That's normal. The installer checks for it, and it tries to close, but it not always succeed.