FSDreamTeam forum
Products Support => GSX Support FSX/P3D => Topic started by: pikalaxalt on January 22, 2015, 01:01:34 am
-
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.
-
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.
-
Hmm, very odd... This time, Couatl exited normally. No settings were changed.
I definitely have the latest Addon Manager, since I recently reinstalled KLAX.
-
Alright, the problem has resurfaced without me changing any settings on my end.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
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, 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.
-
I'm going to try a different approach. I normally start all my addons (activesky, fsrealtime, vafs5, and vpilot) before starting FSX. Normally, if ActiveSky downloads an updated module and then tries to load it in while FSX is running, it fails to load the module. On top of that, Windows becomes extremely sluggish at launching new applications while FSX is running, which is why I've gotten into the habit of launching FSX with all my other addons already running in the background. Today, I started all my addons after FSX was already running, and this time Couatl exited normally with FSX. So perhaps the culprit is not which addon, but when. I will continue to use this approach until I encounter this problem again.
-
So perhaps the culprit is not which addon, but when. I will continue to use this approach until I encounter this problem again.
We have a confirmed issue with the GoFlight modules. They work together with our modules only if you load them manually after FSX started. So, maybe this is your issue, or another product is behaving the same.
With regard with the GoFlight module, I *think* the main issue is that they compiled using the VS2010 ( or VS2012, not entirely sure ) compiler, so they are getting a dependency on the VC++ 2010/2012 runtimes. But also, as any FSX addon that is also a Simconnect client, they also get a dependency on the VS2005 runtimes, because they brought the Simconnect library too.
This issue is not very well known amongst developers, but according to the very long and complex explanation on this site:
http://siomsystems.com/mixing-visual-studio-versions/
Having dependencies on multiple versions of the VC++ CRT runtimes in the same program IS asking for trouble.
Which is why, all our modules are still compiled using VC++ 2005, so they are only dependent by ONE runtime, the 2005 version, which is the same used by FSX and Simconnect.
The loading order CAN affect this, because the way the (very complex) Windows side-by-side loading system works, it's supposed to TRY to allow multiple versions of the same .DLLs running together in memory, and this will work or not, depending on the loading order of modules.
Not sure if you have the Goflight modules, but perhaps the same issue is valid for other modules too, I see that many developers use different versions of the VC++ libraries quite liberally, without worrying so much of the potential issues when running together.
-
I don't have any GoFlight products, and I have completed another flight where Couatl failed to quit after a normal FSX exit despite waiting until after pressing "FLY NOW" to launch my external addons.
When I get the chance, I will perform some tests where one of the four external addons is not running. I've excluded VAFS5 as the cause, as the problem exists even when VAFS5 is not used.
-
I don't have any GoFlight products, and I have completed another flight where Couatl failed to quit after a normal FSX exit despite waiting until after pressing "FLY NOW" to launch my external addons.
Which is why, I said "Not sure if you have the Goflight modules, but perhaps the same issue is valid for other modules too". You probably have another addon with a similar problem.
and I have completed another flight where Couatl failed to quit after a normal FSX exit despite waiting until after pressing "FLY NOW" to launch my external addons.
Then it means the offending one is one that starts with FSX automatically, it cannot be anything else, since you said yourself that "I did run that test with no external addons and default trike, and got a successful exit". You only need to find one, testing them one by one, and adding them one by one.