After Boarding in GSX, opening FLIGHT ASSISTANT causes a CTD **SOLVED**

[Yellow11]

We have observed a reproducible CTD and report it.

If you run Request Boarding from the GSX Toolbar menu, complete it, and then open FLIGHT ASSISTANT from the Toolbar menu, it will cause a CTD.
This CTD does not occur even if Pushback, etc. is performed in GSX, but only when Boarding is performed in GSX.

I have not been able to verify exactly at what point in the Boarding process the CTD begins to occur, but I feel that if you try to open FLIGHT ASSISTANT after passenger boarding is complete and baggage loading has begun, it will cause a CTD.

In earlier versions of GSX, I was able to open FLIGHT ASSISTANT after GSX Boarding was complete without CTD, and my MSFS Community folder add-on configuration has not changed since then, so I believe the problem was caused by a recent GSX update.

[virtuali]

I tried to reproduce this, but couldn't.

- I called GSX Deboarding first, when the pilots went away, open the Flight Assistant menu, no issues, with or without the GSX menu opened at the same time.

- I then called Boarding, waited for the last passenger to board, open the Flight Assistant menu, no issues, with or without the GSX menu opened at the same time.

As already explained in so many threads about CTDs, you shouldn't forget we are in a "CTD week" so, anything you do in the sim is unpredictable, especially when crash/hangs are concerned, they can happen at any time, randomly.

Be sure you applied the fix suggested by Microsoft:

https://forums.flightsimulator.com/t/fix-for-ntdll-dll-crashes-on-windows/538552

Personally, I never had a CTD, but I'm using SU10 Beta, in DirectX 12, and this configuration seems to be unaffected.

[Yellow11]

We are pleased to report that we were able to reproduce the CTD on the ASOBO A320 NEO.

It seems that the ULD customization in Customize Airplan is the cause of the CTD.

First, I performed Boarding without customizing ASOBO A320 NEO.
After the GSX menu showed Boarding completed, I opened FLIGHT ASSISTANT and the CTD did not occur.
At this time, the ULD Code of Cargo1 and Cargo2 of A320 is BELT.

Next, I set the ULD Code of ASOBO A320 from Customize Airplan in the same way as FBW A32NX, where the CTD can be reproduced.
Cargo1 is AKH and Cargo2 is AUTO.
Then I performed Boarding, and after Boarding completed was displayed on the GSX menu, I opened FLIGHT ASSISTANT and CTD occurred.

There may be other factors affecting this, so I will describe the procedure I verified.

• Create a flight plan in SimBrief.
• Set up the same flight plan in MSFS world map as in SimBrief.
• Spawn at the departure airport in ASOBO A320 NEO.
• Execute Customize Airplan from the GSX menu.
• Set Cargo1 to AKH and Cargo2 to AUTO and save.
• Execute Boarding from the GSX menu.
• Wait until "Boarding completed" is displayed on the GSX menu.
• Open FLIGHT ASSISTANT from the Toolbar menu.
• CTD

The attached virtuali.zip contains the gsx.cfg files for the ASOBO A320NEO and FBW A32NX customized with Customize Airplane.

In addition, this verification was conducted with the MSFS Community folder reduced to the minimum required add-ons in order to eliminate non-GSX influences.
The contents are GSX, FBW A32NX, Navigraph's Navdata, and LorbyAxisAndOhs_MSFS.

[Yellow11]

Since I am using SU9, I asked a friend of mine who is on SU10 beta to verify.
The result was that MSFS froze when I performed the same procedure.

[virtuali]

Since I am using SU9, I asked a friend of mine who is on SU10 beta to verify.
The result was that MSFS froze when I performed the same procedure.

I tried your test and yes, I could reproduce the problem.

It was more or less caused by GSX, because we had to use a spare variable which was sent to an *object* to perform an animation, in this case related to the movement of ULD containers.

Normally, when you use Simconnect to send variables to an object other than the user airplane, they either work, or they give an Simconnect exception if they are not supposed to be used, so we normally know exactly which are safe to use for Ground vehicles purposes and which aren't.

In this specific case, it seems that, even if the variable is being sent to an object ( the Cargo Loaders in our case), the simulator interprets it as it was meant for the user airplane, so it did work, but since it was precisely one related to the Fly Assistant categories, it confused the panel, causing a crash.

I've made a complete crash dump and I've sent it to Asobo, since the expected result when using a variable that is not meant to be used for a certain kind of vehicle should be a Simconnect exception, not an automatic routing of the variable over the user airplane without any feedback.

The fix on GSX side which uses a different variable we have tested in other objects to be working with no side effects is already online now on Live Update.

[Yellow11]

I was able to apply the Live Update and confirm that the problem has been resolved.
Thank you for a great add-on.