KMEM still crashing (CTD), FSDT please help

[virtuali]

But my crashes aren't G2D.. They are just random stupid modules.. Why...

But I think you had G2D.DLL crashes too. In any case, I think you are aware that you are the ONLY one reporting crashes with every module that seem random.

It always happens when KMEM is loaded

But nobody else reported THIS specific form of crashes.

Everybody that ever posted here, either had crashes in ntdll.dll/kernelbase32.dll (which we believe to have found and fixed them all), or it was GD2.DLL, which at least on Wise87 system was CLEARLY caused by the PoolSize = 0 line, which is a known dangerous setting.

Fact it's happening only at KMEM, doesn't mean there's anything wrong with it. It happened at KMEM only even on Wise87 system, but it might simply mean the problem happens only when the scenery is particularly demanding, which of course is a combination of all addons installed and your graphic settings too.

[Hnla]

Yes I am aware I am the only one. I guess the hard truth is there is no solution.

[virtuali]

Yes I am aware I am the only one. I guess the hard truth is there is no solution.

Do you have a chance to try another sim, like FSX:SE or P3D ? Or, try FSX on another system ?

[Hnla]

Yes I am aware I am the only one. I guess the hard truth is there is no solution.

Do you have a chance to try another sim, like FSX:SE or P3D ? Or, try FSX on another system ?

I don't.... Would you be willing todo a quick teamviewer now if you have a second?

[virtuali]

I don't.... Would you be willing todo a quick teamviewer now if you have a second?

Ok, send me a PM with the session id

[virtuali]

Just had a Teamviewer session with Hnla. His problem was different, since he had random crashes from any modules, like fsuipc, etc.

I checked his DLL.XML and EXE.XML file and, especially the DLL.XML, was probably the most crowded and full of stuff I ever seen. Dozen of 3rd party modules, all loaded together, so it was a miracle that FSX even started, and of course, each of them takes some memory, there was a separate DLL for *each* OrbX scenery, talk about efficient memory usage...

However, I tried disabling *every* 3rd party module there, except bglmanx.dll, Couatl and SODE, which are all required by KMEM. In addition to that, I excluded the whole FSX folder from the antivirus.

And sure enough, on the next restart, I was able to start KMEM and use it for some time with no errors. I loaded the Aerosoft A320, and started GSX servicing.

Hnla went away in the meantime but, while he was away, I kept FSX running, and I did it from 1:13 ( my time ) to 2:00. It ran continuously with no crashes, made a complete GSX service and Pushback and using SODE jetways too, then I quit the sim normally, which ran over KMEM for 47 minutes with no errors, and then I just quit the session, because it's 2:07 AM here (talk about "not investigating"...)

So, even in case of Hnla, it's confirmed the problem it's NOT KMEM, it's just happening there, likely because, with such an ungodly amount of 3rd party modules loaded, FSX might just have ran out of memory, which might happen at any other detailed scenery.

It's also possible the problem is just a single module but, following Hnla report that crashes happens at random everywhere, I'd be more inclined to believe it's just a low memory issue. And, with so many modules installed, I couldn't possibly try all combinations, just restarting the sim every time a new module would be re-enabled would take hours, so I'll have to leave this to him.

But it's clear that, even in this case, it has been proven again there's nothing wrong with KMEM.

[Hnla]

Thank you for all your help.


Sent from my iPhone using Tapatalk

[por930]

Great support Umberto. You have gone beyond the call of duty here with your Teamviewer sessions.

I think is what is found in most cases, it is our own house keeping issues that are our downfall. We do not realise just how many modules get loaded each time we fire up FSX. They in turn may trip over each other with their own priorities, steadily sucking away the available RAM, so that "if" an error occurs before the whole program loads, causing it to crash at what ever module it happens to overload, the "random" appearance of the crashes, and no OOM warning.

I recall quite some time ago having a program that let you see what modules were loaded into FSX...need to work out what it was.   

[Hnla]

Well looks like my crashes are still there.

Will all of my modules in dll.xml disabled in exception for FSDT and sode ones, I still got a crash:

Faulting application name: fsx.exe, version: 10.0.61637.0, time stamp: 0x46fadb14
Faulting module name: g2d.dll, version: 10.0.61637.0, time stamp: 0x46fadb58
Exception code: 0xc0000005
Fault offset: 0x0001b92e
Faulting process id: 0x2f8
Faulting application start time: 0x01d1ee5594b87dd3
Faulting application path: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\fsx.exe
Faulting module path: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\g2d.dll
Report Id: 96728803-5a49-11e6-b937-8c89a51aac22

[por930]

Some users find if FSX is located in the program folder, permission issues can be an issue and did you follow Umberto's advice re post #265,

"[BufferPools]
PoolSize = 0

Yes, I know that on some sites, this is a suggested fix to obtain better performances but, it's very well known to be risky and increase the chance of crashes, when the VRAM usage is high, which is *normal*, with a scenery like KMEM, because it has been purposely designed to rely a lot on the video card ( they become faster and faster every year ) and less on the CPU ( they don't increase in speed so much and are difficult to replace ).

So, I just commented out the PoolSize = 0 line (removing would be the same), which would cause FSX to use its own internal default value ( 4MB ) and sure enough, the G2D.DLL crash went away!!"

FSX seems to have a life of its own. One minute, all great, then, bang, for no reason? it just quits again.

[virtuali]

Well looks like my crashes are still there.

Will all of my modules in dll.xml disabled in exception for FSDT and sode ones, I still got a crash:

I'm sorry, but I didn't had ANY crashes with all your modules disabled. I used your PC for more than 1 hour and it never crashed.

And, the GD2.DLL crash is caused by the PoolSize=0 line in the FSX.CFG. Yes, you said you don't have it, but I haven't checked it so, please, be sure you check it again.

I already gave you all the possible assistance you could ever ask for. I can only suggest to reinstall your system entirely.

[virtuali]

FSX seems to have a life of its own. One minute, all great, then, bang, for no reason? it just quits again.

No, it doesn't. Everything has a reason to be happening. This is not dark magic. More on the PoolSize = 0 issue: we made further tests, on two different systems, one with FSX:SE and another one with FSX+SP2.

On the system with FSX:SE, setting PoolSize = 0 doesn't cause any problems, even when switching to Full Screen and back. This with a GTX980 with 4GB of memory.

On the system with FSX+SP2, setting PoolSize = 2 caused an immediate crash when switching to Full Screen. This on a GTX970 with 4GB of memory (which are really 3.5, but I don't think it matters). No problem switching to Full Screen and back when the tweak is removed, which is what FSX defaults to.

It's likely FSX+XPack is the same of FSX+SP2 in this regard, and this could possibly mean one of the following:

- FSX:SE fixed this bug

OR

- FSX:SE ignore the setting because it's known to be dangerous so, if you set it to 0, it will use a default

In both cases, it's clear enough the problem is NOT KMEM, as we believe to have proved it already.

User saying "but it happens only at KMEM", it's JUST because it's a sophisticated scenery using a lot of high quality textures and materials, lots of vertex shaders ( the human animations and the SODE jetways ), so it REQUIRES the graphic sub-system, which is a combination of the drivers used and the video setting used, to work in top shape.

[por930]

Yes, you are correct Umberto, not "dark magic". We meddle too much and a simple change, or an omission to do some thing can cause all sorts of issues.
BTW...off topic..Love the anticipated time for follow me car notice on latest update of GSX. I often wondered if it forgot me^^^

[Hnla]

Did some more testing, and it seems that It only crashes with the PMDG 737NGX... I didn't crash with you for the team viewer session because you selected the Aerosoft Airbus.

I did a complete reinstall and it still isn't resolved.

Now the CTD is consistently G2D.

[virtuali]

Did some more testing, and it seems that It only crashes with the PMDG 737NGX... I didn't crash with you for the team viewer session because you selected the Aerosoft Airbus.

Which further confirms the problem is not KMEM itself, likely because with such a memory-hungry airplane, is more likely it could exhaust resources and/or VRAM, which is related to the G2D.DLL crash.

Try to reduce the texture size to 1024x1024 and see if it improves.