KMEM still crashing (CTD), FSDT please help

[virtuali]

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.

[skipy33]

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.

Hi Umberto,

The fact is that on MY system the use of simobjects from both SODE and XHT (remember I always disable APcontroler.exe when using SODE, I'm talking of simobjectpaths in Fsx.cfg) has a negative impact only with KMEM.

I agree XHT and SODE developers should discuss together but on the specific use of SODE by KMEM (as KIAH has no trouble for example).

Best regards, Skip.

[Hnla]

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.

I highly doubt I am the "only one", more than likely a bunch of users have simply "given up" and stopped posting because the path to no crashes with KMEM seems to be non existent...

The G3D Crash I had was probably related to FSUPIC, however did YOU read my previous message? I got a G2D.DLL crash while loading KMEM. Doesn't matter who's "fault" it is, all I want to know is how to fix it.

[virtuali]

I highly doubt I am the "only one", more than likely a bunch of users have simply "given up" and stopped posting because the path to no crashes with KMEM seems to be non existent...

Please re-read my message carefully. You were ALWAYS the ONLY one with a G3D.DLL!! That's what I said. I never said you are the only one reporting of "any" problem.

And no, it's not that users are "given up", the very minor problems that were really a KMEM problem (and none of them caused the sim to crash) were fixed very fast, and you are not seeing any more reports now, because if you followed many threads, we always found the real cause was something *ELSE*, most likely the antivirus so, when users finally are convinced they MUST disable it, crashes go away.

Lots of user (just check the posts) came back to report their problem was fixed.

And in fact, what really happens on forum, is that even users that fixed their problem, DO NOT report back saying they have. That's why I'm quite confident the problem are fixed, because several users said they are (and I don't have any reasons to doubt them) and those that haven't, it's not because they have "given up", but because they just fixed the problem following the forum posts, and never came back to said it's all fine now.

The G3D Crash I had was probably related to FSUPIC, however did YOU read my previous message?

So you got a G3D crash, and thought it was KMEM, and now you have a GD2 crash ? The same crash that we found NOT to be caused by KMEM ?

I got a G2D.DLL crash while loading KMEM. Doesn't matter who's "fault" it is, all I want to know is how to fix it.

This sounds like "you should fix it even if it's not your fault...", which is like attributing to us god-like powers over any other developers software. I really like we could be able to do that.

The only thing we could do, is trying to alert the respective authors why SODE and XHT seems to have issues working together and apparently cause a G2D.DLL crash.

[Hnla]

You were ALWAYS the ONLY one with a G3D.DLL!!

Yep, that's really no secret. I never said other users had G3D errors either.

So you got a G3D crash, and thought it was KMEM, and now you have a GD2 crash ? The same crash that we found NOT to be caused by KMEM ?

I never said directly I thought it was KMEM. And yes, for the third time, I do have the G2D.dll crash now.

This sounds like "you should fix it even if it's not your fault...", which is like attributing to us god-like powers over any other developers software. I really like we could be able to do that.

The only thing we could do, is trying to alert the respective authors why SODE and XHT seems to have issues working together and apparently cause a G2D.DLL crash.

Your replies contain quite a bit of "fluff" and no substance. Your entire reply had no helpful information except, maybe, the last sentence... somewhat

[virtuali]

I never said directly I thought it was KMEM. And yes, for the third time, I do have the G2D.dll crash now.

And the only clear case where we found a consistent reason for it, is this potential conflict between XHT and SODE.

your replies contain quite a bit of "fluff" and no substance. Your entire reply had no helpful information except, maybe, the last sentence... somewhat

My reply contained two facts that seems to be clear about your TWO errors:

- The first one, G3D.DLL, you said yourself it was caused by FSUIPC so, why we are even discussing it ??

- The second one, the GD2.DLL crash, with the ONLY user that was willing to do a Teamviewer session with me, wasn't replicable UNLESS he later enabled both XHT and SODE object for non-FSDT sceneries.

[skipy33]

Hi Umberto,

I send an email to SODE team. Perhaps they could add a setting in SODE config to exclude unwanted simobjectpaths?

Extract of mail :
Is there a way (or a future way) to set a kind of "exclude simobjectpaths"  in parameters so SODE will not scan and use folders not used by airports using it? Here's my current fsx.cfg:

SimObjectPaths.0=SimObjects\Airplanes
SimObjectPaths.1=SimObjects\Rotorcraft
SimObjectPaths.2=SimObjects\GroundVehicles
SimObjectPaths.3=SimObjects\Boats
SimObjectPaths.4=SimObjects\Animals
SimObjectPaths.5=SimObjects\Misc
SimObjectPaths.6=E:\MyTraffic Professional\MyTraffic\Aircraft
SimObjectPaths.7=FsxAI
SimObjectPaths.8=C:\Program Files (x86)\12bPilot\SODE\data\SimObjects
SimObjectPaths.9=C:\ProgramData\12bPilot\SODE\SimObjects
SimObjectPaths.10=Aerosoft\Split X\simobjects
SimObjectPaths.11=Aerosoft\Mega Airport Prague\simobjects 

I'd like to exclude the 2 last paths and perhaps bypass the issue I have with FSDT KMEM. Today I have to remove them if I want to fly FSDT KMEM without Fsx crash.

Best regards,

Skip.

[Hnla]

And the only clear case where we found a consistent reason for it, is this potential conflict between XHT and SODE.

AND?? I don't have HXT.

- The first one, G3D.DLL, you said yourself it was caused by FSUIPC so, why we are even discussing it ??

I never said It was for sure caused by FSUPIC, I said it's a song possibility

- The second one, the GD2.DLL crash, with the ONLY user that was willing to do a Teamviewer session with me, wasn't replicable UNLESS he later enabled both XHT and SODE object for non-FSDT sceneries.

Well that doesn't apply to me.

[Hnla]

Now, a new crash while switching to Night at KMEM.

Faulting application name: fsx.exe, version: 10.0.61637.0, time stamp: 0x46fadb14
Faulting module name: d3dx9_34.dll, version: 9.19.949.46, time stamp: 0x4649415c
Exception code: 0xc0000005
Fault offset: 0x00154f9b
Faulting process id: 0x1110
Faulting application start time: 0x01d1cd9946e57746
Faulting application path: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\fsx.exe
Faulting module path: C:\Windows\system32\d3dx9_34.dll
Report Id: f5acca11-398e-11e6-949b-8c89a51aac22

[virtuali]

Hi Skip,

would you like to try a test ?

- Go into your FSX\Simobjects\Misc\FSDT_KMEM folder and edit the SIM.CFG with Notepad

- REMOVE the last line that reads like this:

module=SODE

It shouldn't make any difference, because none of our objects are actually "real" SODE objects (except for the jetways which are in another folder) so nothing from SODE should try to use them, but you never know if this might be a problem or not, so it's worth testing.

[virtuali]

Now, a new crash while switching to Night at KMEM.

It's really beginning to look like my whole FSX is screwed up. Or my entire computer for that matter

I think there's no need to add that the ONLY one that ever reported a crash into d3dx9_34.dll in this forum, was you, in another thread.

Instead, it's enough to make a google search with "d3dx9_34.dll fsx" and you'll see plenty of results, dating back years and related to all sort of different products.

[Hnla]

But why I am just getting random crashes with KMEM with random DLL's... I know I'm the only one.. Is my whole computer messed up???

[virtuali]

But why I am just getting random crashes with KMEM with random DLL's...

Our sceneries usually (and intentionally) require the video drivers and directx to perform flawlessly, because the put way more stress on the video drivers than any other scenery out there, and we always increase this from scenery to scenery, because we rely more and more on shaders features.

The obvious reason why we do that, is that video card power increase continuously every year, and it's easy enough to upgrade a video card, while cpu power (which other sceneries relies more onto) doesn't increase so much, and it's both hard and expensive to upgrade the cpu.

And, the increased reliance over the video card, results in our sceneries to perform SO MUCH better in P3D, due to its more modern graphic engine based on DX11 so, each time they optimized the gpu/shader code, we get a speed bump for free.

The side effect, is that if you have a problem with your drivers or your DirectX install, you'll surely notice it more at our sceneries, and KMEM more than the others.

I know I'm the only one.. Is my whole computer messed up???

Maybe it's just something related to DirectX and Video drivers. Some sites suggest to reinstall DirectX being sure it's the latest version.

Other things you can try are:

- reinstall the video drivers using the latest stable version, and doing a clean installation, to remove any non-default settings or tweaks.

- delete the FSX.CFG to let FSX create a new one from scratch, to exclude the chance the issue was caused by a tweak that doesn't work well with your system.

[Hnla]

OK- I think I may have solved the puzzle here...

So i updated my video card drivers and reset my FSX.CFG. I went back to FSX- and noticed that my crashes with KMEM were gone. I thought it must of been one of the two causing the problem...

Then I realized when I rebuilt my FSX.Cfg, It deleted the line enabling Mytraffic 2013, and I noticed there was no AI. So i added the line back in- re-enabling Mytraffic2013- and Bang.. I was able to produce the CTD again. Both at the same scenario and both G2D.DLL...

So it turns out that Mytraffic2013 has some sort of incompatibility with something.... surely this is useful to know for anyone else with CTD at KMEM...

[skipy33]

OK- I think I may have solved the puzzle here...

So i updated my video card drivers and reset my FSX.CFG. I went back to FSX- and noticed that my crashes with KMEM were gone. I thought it must of been one of the two causing the problem...

Then I realized when I rebuilt my FSX.Cfg, It deleted the line enabling Mytraffic 2013, and I noticed there was no AI. So i added the line back in- re-enabling Mytraffic2013- and Bang.. I was able to produce the CTD again. Both at the same scenario and both G2D.DLL...

So it turns out that Mytraffic2013 has some sort of incompatibility with something.... surely this is useful to know for anyone else with CTD at KMEM...

Hi,

I also use my Traffic X... I remember I made some tests with AI Traffic set to 0 and of course with mytraffic scenery disabled but always had CTD. Right now if I remove SplitX and Prag simobjectpaths I can fly KMEM without any CTD and with MytrafficX active (and lot of Fedex birds at ramp).

I'll made the test to remove only MytrafficX simobjectpath (and disable Mytraffic X scenery). If no CTD also it will means that we perhaps have a problem when SODE is loading KMEM with a large number of simobjects declared in Fsx?

I let you know. Skip.