KMEM still crashing (CTD), FSDT please help

[pcubine]

So because you are unable to fix KMEM's problems, you say go back to default jetways LOL

It's not my airport. I didn't develop it. I am just trying to save you some heartache.

[Hnla]

So because you are unable to fix KMEM's problems, you say go back to default jetways LOL

It's not my airport. I didn't develop it. I am just trying to save you some heartache.

I am obviously talking to the only "heartache" here- (Umberto)

[virtuali]

So because you are unable to fix KMEM's problems, you say go back to default jetways LOL

If these "KMEM problems" go away by disabling it...it's best having static jetways than a crash. Several developers made airports with static jetways for years and they still do, and nobody complained about it.

But since this doesn't obviously happens to everybody, but just a bunch of users, it would be wrong to not have that feature in the first place.

In any case, I just had a Teamviewer session with another user today. He was affected by a crash in G2D.DLL happening 100% of the times at KMEM.

The first thing I did, was to disable *every* 3rd party module in the DLL/EXE XML files. And guess what, the crashes went away.

Next step was to enable each module, one by one, test KMEM, until it started to crash again. What we found was:

- With EZDOK camera enabled, the GD2.DLL crash happened 100% of the times.

- With SODE, but no EZDOK camera, the crash happened only once in a while, like 25% of the time.

Without EZDOK or SODE, but with all the other 3rd party modules re-enabled (PMDG, FSRecorder, ASN, Squawkbox), no crashes.

I tried everything, including sending him the next (still unreleased) version of GSX, which comes with a new Addon Manager and Couatl, but the ONLY way I could stop the crashes, was to disable EZDOK and SODE.

I'll try to discuss this with EZDOK and SODE authors, maybe they have some ideas and, perhaps, we might be finally able to reproduce it, which we haven't so far.

[Wise87]

Thanks for getting with the EZdok developers on this matter.


Sent from my iPhone using Tapatalk

[cosnowboarder_777]

Hi Umberto, I am not an EZdok user and I still have the crashes every time. It must be something else as well.

[Hnla]

So, they release a product, and integrate it with SODE, which is faulty. And we may never know what is wrong.

[virtuali]

Hi Umberto, I am not an EZdok user and I still have the crashes every time. It must be something else as well.

Yes, as I've said, sometimes (but not as frequently) it happens with SODE too so yes, there might be two different issues at the same time.

[virtuali]

So, they release a product, and integrate it with SODE, which is faulty. And we may never know what is wrong.

SODE it's used and existed well *before* KMEM.

And, this only happens to SOME users, if it happened to everybody, we would have the forum flooded by identical reports (I'm referring to the GD2.DLL CRASH ONLY), not just a couple of people.

And besides, you STILL haven't replied to my offer to have a Teamviewer session.

And, before you try the next reply, I'll stop you now: when I was in Teamviewer with this user, I also tried to send him a modified KMEM with NO SODE JETWAYS, which is the ONLY part with integrate with it. This because, opposite to what you think, I ALWAYS try to exclude things we MIGHT have done "wrong" first.

Unfortunately, it hasn't made any difference so no, it wasn't the "integration" with GSX.

And, I've already got a first reply from someone at Ezdok support, and they told me:

- The version we where using ( 1.18.5 Beta ) is no longer current, and it doesn't fully supply FSX Acceleration, so they suggested to update to the latest version.

- Both Ezdok and FSX should run "As Administrator", otherwise there WILL be crashes!

- The line that calls Ezdok in the EXE.XML should be the last one. Actually, the last one was SODE so, it's possible this loading order made the two crash together.

It's obviously clear that SOMETHING was wrong with the Ezdok installation, since it wasn't current, it didn't run As Admin and it wasn't the last line loaded. I'm just reporting what THEY told me...

[12bpilot]

So, they release a product, and integrate it with SODE, which is faulty. And we may never know what is wrong.

It is difficult to analyze the problem when one can not reproduce it. These are the first reports of this kind ever involving SODE, so troubleshooting takes some time...

Also, I can't think of a direct connection between g2d.dll and SODE, except for the menu items it adds to FSX, which are handled by that library as far as I know. I have sent out a SODE version that doesn't add menu items to FSX to Skipy and wait for his report...

[Hnla]

So, they release a product, and integrate it with SODE, which is faulty. And we may never know what is wrong.

It is difficult to analyze the problem when one can not reproduce it. These are the first reports of this kind ever involving SODE, so troubleshooting takes some time...

Also, I can't think of a direct connection between g2d.dll and SODE, except for the menu items it adds to FSX, which are handled by that library as far as I know. I have sent out a SODE version that doesn't add menu items to FSX to Skipy and wait for his report...

Are you a SODE developer? You Can you send anything to me and I will test out very fast as well.

[12bpilot]

Check your PM.

[Hnla]

Here is a new crash that I am able to produce 2 out of 3 times tested. I used the exact same scenario for each one:

Load up Default PMDG 737-700, load up KMEM At gate B42, and Set it to "Night" within FSX.

Faulting application name: fsx.exe, version: 10.0.61637.0, time stamp: 0x46fadb14
Faulting module name: bglmanx.dll_unloaded, version: 0.0.0.0, time stamp: 0x57694e42
Exception code: 0xc0000005
Fault offset: 0x6aa57720
Faulting process id: 0x11b4
Faulting application start time: 0x01d1d3173cbc35b5
Faulting application path: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\fsx.exe
Faulting module path: bglmanx.dll

[virtuali]

Here is a new crash that I am able to produce 2 out of 3 times tested. I used the exact same scenario for each one:

Load up Default PMDG 737-700, load up KMEM At gate B42, and Set it to "Night" within FSX.

What's a "default" PMDG 737-700 ?? It's either the default 737 or the PMDG 737...

In any case, I tried with the default 737, went to B42, and switched from Day to Night and then back to Day 10 times in a row. Not a single crash, of course...

I don't have the PMDG 737, but I have the 777 and did the same test. 10 times in a row from Day to Night and back. Not a single crash, of course...

So, it's clear the problem is happening on your system only and in fact, the ONE and ONLY report about the "bglmanx.dll_unloaded.dll" as a faulting module, came from YOU. Nobody else has ever reported it.

However, even if this problem clearly affects you and you only, it might be *possible* (since this one seems to be related to the Addon Manager) to at least understand what's happening, if we had a Teamviewer session, since we have a special debug version that we can try. But since you STILL haven't replied to ANY of my many offer to connect, I'm afraid you'll continue to post about your crashes without any way to solve them.

[por930]

Hnla, Stop the @#$%^& torture and have a Teamviewer session with Umberto. It may help solve the issue, especially if Umberto has a debug version to better help solve what is 'different' about your machine and trips it up. If you can at least isolate the problem, you will be a long way to find a solution.

[Hnla]

Well I PM'ed umberto asking todo Teamviewer and No response, so don't keep with this "stop the torture" nonsense.