FSDreamTeam forum
Products Support => GSX Support MSFS => Topic started by: airbumps on March 13, 2024, 10:13:43 am
-
Hi All,
Last half dozen flights I've had GSX working perfectly on departure but when I approach my destination I've noticed that COUATL has crashed. Its happening with both the Fenix and PMDG and so far has happened at six different airport combinations across the USA.
I've turned on logging and attached two COUATL Log files.
Umberto, is there anything in these these log files that points to why this might be happening?
Cheers
-
Same experience.
-
Just enable the W8 compatibility modus for Coatl again. Is Coatl outdated software, I wonder? I just found a web diiscussion about it dating: April 2010.
-
Same here, and this is a new bug. Has never happened before.
-
Same here .... 8/10 flights gsx has not survived the flight (dont know if it dies on takeoff, landing or whenever... :;)
-
Happening to me too. Every flight. I land and I cannot select the gate without restarting COUATL and going through a whole lotta mess and waiting for it. It started immediately after the last 3/11 update.
-
Same here. 9/10 flights Coautl crashes sometime after take off and has to manually be restarted upon arrival.
-
Just set the mentioned Windows 8 compatibility and on first test seems to have done the trick.
-
Same here. Crash short after Take Off
Faulting application name: couatl64_MSFS.exe, version: 4.8.0.5390, time stamp: 0x65ef1a93
Faulting module name: clr.dll, version: 4.8.9181.0, time stamp: 0x64b85478
Exception code: 0xc0000005
Fault offset: 0x00000000000a88ac
Faulting process id: 0x0x19EC
Faulting application start time: 0x0x1DA784FE93112E5
Faulting application path: e:\Programme\Addon Manager\couatl64\couatl64_MSFS.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Report Id: 1a229602-ca65-4f5e-814c-35ba59edb45a
Faulting package full name:
Faulting package-relative application ID:
-
Just set the mentioned Windows 8 compatibility and on first test seems to have done the trick.
Is this a valid and proven workaround (can we get validation by FSDT perhaps if there is not a fix for this coming?)? And, can you by chance remind me how this is accomplished (if so)? Been a while since I had to fool with that kinda stuff in Windows. Thanks!
-
Just set the mentioned Windows 8 compatibility and on first test seems to have done the trick.
Is this a valid and proven workaround (can we get validation by FSDT perhaps if there is not a fix for this coming?)? And, can you by chance remind me how this is accomplished (if so)? Been a while since I had to fool with that kinda stuff in Windows. Thanks!
Find the location of the Couatl application (in my case it's Couatl64_MSFS.exe). It's in your FSDT Addon Manager folder. Right click "properties" and set Windows 8 under the "Compatibility" register (see screenshot).
Just doing a second flight now and will report back if it's still working.
UPDATE: Second flight also worked with the Win8 fix.
-
Is this a valid and proven workaround (can we get validation by FSDT perhaps if there is not a fix for this coming?)? And, can you by chance remind me how this is accomplished (if so)? Been a while since I had to fool with that kinda stuff in Windows. Thanks!
The validated fix was PRECISELY to DISABLE Windows 8 Compatibility mode, as indicated in the release notes of the latest update.
We enabled it months ago, because some users reported it worked better without it but, recently, there was an inexplicable crash that we could reproduce (after many tries), when selecting a service on a gate, with the program just shutting down with no errors.
After lots of test, it was confirmed on multiple system that, Disabling the Windows 8 Compatibility test completely fixed this crash, and we were unable to reproduce it afterwards, no matter how hard we tried, so we decided to remove the Windows 8 Compatibility flag, also because I assure the program is compiled with the native Windows 10/11 SDK and it's always updated with each Windows SDK update so, there's no reason why it should require Windows 8 Compatibility flag.
OF COURSE, as with anything related to Windows and MSFS, there might be so many other products running at the same time, and any of these might need some older version of the Windows runtimes, and it's known that, when two programs try to use different versions of the runtimes and are running together, there might be issues.
So, if the Windows 8 Compatibility flag works best for you, just enable it. We surely never designed the program to run with it (is not even clear on any Windows documentation what it really does), and it's sure that, after so many test, on all system WE could try, it's far more stable without it but, again, every system is different especially when so many add-ons run together all at the same time.
-
So will try to enable Windows 8 Mode .... thats weired, but if it helps ... lets go back to the good old times :P Better than a crashing GSX on each flight
-
Maybe Fenix2GSX plays a role in this?
-
Maybe Fenix2GSX plays a role in this?
I had this the other day with 2.9.5, where COUATL / GSX menu was not working at the arrival airport for the first time. I was in the PMDG 737-700 and do not have anything Fenix installed.
-
I too have this problem with every flight now since the last update. The previous version worked fine apart from some random crashes. It happens somewhere between pushback and taxi in.
I'm using Windows 11 and I do not have Fenix2GSX installed. Happens with every aircraft. The Couatl.err lists no errors, but the event viewer shows:
Application: couatl64_MSFS.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an internal error in the .NET Runtime at IP 00007FFFE95A88AC (00007FFFE9500000) with exit code 80131506.
Faulting application name: couatl64_MSFS.exe, version: 4.8.0.5390, time stamp: 0x65ef1a93
Faulting module name: clr.dll, version: 4.8.9181.0, time stamp: 0x64b85478
Exception code: 0xc0000005
Fault offset: 0x00000000000a88ac
Faulting process id: 0x0x12B8
Faulting application start time: 0x0x1DA791A88E7483A
Faulting application path: F:\Program Files (x86)\Addon Manager\couatl64\couatl64_MSFS.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Report Id: 3c2ab4c0-fcea-49cd-a450-671a2c6ecbe8
Faulting package full name:
Faulting package-relative application ID:
-
It would be useful if everybody that posted here reporting a crash in midflight, provided the following information:
- If you use Windows 10 or 11
- If you closed the GSX Toolbar menu after takeoff, as suggested in the manual.
- If this improves if you re-enable Windows 8 Compatibility option for the Couatl engine.
-
I use Windows 10. I do always close the GSX toolbar.
Haven't had the opportunity to test the compatibility setting yet but did just change it - will retest ASAP.
-
The information you requested:
- I use Windows 10.
- I did not close the GSX toolbar on the last flight (sometimes forget to do that).
- I do not have the Windows 8 compatibility set.
Thanks.
-
It would be useful if everybody that posted here reporting a crash in midflight, provided the following information:
- If you use Windows 10 or 11
- If you closed the GSX Toolbar menu after takeoff, as suggested in the manual.
- If this improves if you re-enable Windows 8 Compatibility option for the Couatl engine.
- Windows 11
- Yes. Also tried with the option after 10k both ways (on and off), still the same.
- Yes
Problem seems consistent since one of the last two updates. Was fine (most of the time) before update.
-
I can confirm that at least for me, rechecking the box to force Win 8 compatibility seems to alleviate the bug on repeated flights. I'm not sure that's the best permanent fix, because I feel like the sim has gotten a little laggy since I did that. Maybe it's something else, I dunno, but I've done nothing else to mess with anything really, so I'm thinking maybe that is causing it. But at least it does fix the specific bug - that much I can say. I may switch it back after a few flights and see if the lag disappears (I know the bug reappears because I tested that).
For further info, I am using the Fenix A320 exclusively and the error is occurring regardless of how I engage with GSX (using the integrated loading or using manual GSX loading process). GSX worked virtually flawlessly prior to the last update for me for a very long time.
Hope all this helps you isolate the issue! Thanks.
-
I'm not sure that's the best permanent fix, because I feel like the sim has gotten a little laggy since I did that. Maybe it's something else, I dunno,
Compatibility mode on the Couatl program, which is a separate .EXE, cannot affect the simulator itself, because they run on completely separate threads so, even if for some reason our code would run slower, it won't have any effect on how the sim performs.
As an example, if GSX needs to calculate some pathfinding, to have a remote vehicle like Catering or Deicing coming to your airplane, if that calculation normally takes (this is just a made-up figure) 100msec (1/10th of a second) to make and, for some reason, the code became twice as slow, requiring 200msec, the only effect on the sim, would be the vehicle will appear and arrive 100msec later than normal, which of course nobody would be able to notice.
This is because the code itself is not running on the same process, so it's automatically running on a different thread, which in most cases means an unused core of a multi-core cpu the OS will assign it to, that without any special coding on our side. Even if we purposely slowed down our code, for example adding intentional pauses, even several seconds long, between each task, you won't see any effect on the sim, just our things will proceed with pauses in between.
In brief, we are UNABLE to "slow down the sim" with code. The only way we could slow down the sim is by populating it with too many objects at the same time and/or spamming it with so much Simconnect traffic, unti it breaks, which is something we are always careful not to.
In case, yes, the Windows 8 Compatibility mode is not a permanent fix, which I don't trust, both because there's no reason why it should work better but, most importantly, it's not very clear what it does, and in many cases, enabling it caused crashes in worse places than during a flight (where you don't even need GSX to begin with).
We are testing a completely different solution, quite like what Fenix does, of using a small and extremely simple "bootstrapper", which doesn't do anything other than starting the Couatl engine itself (instead of relying on MSFS), and it would just monitor it, and auto-restart it in case it crashes, all automatically. And will exit as soon MSFS quits, so it won't be resident in Windows.
-
- If you use Windows 10 or 11
Windows 11
- If you closed the GSX Toolbar menu after takeoff, as suggested in the manual.
Yes, its closed
- If this improves if you re-enable Windows 8 Compatibility option for the Couatl engine.
Without Windows 8 Comp ode -> Crash, all the time .... with activated Win 8 -> NO CRASH, never since re-enabling.
-
With the Windows 8 compatibility setting no crash indeed.
-
EDIT:
Version 2.9.6 has been released officially, no need for the Beta installer anymore.
-
Ran the installer and exe.xml seems to be configured correct. It mentions now couatl64_boot.exe instead of the couatl script engine.
But the couatl script engine was not started after firing up the sim. Trying to start couatl64_boot-exe manually did also not start it. Starting the script engine manually did.
Starting the scripting engine manually first and then starting couatl64_boot.exe manually does work. Then both processes are running.
At the end of the flight the script engine was still running and functional.
But this all was with the Windows 8 compatibility still configured. So maybe not a good test.
Removed the Windows 8 compatibility setting. Same behavior. As for not starting the couatl64_boot.exe nor the scripting engine.
-
We had two updates today, try downloading it again now.
-
The startup process seem to work fine now. Couatl64_boot.exe and the scripting engine are both running now after starting the sim.
At the end of the flight Couatl was available, but only by calling it from the menu on top. Not with the shortcut in TouchPortal.
-
At the end of the flight Couatl was available, but only by calling it from the menu on top. Not with the shortcut in TouchPortal.
Couatl is never called from the top menu, which will only open the GSX Menu so, if GSX is running (and from your report it seems it is), there's no reason why it wouldn't start if the top menu is controlled by another app.
Unless, this TouchPortal you are referring to, has a function to start Couatl directly, so it's unrelated to the top menu. If this is the case, you should either change it (if possible) to start or stop the couatl64_boot.exe instead, because if another app tries to stop couatl by itself, it will be re-started by the couatl64_boot.exe.
And yes, of course you can still close the Couatl engine if you need to but, you can do it ONLY from the "Exit" button of the Traybar notification area icon right-click menu. The couatl64_boot.exe recognizes it was intentionally closed in the proper way (so it wasn't an accidental quit/crash), so it won't restart it in this case.
-
Yes, you are right of course. The top menu does not start the script engine. Only the menu. I defined a shortcut for that and call that from TouchPortal. Maybe the sim was not in focus and that was the reason it didn't seem to work.
So, looking fine i think. Maybe some more people come with feedback.
-
Thanks for the update. It seems to have fixed whatever was going on. I went back in and removed the compatibility checkbox, tested - worked fine. With it in, it also works fine. COUATL stays up on landing in both scenarios. Personally, for me, leaving the checkbox unchecked seems to be a bit smoother for whatever reason, so I left it unchecked but either way, thank you!! Nice job. GSX back in business for me beautifully.
-
We'll probably settle for Win8 Compatibility disabled, since it seems more right to me, and with the auto-restarter, is not really a problem if it will crash in flight.
-
There is still an issue with the "clr.dll" module which crashes... when GSX is running and leaving the sim back to main menu....
its an issue with .net framework 4.8.xx and Win 11 ... any ideas (may you have an idea.... its not gsx which makes the sim crash i know, but when gsx is running msfs crashes due to the faulting module clr.dll