FSX:Steam freeze after landing at MDPC requesting services

[p3dx3]

That still does not make much sense to me, why would I have memory issues when starting on the ramp with a default aircraft? When I can fly routes using the PMDG aircrafts that are heavy on VAS multiple legs at a time without any issues as long as I do not call up GSX. Either there is something wrong with GSX dealing with afcad files created in ADE, or something in my ADE is broken when compiling afcad files that is causing GSX to crash when reading them.

[virtuali]

That still does not make much sense to me, why would I have memory issues when starting on the ramp with a default aircraft?

That's the only explanation which is consistent with what we observed so far:

- When we had the Teamviewer sessions, you were never able to show me a crash with GSX, once you disabled the modules from FS Labs, by simply placing the plane on an airport and call GSX there.

- You later said it only happens after landing.

Since GSX doesn't behave different, and it creates the same objects, the only possible explanation that makes an "after a landing" different, is the memory usage and fragmentation caused by the flight itself.

When I can fly routes using the PMDG aircrafts that are heavy on VAS multiple legs at a time without any issues as long as I do not call up GSX.

If the memory-hungry airplane already placed you CLOSE to exhausting VAS, calling for additional objects it's the proverbial "straw that broke the camel's back" which placed you in an OOM situation.

Either there is something wrong with GSX dealing with afcad files created in ADE

Which cannot be, otherwise we would have thousands of similar reports, since 90% of the AFCAD out there are made with ADE.

or something in my ADE is broken when compiling afcad files that is causing GSX to crash when reading them.

You never said it only happens in AFCAD YOU made yourself! Is this the case ?

[p3dx3]

I will keep testing it looks that my system was the issue. FSX Steam installs a version of the uiautomationcore and I tried v16386 in my Windows 10 install. 2 days of successful flights after moving from v18000 of the .dll file. I am sorry Umberto for wasting all your time!

[virtuali]

I will keep testing it looks that my system was the issue.

This was abundantly clear right from the start, surely after we had our TM session...

FSX Steam installs a version of the uiautomationcore and I tried v16386 in my Windows 10 install. 2 days of successful flights after moving from v18000 of the .dll file. I am sorry Umberto for wasting all your time!

Several years ago, GSX installed what it was universally considered a safer version of the uiautomationcore.dll automatically, so users won't mistakenly assume that "GSX crashed their FSX" but then there was an uproar of protests, so we removed this in later versions, so now we must take the risk that, by NOT doing that, users will STILL mistakenly assume that "GSX crashed their FSX"...It's a battle we really cannot win.

The only sensible solution would be: update to P3D, because FSX is becoming a big mess of unreliability. One of the first thing LM got rid of, was the user interface, which uiautomationcore.dll is part of.

[p3dx3]

Okay but steam installs that same safe version. I had to use v16386 and remove the steam installed v18000. Did not think that had to be done I thought steam had everything fixed.

[virtuali]

Okay but steam installs that same safe version. I had to use v16386 and remove the steam installed v18000. Did not think that had to be done I thought steam had everything fixed.

So, it seems the Steam installer installs the same version we USED to install in our old installers (dated 2013). If you read that long thread here:

http://www.avsim.com/topic/421820-wrong-version-of-uiautomationcoredll/

You'll see that, while most of the users reported v18000 is the safest, it's still not 100% confirmed, because *some* users said it worked better with other versions.

But in any case, it's not relevant to our installers anymore, since we don't install that .DLL anymore since September 2013: it's just too risky to do it, because there's no sure fix. You seems to be in the minority of those that found their FSX more stable with the older v16386 version.

[p3dx3]

Came back and installed this scenery again. Edited the afcad in ADE

There is an error with a taxi sign name, ADE refuses to compile.

I[GG]m09-27

GG changed to G and compiles

This was crashing GSX I would not be shocked. The scenery is TropicalSim MDPC 2016