GSX error on Pushback

[ACSoft]

I updated to version 2.9.6 and in my 1st flight, during the pushback, I had a sudden Couatl crash with the included error message. I have also attached the file Couatl.err.txt which was linked with the error message.

After posting this, I will try to reproduce and come back here, if I found something more.

[virtuali]

It would be best if you enabled logging, because the panic file doesn't include everything. The only thing I noticed, is that you have two airport profiles in conflict:

Loading user customizations from C:\Users\Alain\AppData\Roaming\Virtuali/GSX/MSFS\LFSB-d13fd2.ini
Loading user customizations from C:\Users\Alain\AppData\Roaming\Virtuali/GSX/MSFS\lfsb-FSDT.ini

One you made, and the default we supplied with the scenery, which changes you made, exactly? Something related to pushback?

[ACSoft]

I have customized some gate, but nothing in relation with pushback, that's all.

2 airport profiles "in conflict" !?!

How can these profiles be in conflict, I mean I thought it was perfectly legal to have multiple profile (see screenshot) and to choose in the editor, which one you want to use, no ?

EDIT:
One more question:
Is this booter "couatl64_boot.exe" really mandatory ?
by curiosity, I tested and apparently it work as before, without the booter.
Personnaly, I had no problems at all with Couatl64, previously to this new version.
No crash, no loading failure, but now, I suspect this booter to provoke the problem I had.

EDIT2:
Have activated logging per your advise, so if the problem occur again we wiil have all informations.
Now, to say, I made already several departure tests on LFSB, including pushback, but didn't had the crash again.

[virtuali]

How can these profiles be in conflict, I mean I thought it was perfectly legal to have multiple profile (see screenshot) and to choose in the editor, which one you want to use, no ?

Sure, it's legal, but it can be confusing, and because unless you said at least once which profile you wanted to use, so the program saved your preference, the profile loaded would have been depending on the directory order so, in case of profiles made for different airports, it might not be what you expects.

Since that was the only thing unusual in your log (which is partial), I pointed it out, so it might have offered a hint.

No crash, no loading failure, but now, I suspect this booter to provoke the problem I had.

It's highly unlikely it was the booter, especially since you said you never had issues with random restarts, so the booter won't have much to do.

If you had, and by pure chance the couatl engine restarted in the middle of a pushback (very rare, not sure if anybody reported it), and some other combination of issue, like you restart it manually during the lag interval after which the booter decides to intervene, than MAYBE it might have something to do with it.

There's even a safety precaution to possibly cover this case: since the panic log opens Notepad, the booter won't try to restart automatically while Notepad is open, assuming you are reading an error message, so it won't interfere with that.

[ACSoft]

Umberto, thanks for the detailed answer.

Like I said in my last edit, fortunately, I didn't had any more crash. Probably, just an infortunate random and mysterious even !

Anyway, can-you elaborate a bit how the new "Couatl64_boot.exe" work ?

I have seen that this program create a "couatl64_boot.log" file, apparently overwritten on each new session. I had a look when I discovered it and remarked, for example, that I had about 20 consecutives lines "RESTARTNG couatl64_MSFS.exe" with a time stamp. As far as I remember, time separation was about 1mn between each even. Does this say something to you ?

So, it would be nice if you give us some details, so we can survey this log file, to see if everything is working as expected.

Thanks in forwards !

[virtuali]

Umberto, thanks for the detailed answer.I had about 20 consecutives lines "RESTARTNG couatl64_MSFS.exe" with a time stamp. As far as I remember, time separation was about 1mn between each even. Does this say something to you ?

Yes, it says the booter is doing its job, and now you DO have crashing issues. Try removing the Windows 8 Compatibility flag from Couatl64_MSFS.EXE, and see if the crashes stops.

The GSX menu open normally and I asked for Jetway connection from the GSX menu

Exactly, this is the kind of crash I sometimes get on a gate, which always go away by disabling Windows 8 Compatibility, but several users swear it made the program more stable for them, so we temporarily set it again, but we'll probably settle for not using it, since FOR ME (and likely for you) it works better in default, when no Compatibility flags set.

[ACSoft]

Funny, I was typing my new message for the new crash and suddenly all dissapeared ?

Apparently I do a mistake and maybe posted by error, or you intercepted my message ?

Anyway, I will keep my message & log files and do further tests, with the Windows 8 compatibility disabled, as you now advised to me. I really hope this will be the solution, because I am bit upset right now. As I told you before, I belonged to lucky user which never had problem with couatl not loading or crashing.

EDIT:
OK, Windows 8 compatibility removed.
Do-you want me to re-publish the previous message I removed, with the log files I saved ?
Or I keep it aside, just in case ?

[ACSoft]

Umberto, maybe Something interesting for you.

I redo almost the same flight. This time LFSB>LSGG (back to Geneva !) and obviously WITHOUT the Windows 8 compatibility this time.

As you can see in the 2 attached Couatl64_boot.log files, if the one corresponding to the flight LSGG>LFSB which had the W8 compatibility activated, has a multitude of "RESTARTNG couatl64_MSFS.exe" log lines, but in the log of the return flight, WITHOUT W8 compatibility, just one (probably the initial launch of Couatl64_MSFS.exe).

Therefore, I cross my fingers that my GSX returned to its previous great stability.

[virtuali]

Therefore, I cross my fingers that my GSX returned to its previous great stability.

That confirms my own findings: on a normal system, Windows 8 Compatibility is not required and, in fact, it's even worse.

Apparently, it's exactly the opposite for some users but, at this point, I suspect it might be caused by some other add-on that runs together with GSX that *does* require Windows 8 Compatibility itself, so there's a VC++ runtimes clash between the two, since loading different versions of the runtime (or the same version running in two different compatibility modes, which I guess it's even more complex) is causing some kind of conflict.

Not that this really matters: with the auto-restarter, it won't change much, even for those that needed Windows 8 Compatibility to prevent crashes in flight: what matters is GSX is available on arrival.