And I would think that FSDT would want to try and kill this error for good, however it doesn't see like they can get a good handle on it.
Haven't you read the previous message by skipy33 ? We had our Teamviewer session, and I couldn't replicate the crash he reported.
However, he later found the test configuration we were using was not the one he always used, and was missing one line containing some SODE objects needed by other airports ( not FSDT's ). When he added it, the crash reappeared on his system.
He also found the crash happened ONLY if BOTH the lines for
non-FSDT SODE objects AND the lines for the APController objects (used by Aerosoft SpliX and Prag) were present.
So, in the end, even this other report confirmed there's NOTHING to fix on KMEM. If anything, it seems to be some kind of conflict between
non-FSDT SODE objects and XHT APController, something that would likely happen in any other airport using SODE.
The only thing we can do, is to report it to Jeffrey Stahli (SODE's author) and/or the APController developers, perhaps they'll find why it could happen. Looking at the Aerosoft problems, it looks like APController has its own good share of problems...
Note that, he always said the crash was in G2D.DLL, which was a crash reported by several users.
You, as of today, are still the ONLY one reporting a crash with G3D.DLL but this was just an example of how something that would really LOOKED like a "KMEM problem", was in fact something entirely different and unrelated to it, with the exception that KMEM is just another scenery that uses SODE.