FSDreamTeam forum
Products Support => Memphis KMEM Support FSX/P3D => Topic started by: Wise87 on June 04, 2016, 03:52:50 am
-
FSDT
I've spent the last 2 days trying to figure out why I'm having such a problem with Memphis and why I keep getting g2d.dll errors overtime I start up at KMEM. I know G2D.dll is not part of your scenery but anytime I start up. I can see it caching and loading and than the error happens. I spent the entire day loading over 30 different pay-ware airports to include all the FSDT scenery I own and not one did I get a crash on loading. I also tried tried flying into KMEM several times and pretty much every time I start to see the airport my sim crashes with the same error. I've tried default aircraft, pay ware aircraft, etc.
I made sure I have all the latest updates and my computer is only used for FSX. I have not had one system crash since I built it several months ago until I installed Memphis. I don't know what else to do. I really do like the scenery when it works but it's getting to the point I should uninstall it. Any help would be appreciated.
-
Just did a round trip flight and after landing and parking. CTD. Now when i try and load into KMEM. CTD
-
Just did a round trip flight and after landing and parking. CTD. Now when i try and load into KMEM. CTD
CTD doesn't mean anything. Please go into the Windows Event Viewer, to check WHAT has really crashed.
-
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: 0x00085da6
Faulting process id: 0xd30
Faulting application start time: 0x01d1be81a89eb18d
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: e3194608-2a75-11e6-85d6-54271e7a78ec
Faulting package full name:
Faulting package-relative application ID:
-
This happens if you run FSX. trike at KMEM. Then try to load into another plane. CTD. If i load in at another airport then move to KMEM. everything works a should.
-
Good to see I'm not the only one getting the G2D error.
-
NEVER had this issue prior.
-
From what I'm seeing more users are starting to report G2D.Dll errors and it only happens at KMEM. This tell me there is a problem, especially when it doesn't happen with other scenery. I hope they look into this because it is scenery related. Something is triggering it. FYI, I've only been using the FSX ultra light when loading so I know it's not a gauge.
Also to add, I will start FSX 10 times only only have KMEM load correctly twice out of ten. The error always happens as the scenery is finalizing loading then crash.
-
Now i cant even get to KMEM. I go to free flight and pick KMEM then fly now. CTD.
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: 0x00085da6
Faulting process id: 0x1430
Faulting application start time: 0x01d1be8906eb2a3b
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: 9973f107-2a7c-11e6-85d6-54271e7a78ec
Faulting package full name:
Faulting package-relative application ID:
-
I am having the same problem as well. Can't even load the airport now without it crashing from the g2d issue. Lets hope this gets fixed quick as it is extremely frustrating. the airport is unusable at this point.
-
I am having CTD from KMEM as well, except mine is from bglmanx.dll
-
Just finished a flight from FSDT JFKv2 to KIAH with 80% UT2. Sim ran perfect and never dropped below 25FPS. Rebooted my system to see what KMEM would do and BAM, g2d.dll crash. You have to love it. ::)
-
Yea, This one IS a issue.
-
2 days ago i install the demo, but always same CTD as you guys! Very sad.
Max
-
I am going to hope the silence from FSDT is them working hard on maing the scenery proper.
-
Just a followup on my KMEM experience. This is day 3 of using this scenery. Today I decided to give it another shot. I made no changes to my system. Today I was able to load up at KMEM 5 times with no G2D.dll errors. I figured I fly the same route that always crashed my sim as I stated before in earlier post. Today I was able to sucessfully fly from KSDF to KMEM on the Bluzz1 arrival to 36R.
I will keep flying this route to make sure this was not a fluke. I still think there is something wrong that needs to be looked at. Too many other users are still reporting the same issue.
-
I can do this, too - that is, fly from another airport TO KMEM. However, if I fly a route starting AT KMEM, by loading KMEM as the start airport, I get a fatal error. If I load to a random airport first, then load KMEM as the start airport, KMEM loads fine, and a complete flight works for me fine.
The big difference is either loading KMEM as the starting airport (fatal error) or loading a random airport first, let everything load in and settle, then select KMEM after the first random, but unnecessary, airport. I don't know enough about this error, or why it happens to give any other helpful info, yet.
-
While I am experiencing crashes too, I fear that this problem is not because of FSDT or of KMEM, but I fear that these crashes are from FSX responding to the scenery just overloading FSX in general..(.Again- this is of no fault of FSDT!) KMEM has been released, and BANG- we were presented with so many new innovative new features and FSX seems to trip and fall overtime that KMEM is loaded. Sometimes it gets back up for me.. but we have to accept that FSX just is plain and simple becoming unable to keep up with the demands..
It just sucks we have such an old sim... I haven't heard of Fatal Errors from P3D... maybe it's time for switch...
-
Damn dude, You a car salesmen? You're good.
When P3D isn't a Beta program. Then, Maybe ill switch. If KMEM is overloading FSX and crashing it. Guess what. Its a KMEM issue and needs to be "tuned and optimized " to work better with FSX, Since over 80% of simmers still utilize FSX as the primary software. If it cant be made to work with it, it shouldn't have been sold saying it would.
-
I am going to hope the silence from FSDT is them working hard on maing the scenery proper.
I cannot replicate either the G2D.DLL crash. In order to be able to start to investigate how to fix something, we would first need something or a procedure we can replicate.
I tried doing what has been suggested here, like starting a flight at KMEM or switch back and for to another airport, it doesn't make any difference, and I'm still unable to see any crashes.
My default flight in FSX starts at KMEM, and for the past month I started and restarted it hundreds of times per day. It where was a problem like that, it should be easy to spot.
HOWEVER, I would like to note that we all use FSX:SE, which is the current version of FSX. It's *possible* this might be a problem with FSX SP2 only, maybe it's JUST too much texture memory used, and FSX:SE is more conservative with memory.
Are you all using FSX-SP2 or FSX+Acceleration ? Is anyone using FSX:SE having crashes ?
A possible way to test this, could be reducing the Texture resolution, for example at 1024x1024, and see if it makes any difference.
-
FSX - Acceleration here.
I wonder if this video may help some. I'm not home to test it out.
https://m.youtube.com/watch?v=Ehap3i62GhM
Sent from my iPhone using Tapatalk
-
I am going to hope the silence from FSDT is them working hard on maing the scenery proper.
Are you all using FSX-SP2 or FSX+Acceleration ? Is anyone using FSX:SE having crashes ?
A possible way to test this, could be reducing the Texture resolution, for example at 1024x1024, and see if it makes any difference.
I have a post about My PMDG J4100 but I'm finding more planes with g2d.dll problems at KMEM , Mine crashes in both FSX+Acceleration and FSX-SE with the g2d.dll error manually setting the FSX.CFG to 1024x1024x32 had no effect . FYI My FSX_SE is running OEM textures and FSX all Orbx , both are running GSX, and Active Sky on NVidia GSX460 GPU's and Win7 Ultimate.
(ON Mine) FSX crashes wile your sitting at the airport watching the scenery loading and SE before you even spawn at the airport. FSX PMDG 744 works fine, Oem 744 doesn't
PMDG J4100 doesn't but the Majestic Q400 works fine. for the guys with some planes that work at MEM and some that don't, try loading your plane at a different field set you view to external then move to KMEM the Airport will load fine for Me with the J4100 until I jump back to the cockpit.
-
As I've said in my previous message, a possible way to test this, could be reducing the Texture resolution, for example at 1024x1024, and see if it makes any difference.
-
I also get g3d.dll crashes about every second time I load KMEM. I get the crashes mainly at daytime - didn't experience one at night yet. Texture resolution is at 1024x1024
The CTDs occur only when KMEM is loaded into the sim. No difference between starting a flight at KMEM or switching from another airport to KMEM. When KMEM got loaded successful with no CTD, I can maneuver around the airport without any problem. So either it crashes directly when KMEM is loaded or it does not crash at all. Standard aircraft were used for testing.
FSX with SP2
-
I also get g3d.dll crashes about every second time I load KMEM. I get the crashes mainly at daytime - didn't experience one at night yet.
This seems to be different, and it's the first report ever. Which version of the sim you use ?
-
I always fly with 1024x1024 textures set it the cfg! I have FSX SP2! And i do have the g2d.dll CTD! My sim crashes short after loading the airport! So that means the airport is not full loaded!
Max
-
Ok, right now, the only thing that seems consistent across all reports, is the crashes are happening mostly in FSX SP2 (maybe there's a connection between the strange objects in the air), but are very rare in FSX+Acceleration or FSX:SE or P3D.
-
Ok, right now, the only thing that seems consistent across all reports, is the crashes are happening mostly in FSX SP2 (maybe there's a connection between the strange objects in the air), but are very rare in FSX+Acceleration or FSX:SE or P3D.
Wrong, I use Accel, and I am getting constant CTD when the airport first loads.
-
Yup, What he said . I am FSX and Accel. Same CTD
-
FSX Accel here also if you missed it.
Sent from my iPhone using Tapatalk
-
I also get g3d.dll crashes about every second time I load KMEM. I get the crashes mainly at daytime - didn't experience one at night yet.
This seems to be different, and it's the first report ever. Which version of the sim you use ?
I use FSX+SP2. But I only had the chance to do about 6-10 test runs today. So my testing may not be sufficient yet. That the crashes only occured at daytime could have happened randomly.
-
Same problem. Randomly crashes after loading at daytime (FSX SP2)...
-
Wrong, I use Accel, and I am getting constant CTD when the airport first loads.
What do you mean "wrong" ?
I haven't said *nobody* uses Acceleration, but the vast majority of crash report are from SP2, you are one of the minority using Acceleration that are reporting a crash.
-
I take it your receiving emails about the same problem from folks who are not posting on the form?
Just to add when I get the crashes the last things I see is SOD message is complete and goes away and then the texture is loading then I see what looks like little pyramids all over the place as the final texture loads than it's followed by the crash notification. I'll try or if someone else can capture a video of that will help.
Sent from my iPhone using Tapatalk
-
then I see what looks like little pyramids all over the place as the final texture loads than it's followed by the crash notification. I'll try or if someone else can capture a video of that will help.
Ok, I understand.
Do you have this 100% of the time ? If yes, I would really like to have a Teamviewer session with you, because I wasn't able to replicate it yet. And I'm installing all sort of random stuff (airplanes, sceneries, etc.) in FSX, just trying to to make it crash, without success...
-
I'm not available until 1600 CST in the US. Over the last two days the crash has been hit or miss. No were near as often as it was the first two days. I would say I'm at 60/40 success rate. I do have a video were the scenery is loading but it doesn't crash on this one. Trying to capture next time it happens.
-
Hello Support,
FSX SP2 (ORBX, EZDOK), Crash...by KMEM Airport... see to video..
https://youtu.be/XgyOK4FBBF0 (https://youtu.be/XgyOK4FBBF0)
Name der fehlerhaften Anwendung: fsx.exe, Version: 10.0.61637.0, Zeitstempel: 0x46fadb14
Name des fehlerhaften Moduls: g2d.dll, Version: 10.0.61637.0, Zeitstempel: 0x46fadb58
Ausnahmecode: 0xc0000005
Fehleroffset: 0x00085da6
ID des fehlerhaften Prozesses: 0x1e7c
Startzeit der fehlerhaften Anwendung: 0x01d1c0c44176df9c
Pfad der fehlerhaften Anwendung: E:\Microsoft Games\Microsoft Flight Simulator X\fsx.exe
Pfad des fehlerhaften Moduls: E:\Microsoft Games\Microsoft Flight Simulator X\g2d.dll
Berichtskennung: f07bbc7f-2cb8-11e6-9007-24fd523a9978
I try by other KIAH, KJFK... work fine, problem for KMEM..!!
regard
Sebastian
-
I take it your receiving emails about the same problem from folks who are not posting on the form?
Just to add when I get the crashes the last things I see is SOD message is complete and goes away and then the texture is loading then I see what looks like little pyramids all over the place as the final texture loads than it's followed by the crash notification. I'll try or if someone else can capture a video of that will help.
Sent from my iPhone using Tapatalk
I've the exact same phenomenon. I also see something like little pyramids all over the airport seconds before the CTD occurs.
It also often looks like in the Video of EDDT-Sebi.
-
FSX SP2 (ORBX, EZDOK), Crash...by KMEM Airport... see to video..
Ok, it's not easy to see it very well, but it seems the crash happened *after* the scenery finished loading, right ? Please contact me by PM, I would like to arrange a Teamviewer session to have a look at it.
-
Yes, on my system it also looks more like it occurs shortly after loading is finished.
-
I won't be home till late and I believe VirtualI is in Europe. Somebody who is around please PM him so he can use team viewer to troubleshoot the problem.
Sent from my iPhone using Tapatalk
-
Are you making any progress on this issue? KMEM is basically a game of Russian roulette when trying to fly in or out of it.
-
Are you making any progress on this issue? KMEM is basically a game of Russian roulette when trying to fly in or out of it
I had a very long Teamviewer session last night ( it lasted until 2:05 AM my time ) with an user that had a 100% replicable crash at KIAH and KMEM as soon the scenery finished loading. According to the Windows Event Viewer, the crash happened in FSX.EXE, in the MSVCR120.DLL module.
After trying everything, including sending him different specially made test versions of the Addon Manager that included all sort of diagnostics, I started looking for conflicts caused by other modules.
And guess what, we found it was the Addon Converter X.dll. As soon we removed this from starting up, the crashes at start were gone! According to the description on its website, this module seems to be able to convert planes/scenery originally made for FS9 on the fly, while the sim is running, which seems to be a bit dangerous. Unfortunately, their support forum has been hijacked by spammers for years, so I guess there's nobody left at home to fix anything or give help.
He also had lots of AI originally made for FS9 (that's why he probably had the Addon Convert module installed in the first place) so he also had other *random* crashes, probably because of issues caused by specific AI models with issues, but they were gone depending on the starting gate or the starting time, suggesting it was something AI-related. He'll probably try to switch to a better AI traffic package, one made for FSX.
But with 0% AI or when we found a time/starting position where the supposedly botched AI wouldn't appear, GSX and the scenery were working perfectly fine, including SODE jetways.
I have another Teamviewer session scheduled for this evening, with an user having the G2D.DLL crash, hopefully we'll find something similar.
-
This is great news. I'm glad to see FSDT going the extra step to help the customer.
-
Thank you for doing this extra work Umberto. I hope you can identify the problem with the g3d.dll crash.
-
Yea, Thanks for working on the issue. All 3 of us that still use FSX will appreciate it when or if it gets fixed.
Yorik
-
Wonder if there was any progress on tonight's teamviewer session.
Sent from my iPhone using Tapatalk
-
I've got a message from the affected user, who said there wasn't any need to connect, since he fixed the problem.
So, of course, I guess it wasn't anything related to our software ( like it wasn't with the other user... ). I asked what it was, but haven't got a reply yet.
Note that, he had the G2D.DLL crash.
-
Ok, thank you - hope he will tell you what the problem was, and it could help the others, too. If not, I will try to find a scenario with replicable crashes on my system - maybe you could investigate that one. But I won't be able to do that during the next five days because of a major exam at university this week.
-
That's the thing with the g2d.dll error for me. Over the last two days I've only experienced it once now but I've been to KMEM a dozen times now. When it first came out I would get the crash every time. I have not made any changes to my system. I really hope someone who is still getting the problem gets with FSDT so they can troubleshoot the problem.
Sent from my iPhone using Tapatalk
-
I also get g3d.dll crashes about every second time I load KMEM. I get the crashes mainly at daytime - didn't experience one at night yet. Texture resolution is at 1024x1024
The CTDs occur only when KMEM is loaded into the sim. No difference between starting a flight at KMEM or switching from another airport to KMEM. When KMEM got loaded successful with no CTD, I can maneuver around the airport without any problem. So either it crashes directly when KMEM is loaded or it does not crash at all. Standard aircraft were used for testing.
FSX with SP2
The error you're reporting (g3d.dll) is different than the "g2d.dll" error reported by other users.
The "g3d.dll" error can often be resolved by running the Registered version of FSUIPC which includes a fix for this. If you're already running the Registered version of FSUIPC then it's got to be something else causing it.
I hope this is helpful for you.
Best wishes.
-
I sure hope someone else gets with Umberto on this issue. I would really like to know what is or was causing the conflict. Again with my schedule all this week and my g2d.dll error rate decreasing I don't make a good candidate compared to someone who is available and still gets the error every time.
-
Yesterday I volunteered for a session because i get g2d.dll error and I'm home sick so plenty of time...
-
Umberto, I am wondering if this problem has something to do with Ultimate Traffic 2 injecting AI aircraft (possibly made for FS9) into the airport parking spaces. The reason I ask is that I added a FDX airline schedule into UT2 and assigned some FDX repaints to downloaded AI aircraft and noticed that UT2 starting injecting FDX paints into the parking spots at the passenger terminals (not just at the Cargo ramps).
I too am getting the g2d.dll crash error and I started getting them after playing around with trying to get FDX AI at the airport. But I also got a crash that indicated ASEdata.dll was the issue and I am nowhere near any Aerosoft product. So perhaps the G2d.dll is the just the first thing windows grabs when trying to document the crash even though perhaps it is possible that g2d.dll (or ASEdata.dll) have nothing to do with it?
I have stopped UT2 from running the FDX AI and have yet to produce another crash.
I also run FSX with SP2 only. I am about ready to go to Steam as soon as I can figure out the best procedure for doing it and just how much has to be uninstalled before proceeding.
Mark
-
I also run FSX with SP2 only. I am about ready to go to Steam as soon as I can figure out the best procedure for doing it and just how much has to be uninstalled before proceeding.
Mark
Mark, just curious since you run FSX SP2, do you get the taxiway lines in the sky also or is your airport displaying ok?
A few of us SP2 guys in another thread have been getting the taxiway lines displayed vertically in the sky near the FedEx ramp when the airport loads. If your not getting them I'd be interested to know what your settings are to avoid it.
-
I also get g3d.dll crashes about every second time I load KMEM. I get the crashes mainly at daytime - didn't experience one at night yet. Texture resolution is at 1024x1024
The CTDs occur only when KMEM is loaded into the sim. No difference between starting a flight at KMEM or switching from another airport to KMEM. When KMEM got loaded successful with no CTD, I can maneuver around the airport without any problem. So either it crashes directly when KMEM is loaded or it does not crash at all. Standard aircraft were used for testing.
FSX with SP2
The error you're reporting (g3d.dll) is different than the "g2d.dll" error reported by other users.
The "g3d.dll" error can often be resolved by running the Registered version of FSUIPC which includes a fix for this. If you're already running the Registered version of FSUIPC then it's got to be something else causing it.
I hope this is helpful for you.
Best wishes.
Yes, sorry for that - I mean the g2d.dll - I mixed them up somehow. It did a check today, and it's always the g2d.dll, never the g3d.dll.
-
AirbusA330, do you plan I having a teamviewer session with Umberto?
Sent from my iPhone using Tapatalk
-
Yes, I am getting the taxi lines and floating objects too (taxi and runway signs). Been watching the discussion on that and hoping something in the way of a fix would come along. On my system, the lines disappear once you get close and the signage returns to earth as well. All reappear once I put some distance between them. I can see those taxi way lines in the sky on a 10 mile final to RWY 36.
Mark
-
No taxi line issues here. Just the occasional G2D.dll but I haven't experienced it int 2 days now. I am also running ultimate traffic 2.
Sent from my iPhone using Tapatalk
-
Still doing it for me every time. Whether I fly in there or load directly, crashes almost immediately.
-
AirbusA330, do you plan I having a teamviewer session with Umberto?
Sent from my iPhone using Tapatalk
I can't plan that the next days due to important exams at university. After that, it depends on Umberto. If he is interested in that, I would of cause do that.
-
I'm having the same problem, everytime a load kmem or near kmem ctd. If Umberto want i can teamview with him.
-
Umberto, I am wondering if this problem has something to do with Ultimate Traffic 2 injeting AI aircraft (possibly made for FS9) into the airport parking spaces.
I have stopped UT2 from running the FDX AI and have yet to produce another crash.
These two reports seems to be interesting and yes, it's possible.
G2D.DLL has usually something to do with Gauges but, it might be also used when processing textures, and using AI planes made for FS9 usually has issues with textures (for example, they appear white under DX10).
-
Hello All,
Seems I may have found the causes of the g2d.dll crash! It seems for me its Ezdok! If I start FSX then switch to task manager and close Ezdok then start a flight at KMEM the g2d.dll crash has stopped happeing! Once FSX is loaded just go into the Ezdok folder and restart Ezdok. I did have FSX crash upon loading FSX two more times after using this trick but they weren't g2d.dll. One was d2d1.dll and comsvsc.dll so possibly related to something else.
-
Back to the top.
-
I also use EZdok and UT. I don't see how it could be EZDok as it loads way before you even load an aircraft or select an airport. Also some users have reported the crash flying into Memphis from other airports. What I have seen on my system is if I make any updates with any part of of FSDT software I will get an initial g2d.dll error but after first restart I very seldom see the problem.
Example: I have the majority of FSDT scenery. The last one I bought was KMEM. Than I decided to by the older KFLL. After I installed KFLL I got the G2dll error loading up at KMEM. I had not seen the error in several days until I installed KFLL. I figured KFLL installed older files so I ran KMEM setup again. This time the sim loaded up fine at KMEM both times I tried. One strange issue I did see is even though I entered the registration information, I flew into KFLL from KATL and when I arrived the scenery was not active but it showing active and registered in the manager.
Sent from my iPhone using Tapatalk
-
Same problem here too.
On approach, around 5-10 nm from the threshold, while loading KMEM.
Taken off from KLIT with a NGX
FSX SP2, Active Sky, mid-end hardware configuration.
Best
Dom
-
Any update on this? Its obviously a FSDT KMEM issue.... Lets just get this issue resolved. Accept the issue is with the scenery and lets move forward. We can all forget that is wasn't ready for FSX on release. I'm sure we would all like to have the scenery working as opposed to getting a refund and giving the product back.
I would like to see a update for this error we are experiencing.
Thank you
Yorik C
-
Any update on this?
There has been many updates from our side. Almost everybody reported these has been fixed in several ways, either by installing the current version our our software but, most commonly, fixing/updating OTHER addons which were the cause.
Its obviously a FSDT KMEM issue....
Most of the users who reported their crashes fixed, confirmed it was something ELSE.
-
FSX SP2, Active Sky, mid-end hardware configuration.
This user said he fixed his crashes by updating ASN and FSUIPC:
http://www.fsdreamteam.com/forum/index.php/topic,13764.msg102158.html#msg102158
My crashes were from ASN and I just fixed them by a reinstall of ASN and FSUPIC
-
HMMMMMMM, Strange cause my sim was running just great up until the moment i installed FSDT Memphis. At which point i had to work for 2 solid days just to get the sim running. So, I am guessing all these other people probably had operational simulators as well. I don't know what happened to you in the last years but thing sure have turned "typical" in this forum. Another sim software company that blames everyone else for issues with the product the released not ready.
Now, Thank you for the news on fixing some issues and updating the software. I will run these on my PC and see how things go.
Yorik
-
HMMMMMMM, Strange cause my sim was running just great up until the moment i installed FSDT Memphis.
Are you still referring to the past ? Do you still have crashes NOW ?
At which point i had to work for 2 solid days just to get the sim running.
So it's running NOW, with KMEM too ?
So, I am guessing all these other people probably had operational simulators as well. I don't know what happened to you in the last years but thing sure have turned "typical" in this forum. Another sim software company that blames everyone else for issues with the product the released not ready.
I still are missing the point. I said two separate things:
1) We had several updates for KMEM during the last days. THIS part of the sentence means we surely had some issues, but we acted on them.
AND
2) There were many cases of crashes which were instead caused by conflicts with other addons. This IS fact. We acted on this, by suggesting users some potential causes and in some cases helping directly over Teamviewer, to identify which 3rd party product was the real cause.
This means, we did our part, but we are also blaming other software, because several of the reported crashes which were initially mistakenly attributed to some kind of problem with KMEM, were in fact NOT caused by it.
You are making it sound as if we refused to acknowledge ANY problem with KMEM, which is obviously untrue and the updates are there to prove it.
-
Just tried the latest installer, same issue, instantaneous g2d crash as soon as FSX finishes loading.
-
Great, just did the latest update and now I get the G2D.dll error again. It was working fine until then for a week. An I'm not uninstalling EzDok to get it it too work. Also to add, I disable EzDok and updated ASN, turned off UT2 and I still get the error.
Just a followup. After a reboot from the last update I was able to load KMEM twice.
-
Just tried the latest installer, same issue, instantaneous g2d crash as soon as FSX finishes loading.
The usual question: which other 3rd party modules you have installed ? Ezdok maybe ?
ASN ? Do you have the latest version of it AND the latest version of FSUIPC ?
-
What is it about EZdok that some think causes the g2d.dll error? Of all the hundreds of scenery for FSX why is it that KMEM is the only scenery that has the problem? Tons of users use EZdok. There has to be a fix if this is truly the case. I don't see this being Ezdoks problem since only KMEM is effected.
Sent from my iPhone using Tapatalk
-
Just tried the latest installer, same issue, instantaneous g2d crash as soon as FSX finishes loading.
The usual question: which other 3rd party modules you have installed ? Ezdok maybe ?
ASN ? Do you have the latest version of it AND the latest version of FSUIPC ?
Hi Umberto, I do not use EZdok, I do however use ASN. I did not have the latest FSUIPC installed. I updated to the latest. I noticed this time it took longer for the g2d crash to occur after that update.
-
Hi Umberto, I do not use EZdok, I do however use ASN. I did not have the latest FSUIPC installed. I updated to the latest. I noticed this time it took longer for the g2d crash to occur after that update.
So, clearly, FSUIPC had some part in it. Now, try with ASN, see here, the user Hlna said he didn't had crashes anymore after updating both FSUIPC and ASN:
http://www.fsdreamteam.com/forum/index.php/topic,13764.msg102362.html#msg102362
-
Hi Umberto, I do not use EZdok, I do however use ASN. I did not have the latest FSUIPC installed. I updated to the latest. I noticed this time it took longer for the g2d crash to occur after that update.
So, clearly, FSUIPC had some part in it. Now, try with ASN, see here, the user Hlna said he didn't had crashes anymore after updating both FSUIPC and ASN:
http://www.fsdreamteam.com/forum/index.php/topic,13764.msg102362.html#msg102362
Sorry Umberto, I forgot to mention I did update to the latest SP with ASN as well.
-
Hi All,
Same problem here with KMEM. I can start directly at KMEM stands to setup some startup situations with various aircrafts but today when trying LFPG-KMEM flight I had a CTD on final 36R. I made several tests taking off from a nearest airport and always had a CTD on final (36R, 09) around 6NM from touchdown with CLS DC10 and even Fsx Learjet.
I use Fsx Acc with latest ASN SP5, latest FSUIPC, FTX Global, EFB and iFMS. Texture maxload set to 1024 so around 2GB VAS available at takeoff. Latest test without ASN activated neither EFB.
I'd like to land at Memphis soon!!
Skip.
-
Hi All,
Same problem here with KMEM. I can start directly at KMEM stands to setup some startup situations with various aircrafts but today when trying LFPG-KMEM flight I had a CTD on final 36R. I made several tests taking off from a nearest airport and always had a CTD on final (36R, 09) around 6NM from touchdown with CLS DC10 and even Fsx Learjet.
I use Fsx Acc with latest ASN SP5, latest FSUIPC, FTX Global, EFB and iFMS. Texture maxload set to 1024 so around 2GB VAS available at takeoff. Latest test without ASN activated neither EFB.
I'd like to land at Memphis soon!!
Skip.
Error message from Windows 7 log:
Application Error: [1000] Nom de l’application défaillante fsx.exe, version : 10.0.61637.0, horodatage : 0x46fadb14.Nom du module défaillant : g2d.dll, version : 10.0.61637.0, horodatage : 0x46fadb58.Code d’exception : 0xc0000005.Décalage d’erreur : 0x00085da0.ID du processus défaillant : 0x2420.Heure de début de l’application défaillante : 0x01d1c96f34680e93.Chemin d’accès de l’application défaillante : E:\FsX\fsx.exe.Chemin d’accès du module défaillant: E:\FsX\g2d.dll.ID de rapport : 923ce49a-3564-11e6-a0a3-c86000cc4d68
-
I use Fsx Acc with latest ASN SP5, latest FSUIPC, FTX Global, EFB and iFMS. Texture maxload set to 1024 so around 2GB VAS available at takeoff. Latest test without ASN activated neither EFB.
Understand that "disabled", doesn't mean you just don't launch the ASN (or other products, that I never head of) user interface. Disabled means you DISABLE the associated .DLL your %APPDATA%\Microsoft\DLL.XML file, setting the <Disabled>True</Disabled> for each 3rd party module you want to test as being "really disabled"
Unless you do that, no module is really "disabled".
Please try again with all 3rd party modules disabled (in the DLL.XML file) and see if the crashes stops. Leave ONLY bglmanx.dll in the DLL.XML file and Couatl.exe in the EXE.XML file.
THIS IS JUST A TEST. I'm not saying you must permanently disable all your software, but that's how we proceed when finding the eventual conflicts.
-
You're right I didn't disabled ASN module. Ok I try without anything but FSDT modules and exe (without SODE).
Skip.
-
OK. Made the test without any .dll or .exe module except couatl.exe and bglmanx.dll (no SODE) and same CTD. I used Learjet 45 from KHEE direct to KMEM rwy 9 interception.
Any other idea? Disable all traffic AI? FTX Global?
Skip.
-
KMEM still has issues. Cant load in from a fresh reboot to KMEM without a CTD G2D.DLL while the scenery is loading. Have to load into another airport then go to Memphis and depart. FSX crashed on arrival to my destination with a python27.dll error CTD. SO, Flew from PANC - KMEM just now and guess what. CTD at 2,000 Feet on final for 09. Faulting module path: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\g2d.dll
NEVER EVER had this issue. Looks like you have some more work to do.
Last night i installed the KMEM from FSDT site. COutl is up to date and add on manager is brand new.
I am just about out of patience with this product. Sitting here for 20 hours of flying and not being able to land once... Not how i operate.
-
Last test for today:
- All modules actives (as it was crashing without during next try)
- All sceneries disabled except FSDT KMEM (no more FTX Libs)
1°) Start at KMEM 36C with learjet: Loading ok. I take off and fly 15nm away, save situation and go back without problem (KMEM remains loaded)...
2°) I stop the previous flight and load the situation saved just before (flying 15nm outbound). Turn 180° back to KMEM. CTD as usual when arriving 6nm inbound.
The problem seems to occur when KMEM is loading for the first time when arriving at 6nm.
I hope a fix will be find soon.
Skip.
-
The problem seems to occur when KMEM is loading for the first time when arriving at 6nm. I hope a fix will be find soon.
I just made the following test:
- Created a flight 15 NM south of KMEM
- Saved it as a default flight
- Quit from FSX
- Restarted FSX, and slewed to reach the airport until I was on top of it.
- Repeated this a dozen of times, allowing the whole airport to be unloaded and then reloaded very quickly, which is one of the most stressful testing you can do to *make* it crash.
- Tried with the default A321, then I repeated it again with the PMDG 777, several times, back and forth between the initial point at 15NM out and on top of the airport.
The results ? No crashes whatsoever. I had several 3rd party modules loaded, such as ASN, the PMDG modules, the Aerosoft modules, RAAS Professional, FSUIPC and FSRecorder.
While I was doing this, I was also logging all Simconnect events on a file, to check if any module caused errors. And guess what, there were some errors logged but, guess what, NONE of the errors came from any of our modules (bglmanx and Couatl.exe).
I had:
- Many FSUIPC UNRECOGNIZED_ID errors
- Some SODE OUT OF BOUNDS errors
- Some PMDG 777 errors which are clearly bugs: they mis-named some variables and have a duplicated event id.
- One UNRECOGNIZED_ID error from RAAS Pro
Again, NO errors of any kind from Couatl or Bglmanx.dll. The test lasted about 6 minutes, I wonder how many more errors I could log from those 3rd party modules and IF too many of them might cause a problem to the Sim, along the duration of a flight.
I think the only possible solution would be arranging a Teamviewer session, since I cannot replicate this in any way on my system. PM or email me for details.
-
Hi,
I think I have the same addons than you but the problem seems elsewhere. I performed another test with AI density set to 0 (because KMEM is very busy with Traffic X) and got the same CTD.
I'll give you my mail adress in PM and propose the following plan:
- Modify FSX settings around scenery quality (all are set to max in my configuration)
- Use a "light" simObjectPaths list is Fsx.cfg (Only default and SODE)
- Uninstall / Install KMEM
Regards,
Skip.
-
Note that I never had a G2D crash from KMEM to begin with. My crashes were from "Ntdll.dll" and "FSUIPC4.DLL", and a complete reinstall of ASN and FSUPIC fixed the crashes.
-
Hi,
Well after hours of testing I think I'm approaching the solution... It seems my CTD is related to AIRCRAFT_SHADOW setting in Fsx.cfg. When set active (1) and approaching to KMEM (first time airport is loading) I get a CTD. If disabled (0) no CTD. NOte than after several CTD the system is so dirty than CTD always occurs.
I have to confirm this result and check if ORBX is not linked to that issue. If I start Fsx on KMEM apron with aircraft shadow active no problem...
Skip.
-
Well never mind! I was doing a flight into KMEM and on Approach I got a FSX CTD, however it was caused by "G3D.DLL"...
-
That's interesting to know but, when I made the test, I had the airplane shadows enabled. I did it again just to confirm it, and I cannot see any crashes approaching the airport with aircraft shadows enabled.
Do you have FSX SP2, Acceleration or Steam ?
-
Hi,
FSX Acceleration. I tried to take off from KHEE with aicraft shadow on and set it off before heading to KMEM... And got the CTD. I'll make to more tries:
- One manually setting shadow to off before loading the flight at KHEE
- One with shadow on but at night.....
Skip.
-
Hi,
FSX Acceleration. I tried to take off from KHEE with aicraft shadow on and set it off before heading to KMEM... And got the CTD. I'll make to more tries:
- One manually setting shadow to off before loading the flight at KHEE
- One with shadow on but at night.....
Skip.
1st result at night: Shadows enabled in fsx.cfg. take off from KHEE then approaching KMEM heading 090. At 10NM couatl or bglman disabled shadows. No CTD. I crossed a strange "blurry wall" appeared suddenly at 6NM inbound MEM VOR. Landing OK rwy 09. Shadows automaticaly actvated (as usual on some FSDT sceneries).
It seems CTD occurs by day when FSDT automaticaly changes shadows setting when it is set in Fsx.cfg at FSX launch (so changing the setting manually after FSX starts has no effect on CTD). Have to confirm tomorrow.
Good night.
-
It seems that this airport is too complex for Flight Sim... oh well. Shame it's so beautiful. Time to uninstall
-
It seems CTD occurs by day when FSDT automaticaly changes shadows setting when it is set in Fsx.cfg at FSX launch (so changing the setting manually after FSX starts has no effect on CTD).
It occurs on YOUR system!! I made all the possible tests, and there's are no issues whatsoever with the automatic enabling/disabling of the airplane shadows the Addon Manager does like ANY other FSDT scenery. I don't have any crashes, regardless if the shadows were enabled or not in the FSX.CFG
Note that, the FSX.CFG itself is not touched by the Addon Manager. It will be FSX *itself* that will update it to the current settings, when you exit from FSX.
The only difference is, I'm using FSX:SE, while you use Acceleration. We are not aware if there were issues or bugs or limitations in FSX Acceleration related to the handling of shadows that has been fixed by FSX:SE, but maybe this is the case. We have another system with FSX SP2 that we can try.
-
Hi Umberto,
Yes it's on MY SYSTEM with FSX Acceleration who always ran very well with all FSDT products I have.... and I love. But right now I have this problem with KMEM and the only workaround I have is to arrive by night or to disable aircraft shadow (too bad for my snapshots I post on FB).
I discovered I have to update KIAH as well (yes had decrypting error messages when I wanted to check if the problem appears here too). But you know what? With the latest release of addon manager (3.0.0.14) I can't even start FSX now! FSX crahes.
Restoring previous release of bglmanx.dll and couatl.exe allows me to run Fsx but of course I have some problem when invoking GSX... Couatl stops.
So right now I'm very confused...
Skip.
-
Oh oh... Another brand new addon manager even if the same release number 3.0.0.14. Still crashing FSX because of the same bglmanx.dll but using the 3.0.013 release I can start FSX again and get GSX working on both KIAH and KMEM :-). But always a problem with aircraft shadow set active even starting directly on the runway.
To be continued with later updates...
Skip.
-
Hello,
I'm getting a CTD every time I try and launch KMEM, though I'm not sure what's causing it because the error log is vague. Here is the report:
Fault bucket 847354549, type 25
Event Name: APPCRASH
Response: Not available
Cab Id: 0
Problem signature:
P1: Prepar3D.exe
P2: 3.3.5.17625
P3: 5758bb31
P4: StackHash_0a9e
P5: 0.0.0.0
P6: 00000000
P7: c0000005
P8: ffb301b7
P9:
P10:
Attached files:
C:\Users\User\AppData\Local\Temp\WEREC9F.tmp.WERInternalMetadata.xml
These files may be available here:
C:\Users\User\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_Prepar3D.exe_576d172f9de54bea232825b2f3bdb5fdc1751_0a2b1ed6
Analysis symbol:
Rechecking for solution: 0
Report Id: cb74364b-3723-11e6-a865-001d92afd7f8
Report Status: 0
-
Hi Guys,
As I can start Fsx now I've found a workaround with the 3.0.014 bglmanx.dll problem, I performed another interesting test to help in solving AIRCRAFT_SHADOWS problem.
I use a situation file with QW 757 at KMEM gate.
1st test:
- AIRCRAFT_SHADOWS=1 in Fsx.cfg
- Start FSX and arriving on free flight menu
- Run the loaded situation
- Result is OK: QW 757 is at the gate with a nice shadow on apron
2nd test:
- AIRCRAFT_SHADOWS=0 in Fsx.cfg
- Start FSX and arriving on free flight menu
- Run the loaded situation
- Result is OK: QW 757 is at the gate without shadow on apron
3rd test:
- AIRCRAFT_SHADOWS=0 in Fsx.cfg
- Start FSX and arriving on free flight menu
- Set in display parameters aircraft shadow active
- Run the loaded situation => FSX crashes on unknown module?
Very strange... I was wondering too if "Usepools" settings could have an impact on the behaviour. Does FSDT has a recomandation on this setting? Usepools=0 or 1? Let FSX deal with that and don't specify anything?
Umberto, what do you have on your system?
Skip.
-
3rd test:
- AIRCRAFT_SHADOWS=0 in Fsx.cfg
- Start FSX and arriving on free flight menu
- Set in display parameters aircraft shadow active
- Run the loaded situation => FSX crashes on unknown module?
Tried the exact, same test, no crashes at all. Tried twice, just to be sure.
Very strange... I was wondering too if "Usepools" settings could have an impact on the behaviour. Does FSDT has a recomandation on this setting? Usepools=0 or 1? Let FSX deal with that and don't specify anything?
I don't have any Usepools line in my FSX.CFG.
-
Thanks for the reply Umberto,
If you use FSX:SE I read that the buffer pool mechanism has been optimized on this version and set by default. I removed the usepools=0 I put to increase Fps some time ago but no effect on my problem.
Some times ago I have both SP2 and Acc switch capacity on my system because some sceneries ran very bad on Acc (and very well on SP2!). Perhaps it's a typical Fsx Acc bug.
My last try will be to make a test with "default Fsx.cfg, exe.xml and dll.xml" to be sure I don't have a setting's problem.
BTW I don't understand why Fsx crashes at startup with latest addon manager 3.0.0.14 and starts well with 3.0.0.13 version of bglmanx.dll.
Regards,
Skip.
-
BTW I don't understand why Fsx crashes at startup with latest addon manager 3.0.0.14 and starts well with 3.0.0.13 version of bglmanx.dll.
It doesn't crash with any of them, here. Could you please reinstall now and be ABSOLUTELY sure you turn off the antivirus when installing ?
-
Umberto,
I always set off my AV when downloading and installing FSDT products... I remember the time Norton deleted the airports installer as soon as it was downloaded lol.
Ok. So I downloaded once again addonmanagerX and ran setup. I can see a new version of bglmanx.dll was there even if always marked 3.0.0.14 (the new file size is 1770K against 1809K for the previous one).
Fsx starts again :-).
But I have still my bug with aircraft shadows management at Memphis (no problem at Houston). I'm searching now around Usepools an my graphic card driver... But perhaps simply a g2d.dll problem with Acceleration pack (noone in dev team has Fsx acc ?).
Skip.
Skip.
-
Sorry Umberto but after hours of testing I had to go back to the 3.0.13 bglmanx.dll. This one is more stable with my system as I have "only" the crash approaching KMEM by day with aircraft shadow set. No other problem loading for example QW757 at gate by day with shadows on!
With the latest bglmanx.dll, no crash at fsx startup now but too many crashes just after when loading the scenery (it was impossible for example to load QW757 at gate even without shadow, by day or night). Always g2d.dll in Windows log :-(.
I will test every new release of bglmanx.dll at it seems a lot of changes are made this days.
Skip.
-
That's clearly a placebo effect.
There are NO changes whatsoever in any of the code between the two versions: I purposely changed ONLY the version number to be sure the installer would overwrite it and wouldn't be confused by the same version, to be sure the file was installed (the installer does version checking automatically).
What might do some difference, instead, is the antivirus blocking it or corrupting it because "it's too new". Another had a similar issue and he went away by reinstalling with the antivirus disabled.
-
Hi Umberto,
Well I disable Norton AV during all download and setup process. As fart as I can see setup_addonmanager download the files before install them. Can you give me the size bglmanx.dll should have to be correct? Here are my values:
3.0.0.13: 1 865 488 bytes
3.0.0.14 / 1 : 1 851 664 bytes
3.0.0.14 / 2 : 1 812 240 bytes
I try another time...
Skip.
-
Same problem after a new install. Please confirm the size of the 3.0.0.14 bglmanx.dll?
By the way with any bglmanx.dll (corrupted or not?) I have no crash when starting at Houston, with or without shadows.
Skip.
-
It's no use checking the filesize.
Our files are all digitally signed so, if they were corrupted (even a single byte changed from what it's supposed to be), the digital signature would be invalid and you'll surely noticed it, because FSX will warn you about the publisher being unknown. And, you can always check the Digital Signature itself on the file properties.
And yes, it's normal they will be of different sizes, even if only the version number changed.
By the way with any bglmanx.dll (corrupted or not?) I have no crash when starting at Houston, with or without shadows.
So you are crashing ONLY at KMEM now, and only if you play with the aircraft shadows settings ? I'm starting to think that the software itself doesn't have anything to do with this, and it's simply an issues of FSX not being able to handle shadows at KMEM for some reason, something that must have been fixed in P3D (which has an entirely different way of making shadows) and in FSX:SE, because it uses less memory in general. Perhaps they are just taking too much RAM...
We used to do sceneries with realtime shadows completely disabled but, in KMEM, some objects like the animated crews on the parking really required them (a static shadow on an animated guy doesn't look very good). What is puzzling me, is that we never display more than 2-3 of them at time, so they shouldn't take much memory.
-
Well Umberto, when I start to post here it was only because I had g2d.dll crashes when approaching KMEM by day with Aircraft_shadows active. I never had this problem on any other FSDT Airports.
Then starting to update addon manager X I had to update KIAH as well. Perhaps during one update attempt I get a corrupted file (AV or transfer issue) and it's the reason why at a moment I could not start Fsx at all. This issue is solved and by the way I still have problem only at KMEM.
I will perform other tests but I'm sure I don't have the same behaviour at KMEM when using bglmanx.dll 3.0.0.13 or 3.0.0.14 depending on aircraft_shadows active or not at Fsx startup, if I want to change fsx time from day to night or night to day on main menu before loading the flight.
Can you please just confirm the filesize of current bglmanx.dll and couatl.exe so I can stop reinstall it again and again? Because right now and I don't know why the best result I have is with the latest addon manager X installation but with the 3.0.0.13 bglmanx.dll.
PS: How do you dynamicaly change AC Shadow setting in your code? Can't find it on Pete Dawson or Fsdev forums.
Skip.
-
Can you please just confirm the filesize of current bglmanx.dll and couatl.exe so I can stop reinstall it again and again? Because right now and I don't know why the best result I have is with the latest addon manager X installation but with the 3.0.0.13 bglmanx.dll.
As I've said, it's no use checking the filesize, because the files are all digitally signed.
PS: How do you dynamicaly change AC Shadow setting in your code? Can't find it on Pete Dawson or Fsdev forums.
Directly in memory, and it's a code that hasn't changed in years. I might send you a test version with a switch to disable the function entirely, but I don't think it's the code that does this being the issue, otherwise it would crash at ANY FSDT airport.
[/quote]
-
As I've said, it's no use checking the filesize, because the files are all digitally signed.
OK, I backup bglmanx.dll each time I start a new install and as the files are digitally signed it is normal that I have different file sizes for the same 3.0.0.14 dll? And one of them makes Fsx crash at startup, not the others?
I will try another KMEM full install to see if it changes something and gives the same result than using the 3.0.0.13 dll.
Directly in memory, and it's a code that hasn't changed in years. I might send you a test version with a switch to disable the function entirely, but I don't think it's the code that does this being the issue, otherwise it would crash at ANY FSDT airport.
No doubt the code switching the setting is OK. It's the result with KMEM which is strange. By the way I asked that because I have my own "copilot" program using FSUIPC to manage the flight and it would be nice if I could switch on shadows a few feets before touchdown... A way to bypass my problem. But if it's a direct access to Fsx memory my external program can't do anything.
Well I'm OK to try your test version to see if switching of the function 30nm approaching KMEM with shadows on prevent from crash. You stillhave my mail?
Skip.
[/quote]
-
OK, I backup bglmanx.dll each time I start a new install and as the files are digitally signed it is normal that I have different file sizes for the same 3.0.0.14 dll?
Yes, it's normal, even if the only thing that changes is the version number. Trust me, it IS normal.
And one of them makes Fsx crash at startup, not the others?
You must always add "on my system". I'm still unable to reproduce any test. We just made another test with FSX+SP2, of course using the latest version of everything, and no crash we could see.
-
Yes Umberto, on MY Fsx Acceleration system and its specific g2d.dll.
I think I'll take the time to create a SP2 installation along the Acc one as I had by the past. So I could switch to SP2 when flying liners and switch to Acc when flying F/A18 on carriers. Not so difficult with a VM to get the Fsx SP2 tree after installation then copy it on my system and making a lot of links to custom folders.
Skip.
Skip.
-
Yes Umberto, on MY Fsx Acceleration system and its specific g2d.dll.
Do you always get the crash ? I would really like to have a look at your system with Teamviewer then. PM-me to arrange this.
-
PM you. Even with SP2 I have the problem...
-
Problem still not solved: Just had this crash with default Trike and no ASN:
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: 0xe84
Faulting application start time: 0x01d1cce65c44a029
Faulting application path: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\fsx.exe
-
Problem still not solved: Just had this crash with default Trike and no ASN:
I thought you gave up on KMEM on June 19, 2016 when you wrote "It seems that this airport is too complex for Flight Sim... oh well. Shame it's so beautiful. Time to uninstall." Back for more torture, huh?
-
Hi Umberto. I PM you an important message as I found why I have CTD on KMEM. On MY system it is linked with simobjectpaths list with both SODE and HT APcontroler entries (and so objects). On MY system and using KMEM only I have a problem when all these paths / objects are available at the same time. Removing APControler entries (SpliX and Prag) in my case makes KMEM work perfectly.
I let you see the details in PM.
Skip.
-
I thought you gave up on KMEM on June 19, 2016 when you wrote "It seems that this airport is too complex for Flight Sim... oh well. Shame it's so beautiful. Time to uninstall." Back for more torture, huh?
I got the error while I was going to uninstall KMEM.
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.
-
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.
-
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.
-
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.
-
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.
-
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
-
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.
-
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.
-
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.
-
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
-
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.
-
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.
-
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???
-
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.
-
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...
-
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.
-
Guys,
CONFIRMED!
Here are the 3 simobjectpaths configurations that never cause KMEM to crash on my system:
1°) When I made tests with Umberto (a SODE line missing):
User Objects=Airplane, Helicopter
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=Aerosoft\Split X\simobjects
SimObjectPaths.9=Aerosoft\Mega Airport Prague\simobjects
SimObjectPaths.10=C:\Program Files (x86)\12bPilot\SODE\data\SimObjects
2°) My recent tests (removing XHT APControler lines):
User Objects=Airplane, Helicopter
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
NOSimObjectPaths.10=Aerosoft\Split X\simobjects
NOSimObjectPaths.11=Aerosoft\Mega Airport Prague\simobjects
3°) This morning test (removing MytrafficX line):
User Objects=Airplane, Helicopter
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=FsxAI
SimObjectPaths.7=C:\Program Files (x86)\12bPilot\SODE\data\SimObjects
SimObjectPaths.8=C:\ProgramData\12bPilot\SODE\SimObjects
SimObjectPaths.9=Aerosoft\Split X\simobjects
SimObjectPaths.10=Aerosoft\Mega Airport Prague\simobjects
I hope SODE team will answer me (or you Umberto?) on this problem and perhaps add the simobjectpaths exclusion parameter in their configuration file to make a test?
Skip.
-
Yep- I've just tested it 3 more times, and it's the line in FSX.CFG with MyTraffic2013 that causes FSX to Crash every time.
What's strange is that I can reproduce the crash in the exact same scenario every single time- but the CTD modules are sometimes G2D.DLL and sometimes they are G3D.DLL...
Without the line in my FSX.CFG the CTD is gone completely
-
Yep- I've just tested it 3 more times, and it's the line in FSX.CFG with MyTraffic2013 that causes FSX to Crash every time.
Strange because mine doesn't make KMEM crash if I remove Aerosoft or Programdata SODE lines. But I have a new release of Mytraffic, not the 2013. What Simobjectpaths do you have in addition to mytraffic? Only standard Fsx ones?
Skip.
-
I don't own either Aerosoft airports that you are talking about- I do own Aerosoft airports though.
But you also said that if you remove the MyTraffic line in your FSX.cfg that it also fixes crashes for you correct?
What Simobjectpaths do you have in addition to mytraffic? Only standard Fsx ones?
I just reset my FSX.CFG so I have only the standard FSX ones and:
simobjectPaths.6=MyTraffic\aircraft
-
Well,
Strange that only Mytraffic2013 causes the crash. But why not? As I said not there are not the same objects in it than in my new version of Mytraffic Pro 6.
I said I made a test where I've removed from scenery.cfg the path to mytraffic. So no AI Traffic at all as the mytraffic BGL files were not loaded. And I had a crash too.
IN MY OPINION the problem is around the simobjectpaths and SODE. It's the only link I can make between KMEM and simobjectpaths other than SimObjectPaths.5=SimObjects\Misc where are stocked FSDT simobjects. Of course I can't explain it (and it's not my role to do that) but if you look at SODE log you can see it is scanning all simobjectpaths at startup.
After that if SODE is bugging while drawing the scenery because of too many or "bad" objects found, I think it would be possible to get G2D, G3D or even "unknown" module crash in error log depending on the exact time the bug happens.
One again it would be interesting to keep mytraffic active (or Aerosoft XHT airports) but tell SODE not to scan this folder.
PS: The Aerosoft airports I'm talking about are using a SODE equivalent tool named XHT APControler. And this tool is based on simobjects too.
Skip.
-
Interestingly enough , I have received unknown crashes from KMEM.
Hey Skip, try this scenario :
With Mytraffic enabled,
1. Load up Default trike and go to KMEM
2. Go up to "map" , and position ur aircraft a little bit away from KMEM so that the airport is out of loading range. Put it like 2,000 ft in the air.
3. Load it, then slew the trike right above KMEM so the sim loads the entire scenery.
4. change the sim to Night time. see if you get a crash. This is where I can produce a G2D crash every-time. Without Mytraffic, issue gone.
Sent from my iPhone using Tapatalk
-
I've already perform all possible tests ... Including approach from 30NM, with or without aircraft shadows and changing day to night. See my previous post: With 3 different simobjectpaths lists where I remove something I have no more crash whatever I'm doing with KMEM.
So I have a workaround to use KMEM on my system with My Traffic Pro 6 enable and that's the most important. I just wish someone, FSDT or SODE will find the root cause of this behaviour and perhaps a fix (or a setting) not to modify Fsx.cfg each time I want to Fly Memphis.
Skip.
-
The Aerosoft airports I'm talking about are using a SODE equivalent tool named XHT APControler. And this tool is based on simobjects too.
From what I'm able to find, APController appears to be for XP10. X Plane sceneries being ported to FSX now? ???
-
So with my scenario you DO have a crash with G2D.DLL with Mytraffic? Your explanation aren't very clear. If we can find a crash with the exact same scenario than maybe we can find causality.
Sent from my iPhone using Tapatalk
-
I guess if it's just being caused by some sim objects paths in The FSX.Cfg ... But I can't see any relationship between the Aerosoft and Mytraffic
Sent from my iPhone using Tapatalk
-
OK, I try to answer you clearly:
1°) I'm able to load KMEM without any crash using MyTraffic Pro V6 but I have to remove either Aerosoft or SODE Programdata simobjectpaths (I have 9 airports using SODE in addition to FSDT ones) from my Fsx.cfg to do it.
2°) Some Aerosoft airports like Split X or Prag use a tool similar to SODE that needs some simobjectpaths to be added (as My Traffic and SODE need simobjetcpaths to be added).
In you case you have ONLY My Traffic2013 simobjectpaths added in your Fsx.cfg but it is sufficiant to cause a crash. I can't explain why because I don't have the same release of MyTraffic and certainly not the same configuration (hardware & system).
Skip.
-
Guys, it could be very tricky to test issues caused by Traffic. That's because you should:
- Have exactly the same Traffic addon release.
- Have both the exact Traffic schedule, which might change depending on the updates you installed to it and the settings in the AI Traffic utilities. I see that MyTraffic can be very complex to configure with many different traffic options.
- Start the sim at exactly the same time of the day and day of the year (in the sim).
- Set the traffic density slider at exactly the same value.
- Start your flight at the same position.
Only then, you can be reasonably sure you have the same set of AI models loaded. Because, a crash happening only on a specific airport, that goes away if you disable AI traffic, it's surely some kind of problem of missing/corrupted textures or models file for a specific AI variant that appear only at that time of day, day of week and date, with a specific traffic density and schedule, only at a specific parking spot and, possibly, even at a specific distance from the user (only one LOD might have issues)
But if it goes away by disabling traffic, you can be 100% sure it's an AI!
-
Hi Umberto,
As clearly explain, I don't have any problem with MyTraffic Pro and KMEM. I can say the Fedex Hub is very nice with plenty of Fedex birds on it!
I won't perform any new test without a new release of SODE or KMEM to check if I can fly using my original simobjectpaths configuration without crashing Fsx. I think my post this morning is clear: There is no specific incompatibility between products but a problem when all my products are set in simobjectpaths list and approaching or loading KMEM.
Skip.
-
OK- So i tested out weather simply sliding the traffic slider back down to 0% would fix my crashes and it did. So it's some corrupted thing with my AI, I'll do a re-install and report back later
-
ARGHHH!!!!
So I thought I have a workaround removing APControler simobjectpaths lines from Fsx.cfg... But not at all!!!! I try today to perform a normal flight from Roma to Memphis with PMDG777 and ASN and arriving at 9.7NM on ILS 27 Fsx crashes!
Application Error: [1000] Nom de l’application défaillante fsx.exe, version : 10.0.61637.0, horodatage : 0x46fadb14.Nom du module défaillant : g2d.dll, version : 10.0.61637.0, horodatage : 0x46fadb58.Code d’exception : 0xc0000005.Décalage d’erreur : 0x00085da0.ID du processus défaillant : 0x1d44.Heure de début de l’application défaillante : 0x01d1cea09da61b53.Chemin d’accès de l’application défaillante : E:\FsX\fsx.exe.Chemin d’accès du module défaillant: E:\FsX\g2d.dll.ID de rapport : 1cd3dcaa-3ad7-11e6-b5ba-c86000cc4d68
Application Error: [1000] Nom de l’application défaillante couatl.exe, version : 3.1.0.3487, horodatage : 0x575eda1f.Nom du module défaillant : ntdll.dll, version : 6.1.7601.23418, horodatage : 0x5708a73e.Code d’exception : 0xc0000374.Décalage d’erreur : 0x000ce843.ID du processus défaillant : 0x111c.Heure de début de l’application défaillante : 0x01d1cea0b55f9ad1.Chemin d’accès de l’application défaillante : E:\FsX\fsdreamteam\couatl\couatl.exe.Chemin d’accès du module défaillant: C:\Windows\SysWOW64\ntdll.dll.ID de rapport : 1fdf2c43-3ad7-11e6-b5ba-c86000cc4d68
SODE log file shows LIRF SODE Jetways loading then every minutes until the crash the following error:
[15:16:18.148] INFO SODE.FSLOOP : ### FILTERING OBJECTS WITHIN SIM RADIUS OF 24000m
[15:16:18.148] INFO SODE.FSLOOP : ### Active SimObjects: 0; Active Wind Data Probes: 0
[15:16:18.172] ERROR SODE.FSLOOP : SimConnect EXCEPTION! ID=31
And the last one:
[15:16:50.473] INFO SODE.FSLOOP : SeasonalObjectHandler: Refreshing Season/Time Data...
[15:17:14.458] DEBUG SODE.FSPROCESS : Cleaning up Memory...
[15:17:14.460] DEBUG SODE.FSPROCESS : Closing Connection to FS.
[15:17:14.560] INFO : Terminate SODE.
WHY CAN'T I USE THIS PRODUCT AS I USE ALL THE OTHER AIRPORTS I HAVE?
I will try to make the same tests I performed with the lerar 45 but with PMDG777 to see if the VAS remaining when aproaching KMEM is the problem.
Skip.
-
I will try to make the same tests I performed with the lerar 45 but with PMDG777 to see if the VAS remaining when aproaching KMEM is the problem.
If it was a problem with VAS usage exceeding the 4GB limit you should have received a message just after the CTD that you were out of memory. If you didn't receive the message, I don't imagine it was a VAS problem.
-
If it was a problem with VAS usage exceeding the 4GB limit you should have received a message just after the CTD that you were out of memory.
Not so easy...that's only if FSX itself exhausted VAS but, there are some memory allocation made by KMEM that FSX cannot detect, so it's possible they might cause an NTDLL.DLL error.
-
I downloaded the KMEM Demo a few days ago, installed it into my win 7/64 FSX machine, where all my FSDT and other payware live, and of course, CTD when loading default trike at the airport. This scenery must be "different" to other FSDT scenery code architecture, as it seems to need wider parameters before it will load. All my other FSDT loads straight away.
I also loaded KMEM into my win 8.1/64 FSX-SE machine, which as NO other scenery installed and it worked straight away!! proving that it does work as loaded, just got to get the config happy.
So, no doubt, if you have a machine that happens to fit the new parameters FSDT has inadvertently set, great. For us others, lots of time chasing rabbits down holes.
So, when some one much cleverer than me comes up with a list of possible solutions, I will recommence the journey.
-
I also loaded KMEM into my win 8.1/64 FSX-SE machine, which as NO other scenery installed and it worked straight away!!
That's to be expected. FSX:SE has a better memory handling so, if your FSX is stuffed with too much things, there are both more chances to cause conflicts and more chances to exhaust memory.
I downloaded the KMEM Demo a few days ago, installed it into my win 7/64 FSX machine, where all my FSDT and other payware live, and of course, CTD when loading default trike at the airport. This scenery must be "different" to other FSDT scenery code architecture, as it seems to need wider parameters before it will load.
Yes, of course it's different. In any case, as for anybody else with a problem, I'm available to arrange a Teamviewer session to check your system directly. PM-me about this if you are interested.
-
It's not a VAS issue for sure. No OOM message from Fsx.
I've just perform a test with exactly the same configuration than this morning:
- Starting at Fedex ramp with PMDG777, Asn and EFB running.
- I have a little programm to monitor VAS: 1812K after loading
- Take off runway 27 then a great tour to perform 27 star approach at 38NM
- Glide interception without any issue (I crashed exactly at this moment this morning)
- Full stop landing runway 27.
- VAS remaining on the runway: 1080K
But if I remember my previous tests, If I was able to load KMEM scenery without crashing, I never had crash after when going back even turning 45NM away.
So my next test tomorrow (after I'll perform a flight elsewhere :-)) will be to find an airport at more than 50NM where I can take off with the 777 and same approach 27. Of course Asn weather will be different but honestly I don't think the problem is there.
KIAH is working very well even in the latest release with SODE jetways. But for sure it is not so complex with all new features introduced by KMEM.
One again I love FSDT products and I hope they'll find why KMEM is so hard to make running.
Skip.
-
It's not a VAS issue for sure. No OOM message from Fsx.
As I've said:
there are some memory allocation made by KMEM that FSX cannot detect, so it's possible they might cause an NTDLL.DLL error.
However, if that utility (assuming IT can detect VAS properly) says you *really* have 1080K left, that's VERY close to memory exhaustion!! Unless you meant 1080MB...
-
Umberto
Does the undetected memory allocation occurs at any other FSDT airports other than KMEM?
Thank you
Michael Cubine
-
It's not a VAS issue for sure. No OOM message from Fsx.
As I've said:
there are some memory allocation made by KMEM that FSX cannot detect, so it's possible they might cause an NTDLL.DLL error.
However, if that utility (assuming IT can detect VAS properly) says you *really* have 1080K left, that's VERY close to memory exhaustion!! Unless you meant 1080MB...
Oups yes 1080Mb of course.
Skip.
-
Does the undetected memory allocation occurs at any other FSDT airports other than KMEM?
KIAH, most likely, only in the latest version. But KIAH probably takes less VAS than KMEM, so the two are not comparable anyway. KMEM takes less VAS than KLAX, however so, it's not a particularly memory-hungry scenery, but of course, everything loaded counts.
-
I uninstalled Mytraffic 2013 and Installed MyTraffic Pro. KMEM STILL Crashing. I am so sick of this.
-
I uninstalled Mytraffic 2013 and Installed MyTraffic Pro. KMEM STILL Crashing. I am so sick of this.
THIS sentence of yours:
"This is where I can produce a G2D crash every-time. Without Mytraffic, issue gone."
Which I assume is accurate, clearly proves the problem didn't had anything to do with KMEM.
THIS one, instead:
I uninstalled Mytraffic 2013 and Installed MyTraffic Pro.
Only proves that this other Traffic addon might just have the same problem as MyTraffic 2013. Have you TRIED with AI Traffic at 0% ?
-
Which I assume is accurate, clearly proves the problem didn't had anything to do with KMEM.
Yes, it DOES have todo with KMEM. KMEM might not be *causing* the problem- but the CTD is happening at KMEM, so it DOES involve KMEM. It also involves Mytraffic
Only proves that this other Traffic addon might just have the same problem as MyTraffic 2013. Have you TRIED with AI Traffic at 0% ?
From my previous message:
OK- So i tested out weather simply sliding the traffic slider back down to 0% would fix my crashes and it did.
-
Yes, it DOES have todo with KMEM. KMEM might not be *causing* the problem- but the CTD is happening at KMEM, so it DOES involve KMEM. It also involves Mytraffic
Define "involves"...
Are you saying that, if there's a problem with some AI model that appears at KMEM (because of its schedule) and causes the sim to crash, we could/should do something about it ?
A simulation of a Anti-air Flak/simulated SAMs, to shot down dangerous AI ?
From my previous message:
OK- So i tested out weather simply sliding the traffic slider back down to 0% would fix my crashes and it did
I read it, I just wanted another confirmation: it's clearly an AI problem then.
-
Even more proof that it DOES directly involve FSDT KMEM-
I tested out to see if it was *just* the AI that was causing the problem. So I completely uninstalled FSDT KMEM. Same AI Traffic. And no crashes!
-
Hi Guys,
I'm in contact with SODE support and I'll explain them the problem I have and how simobjects are involved. SOmething
Something I just see now: My flight this morning was made with 2 lines "renamed" to avoid the problem but I did crash with 777:
NOSimObjectPaths.10=Aerosoft\Split X\simobjects
NOSimObjectPaths.11=Aerosoft\Mega Airport Prague\simobjects
But if performing a test with the lear 45 and the same lines renamed, no crash and I can see that in SODE.log:
[00:46:48.017] DEBUG SODE.FOLDERMANAGER : Looking for sim.cfg files in E:\FSX\SimObjects\Airplanes\
[00:46:48.091] DEBUG SODE.FOLDERMANAGER : Looking for sim.cfg files in E:\FSX\SimObjects\Rotorcraft\
[00:46:48.092] DEBUG SODE.FOLDERMANAGER : Looking for sim.cfg files in E:\FSX\SimObjects\GroundVehicles\
[00:46:48.109] DEBUG SODE.FOLDERMANAGER : Looking for sim.cfg files in E:\FSX\SimObjects\Boats\
[00:46:48.127] DEBUG SODE.FOLDERMANAGER : Looking for sim.cfg files in E:\FSX\SimObjects\Animals\
[00:46:48.128] DEBUG SODE.FOLDERMANAGER : Looking for sim.cfg files in E:\FSX\SimObjects\Misc\
[00:46:48.166] DEBUG SODE.FOLDERMANAGER : Looking for sim.cfg files in E:\MyTraffic Professional\MyTraffic\Aircraft\
[00:46:48.173] DEBUG SODE.FOLDERMANAGER : Looking for sim.cfg files in E:\FSX\FsxAI\
[00:46:48.177] DEBUG SODE.FOLDERMANAGER : Looking for sim.cfg files in C:\Program Files (x86)\12bPilot\SODE\data\SimObjects\
[00:46:48.177] DEBUG SODE.FOLDERMANAGER : Looking for sim.cfg files in C:\ProgramData\12bPilot\SODE\SimObjects\
[00:46:48.194] DEBUG SODE.FOLDERMANAGER : Looking for sim.cfg files in E:\FSX\Aerosoft\Split X\simobjects\
[00:46:48.196] DEBUG SODE.FOLDERMANAGER : Looking for sim.cfg files in E:\FSX\Aerosoft\Mega Airport Prague\simobjects\
[00:46:48.199] INFO SODE.FOLDERMANAGER : SODE SimObjects Map Building completed. Size=372
Exactly the same log than if I don't renamme the lines (with "NO"). Size=372 in both SODE.log. Strange isn'it?
Skip.
-
Even more proof that it DOES directly involve FSDT KMEM-
I tested out to see if it was *just* the AI that was causing the problem. So I completely uninstalled FSDT KMEM. Same AI Traffic. And no crashes!
Please test with only the afcad files from FSDT Kmem to have the same AI density.
-
Even more proof that it DOES directly involve FSDT KMEM-
I tested out to see if it was *just* the AI that was causing the problem. So I completely uninstalled FSDT KMEM. Same AI Traffic. And no crashes!
Please test with only the afcad files from FSDT Kmem to have the same AI density.
I've already "tested" everything I could to solve this issue. You guys don't seem to be giving that many things to "test" either...
Umberto was claiming that KMEM was not involved at all in this issue, so I did the last possible test to see if it was simply a MyTraffic missing texture/or corrupt file somewhere so I tried to eliminate FSDT KMEM with only MyTraffic remaining, and the issue is fixed..
Even trying a clean install of a new Traffic Add-on and the issue is still there so I don't know what todo anymore, I've done everything I could do.
Meanwhile, poor Skipy33 is over in Left field with his problems will very little assistance...
-
Yes, a tad frustrating. Umberto did offer to remote log into our machines and see what he can find, which is very kind. Maybe Hnla, your best bet if you have purchased the software and need to get it working is to take up Umberto's offer!
I almost purchased KMEM, saw the CTD issues on the forum, and downloaded the demo instead, and sure enough, on my FSX machine, CTD.
Over the next several months, I will keep attacking the FSX machine with Windows and other software updates and re-apply the demo version and see how I go. Maybe my FSX machine/software combination simply not suitable for FSDT's KMEM, and one day, if I ever decide to migrate to P3D, will re-look.
-
Even more proof that it DOES directly involve FSDT KMEM
I tested out to see if it was *just* the AI that was causing the problem. So I completely uninstalled FSDT KMEM. Same ATraffic. And no crashes!
This is NOT A PROOF!
When you uninstall a scenery, the AFCAD changes! When the AFCAD changes, the number of available parking changes, the parking codes of the airlines changes too.
Which means, the AI model that is causing the problem will likely NOT appear, if you uninstall a scenery, and switch to a different AFCAD, one that has less parking available and a different assignment of repaints due to different or even missing (default AFCADs DO NOT use atc_parking_codes ) parking codes.
I'll repeat it again: the DEFINITIVE proof the problem is an AI, is the fact that YOU said that if you set AI to 0% at KMEM, it doesn't crash
-
Umberto was claiming that KMEM was not involved at all in this issue, so I did the last possible test to see if it was simply a MyTraffic missing texture/or corrupt file somewhere so I tried to eliminate FSDT KMEM with only MyTraffic remaining, and the issue is fixed..
Please read again my explanation. And Alessandro said basically the same...
Meanwhile, poor Skipy33 is over in Left field with his problems will very little assistance...
How could you be SO WRONG ? I had a Teamviewer session with him, and we were UNABLE to see any crash. And further on, he said the problem happens ONLY when adding specific non-FSDT objects to the Simobject folders, and we are trying to investigate this because IT SEEMS related to SODE.
-
Yet again, an answer with all fluff and no helpful information on how to solve this issue.
This is NOT A PROOF!
Great. So what should I do?
When you uninstall a scenery, the AFCAD changes! When the AFCAD changes, the number of available parking changes, the parking codes of the airlines changes too.
Awesome. What should I do?
I'll repeat it again: the DEFINITIVE proof the problem is an AI, is the fact that YOU said that if you set AI to 0% at KMEM, it doesn't crash
No doubt, never denied it. So, lets say it again, 3rd time. What SHOULD I DO?
How could you be SO WRONG ? I had a Teamviewer session with him, and we were UNABLE to see any crash. And further on, he said the problem happens ONLY when adding specific non-FSDT objects to the Simobject folders, and we are trying to investigate this because IT SEEMS related to SODE.
What, you had a team viewer session weeks ago? He has been giving you tons of info in this thread with basically no feedback at all.
-
Great. So what should I do?
Find your defective AI.
Awesome. So what should I do?
Find your defective AI
No doubt, never denied it. So what SHOULD I DO?
Find your defective AI
What, you had a team viewer session weeks ago? He has been giving you tons of info in this thread with basically no feedback at all.
You are now really embarrassing yourself...
"Weeks ago" ? We had it on June 23th, that's only 3 DAYS ago!
"No feedback" ? I keep replying in this thread to both of you.
The difference, between you and him, is that he understand the problem on his system seems to be caused by some kind of interaction between some 3rd party objects and some NON-FSDT SODE objects so, opposite to you, he understand it might be a SODE problem worth investigating together with SODE author. Which is what he did.
You, instead, do not seem to understand YOUR problem is different and, according to YOUR own report, it's happens only when AI are enabled. That's clearly indicates the problem is one of your AI models.
Do you want to have a Teamviewer session with me ?
-
Great. So what should I do?
Find your defective AI.
Awesome. So what should I do?
Find your defective AI
No doubt, never denied it. So what SHOULD I DO?
Find your defective AI
Great "in depth" answers-
How do I find "defective AI" with a clean install of Mytraffic??
-
Ok cooldown....
I'm in contact with SODE support. They read this thread and confirm that using "NOSimobjectpaths" in Fsx.cfg to disable a path is not working. SODE will take it anyway. That can explain why I crashed with my 777 thinking I had disabled 2 APControler lines.
By the way they ask me to perform my test with SODE inactive but with everything else (including My Traffic) and of course no crash occurs. So they could work on the specific trisome SODE+KMEM+My Traffic (in case SODE is disturbed by something in aircraft.cfg or sim.cfg included in My Traffic).
Skip.
-
Hi guys,
Last tests for today which seems to confirm SODE team approach. I use following startup situation: QW757 at KMEM gate, all my simobjectpaths lines in Fsx.cfg.
If I disable SODE modules (exe + dll) I can load the situation without problem and My traffic AI aicrafts all around me.
If I keep SODE modules active, I got a crash even if I set AI traffic to 0.
Hope SODE team will find the root cause because I love to have active jetways on a scenery. The GSX integration with SODE is so great!
Good night.
Skip.
-
Great News skipy33 that you seem to be getting to the issues with the SODE Team. It helps when KMEM works in some situations and not others, as you can start to isolate things and steadily resolve the problem(s) that cause KMEM to fail.
Hnla, Take up Umberto's offer for the Teamviwer session. He is obliviously skilled in trouble shooting his series of FSDT programs, being a programmer and user. Many people have installed this program and it work ok. A few common early issues have been fixed by FSDT. There are now a few isolated issues, which are usually always caused by our machines being a little outside the acceptable envelope for this FSDT scenery. You can go on every user forum and find people who can not load 'a' program for their own reasons.
In my case, my first thought was #$%^ hell FSDT, why didn't you test this better. Then with a little more thought(read this as patience), I accepted it could be "my" problem.....So, I spent the last few days tracking down my windows updates. Seems while they were installed, some in fact had failed. I tracked these down and re-installed them, this time verifying they installed correctly. Another day cleaning my registries and also ensuring the FSX SP1 and SP2 were in place and that KMEM was installed correctly with up to date version. And finally, spent another day defragging my machine(which took 16 hours!!).
I then revisited FSX and attempted to load KMEM.......@#$%^ fantastic, it loaded and during the 5-6 minutes demo cycle, I could flit about the airport in my trike. I then swapped planes to the PMDG 777, which tends to be a vas hungry girl, and also loaded with KMEM. Great job Umberto.
So guys, patience is required tracking down the issues causing KMEM to not work on your machine. If you can, get to a position when KMEM loads. Then start to add things until it fails. The item you last loaded, is causing you problems and you may need to contact the owner of 'that' program to sort out why.
-
Hello,
Last news. I performed tests with SODE debug mode on to send logs to SODE Support. I hope this helps.
If SODE modules are inactive, I don't manage to make Fsx crash at KMEM or approaching.
With SODE active, I manage to crash even with AI Traffic set to zero in Fsx.cfg.
With Sode active I manage sometimes to load KMEM but I Wonder if changing set SmallPartRejectRadius=2 instead of 1 in Fsx.cfg impacts the root cause of the crash.
Changing Fsx time from night to day in welcome menu seems to increase possibilities of crash...
Once I crashed, I must reboot otherwise all other tests crash even with SODE inactive.
Good night. Skip.
-
Changing Fsx time from night to day in welcome menu seems to increase possibilities of crash...
This is what makes my KMEM Crash everytime.
-
Seems we are still passing the buck FSDT? How about fixing the issue? Its not Ai. its KMEM from FSDT
-
Hi All,
Still testing with SODE team support... I get a special debug version of SODE because they can't see any error during first tests.
I tuned some Fsx.cfg parameters and it seems it has an impact in the way I crash or not.
TEXTURE_BANDWIDTH_MULT=120 instead of 160
Usepools=0 instead of RejectThreshold=524288
FIBER_FRAME_TIME_FRACTION=0.33 instead of 0.10
SmallPartRejectRadius=1 instead of 2
AirlineDensity=40 instead of 35
GADensity=0 instead of 5
The strange fact is with these settings, this morning after PC boot, I can start Fsx and load KMEM with SODE, AI and all my simobjectpaths without any crash....
I quit Fsx properly and run again exactly the same situation (QW757 at gate): CRASH!
Very difficult to test anything in this condition....
Skip.
-
Seems we are still passing the buck FSDT? How about fixing the issue? Its not Ai. its KMEM from FSDT
It's not KMEM. It is your computer, operating system, addons , platform or operator error. KMEM is fine.
-
Seems we are still passing the buck FSDT? How about fixing the issue? Its not Ai. its KMEM from FSDT
You are really something: this thread has PROVED it's NOT KMEM and is somewhat related to SODE and/or AI, yet you are still insisting...why you keep embarrassing yourself ?
-
I agree :). It's my system who don't support KMEM and only KMEM. It's my system who works perfectly with about about 50 addon airports, 20 addon aircrafts, Active Sky Next, EFB, VRInsight Combo, Virtual CDU, iFMS and who suddenly stop working when flying KMEM.
MY opinion is not that KMEM is bad. MY opinion is KMEM is not designed as all other other addons I have even from FSDT are and there's something not compatible with MY system.
But OK. As usual I'll find a workaround by myself.
-
It's my system who works perfectly with about about 50 addon airports, 20 addon aircrafts, Active Sky Next, EFB, VRInsight Combo, Virtual CDU, iFMS and who suddenly stop working when flying KMEM.
Nothing in your previous reports and nothing I could see in your Teamviewer session indicated that ANY of your other addons "stop working" when flying KMEM.
Quoting from your last report:
If SODE modules are inactive, I don't manage to make Fsx crash at KMEM or approaching.
-
But SODE is installed by KMEM installer????
But OK I'll work with SODE support team.
Please delete my account.
Thanks.
-
PS: It was also MY system who was guilty when setup addonmanagerx was downloading bad files from one of your mirrored servers and so Fsx crashed at startup....
-
PS: It was also MY system who was guilty when setup addonmanagerx was downloading bad files from one of your mirrored servers and so Fsx crashed at startup....
The files weren't "bad", they were just not the same, exact, version. They were just one version behind, and they worked fine for everybody.
And what THIS has *anything* to do with your current problem ? It only proves, once more, the as soon we find a problem that might be caused by something related to our software, we act immediately on it.
-
But SODE is installed by KMEM installer????
SODE is used by many other 3rd party sceneries and is included in several other installers too.
Suppose you had a problem with FSUIPC, who you'll contact for support ? One of the many airplane developers that includes it in their installers, or Pete Dowson ?
-
Suppose you had a problem with FSUIPC, who you'll contact for support ? One of the many airplane developers that includes it in their installers, or Pete Dowson ?
You can't make a comparison like this because FSUPIC is never included in a product. You always must separately download it, at YOUR discretion. And you can always freely uninstall it.
With SODE, you are FORCED to use it with KMEM-and it's included in the installer, and it's integrated with KMEM!!! It's not like it's an "option" to use it. So it's only obvious why people are coming here for support with SODE with KMEM!!!
Uhh...
-
You can't make a comparison like this because FSUPIC is never included in a product. You always must separately download it, at YOUR discretion. And you can always freely uninstall it.
In the past Captain Sim 757/767 installers installed FSUIPC (unregistered) so the plane was flyable.
-
You can't make a comparison like this because FSUPIC is never included in a product. You always must separately download it, at YOUR discretion. And you can always freely uninstall it.
In the past Captain Sim 757/767 installers installed FSUIPC (unregistered) so the plane was flyable.
Still doesn't make it right to completely scapegoat everything.
-
You can't make a comparison like this because FSUPIC is never included in a product. You always must separately download it, at YOUR discretion. And you can always freely uninstall it.
That's the the case.
Qualitywings, for example, installs it, and so ALL addons that are sold in a boxed version with a CD also installs it (Wilco, Aerosoft, Flight1, etc.). CD users are NOT accustomed having to download something, so everything needed to run a product is always included, which of course includes FSUIPC.
With SODE, you are FORCED to use it with KMEM-and it's included in the installer, and it's integrated with KMEM!!! It's not like it's an "option" to use it. So it's only obvious why people are coming here for support with SODE with KMEM!!!
Wrong.
You are NOT "forced" to use it. It's needed only to animate the jetways in GSX. If you are not interested in animated jetways, you can disable SODE, if you find it crashes your system. Jetways will STILL display, but static.
Instead, there are other developers that use SODE to create actual objects (AND jetways) of the scenery that won't even display if you disable it. And the same is valid for any airplane using FSUIPC: it won't work without it.
So no, is exactly the opposite of what you say: KMEM is perfectly usable without SODE, and will just have static jetway (like so many other sceneries out there), while many of other sceneries out there using SODE will not work without it, and no airplane requiring FSUIPC will work without it, for example if you need to disable it because of a problem.
-
Still doesn't make it right to completely scapegoat everything.
You found SODE crashes on your system ? Just disable it, and KMEM will still work, just without animated jetways...and it won't "scapegoat" ANYTHING.
-
Still doesn't make it right to completely scapegoat everything.
Several hours ago I completed KMEM-RJAA using the PMDG 777F. Started flight at cargo ramp 393. I don't use SODE for that and I have never disabled it. Forget the pax terminal and just haul cargo. Disable SODE and save yourself a lot of aggravation.
-
So because you are unable to fix KMEM's problems, you say go back to default jetways LOL
-
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.
-
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)
-
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.
-
Thanks for getting with the EZdok developers on this matter.
Sent from my iPhone using Tapatalk
-
Hi Umberto, I am not an EZdok user and I still have the crashes every time. It must be something else as well.
-
So, they release a product, and integrate it with SODE, which is faulty. And we may never know what is wrong.
-
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.
-
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...
-
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...
-
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.
-
Check your PM.
-
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
-
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.
-
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.
-
Well I PM'ed umberto asking todo Teamviewer and No response, so don't keep with this "stop the torture" nonsense.
-
Hnla,
Maybe he is a tad busy rechecking code,other potential roadblocks, and development. The support responce time on this forum pretty good.
I had a look around with Google, no doubt you did the same. Seems this Bglmanx.dll error pops its head up quite a bit, on both FSX and P3D platforms. If you check them, the error was caused by Bios, ASN or other modules that needed updating etc.
Have a look at the post by Pete Dowson, http://forum.simflight.com/topic/77549-fsx-fatal-error-fsuipc/ especially his comments, 20 Aug 2014 and 21 Aug 2014
"Your problems are from other add-ins you are running. You need to go through a process of elimination. If you find your DLL.XML and EXE.XML files and paste those here I can point out how to do this for those programs loading automatically."
I appreciate your error is not FSUIPC, but....he provides a way of checking the various .exe and .dll files for which maybe crashing the program. This guy found it to be ASN that needed reinstalling....
-
After a 2 weeks I had a G2D.dll crash during a Flyin on VATSIM . I was hoping for the best :(
I'm using EZdok 1.17. Which version should I be using? Also I just moved EZdok to the last entry in my exe.xml and configured it as Administrator. Anything else I should try? Really trying to conquer this bug.
Sent from my iPhone using Tapatalk
-
Any suggestion on which version of EZDok I should be using? Currently using 1.17. Also to follow up I used AI Aircraft Editor to scan my AI and I found a few that reported errors. I have fixed them. Also I made sure EZdok is set to run as administrator. This is not set by default. I'll keep trying and follow the tips posted here.
Sent from my iPhone using Tapatalk
-
Any suggestion on which version of EZDok I should be using? Currently using 1.17
This is from an email I've got from someone from the Ezdok support team on the Flight1 forum:
the current version is v1.1.87 beta and is the version downloadable from the flight1 website by new customers. If an existing user posted an issue on the forum relating their use of v 1.18 to v1.1.86 inclusive- I would suggest they upgrade to the latest version which retains full compatibility with FSX acceleration ( FSX -DVD version)
UPDATE
Thanks to Flight1, who sent me a copy Ezdok to test, I can only confirm that (as expected) I don't have any crashes at KMEM with version 1.18.7.
-
I'm running the latest version now. Fingers crossed.
Sent from my iPhone using Tapatalk
-
OK, so the problem seems to be caused by FSUIPC4.DLL for me. I keep getting FSUPIC crashes at KMEM, but WHY? I posted on the FSUIPC forum but he's on vacation until the 23 of July..
-
So I did 3 identical tests with KMEM- All 3 with the same exact scenario
-Load up PMDG 737NGX, and go to KMEM on Active Runway (no weather addon loaded)
Of the 3 times I tested that scenario I was able to get the crash once.
Faulting application name: fsx.exe, version: 10.0.61637.0, time stamp: 0x46fadb14
Faulting module name: FSUIPC4.dll_unloaded, version: 0.0.0.0, time stamp: 0x575f3e3a
Exception code: 0xc0000005
Fault offset: 0x1afd6340
Faulting process id: 0x254
Faulting application start time: 0x01d1e1ca5cc40d76
Faulting application path: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\fsx.exe
Faulting module path: FSUIPC4.dll
Not much useful information, but just thought i'd share if anyone has any clues...
-
Hi Hnla,
When Pete Dowson from FSUIPC returns, he will be able to assist you better. The intermittent failure for the same loaded scenario seems to indicate some weakness. Looking on Pete Dowsons forum, he asked a person to supply him some information to assist with help....
" So please do three things:
1. Provide more information about the actual error initially reported. All you've said so far is "I get a message advising me not to use it.". I need more details than that. Check in the Windows error log, see what errors it details from FSX.EXE. There will be more details there. The error log can be seen by entering "event viewer" in the Start edit field, then selecting Windows Logs -- Application.
2. Look in the FS Modules folder. There will certainly be an FSUIPC4 Install log file. Paste that here. And see if there is an FSUIPC4 Log file. If so, paste that here too. If not, tell me -- that means FSUIPC has never actually been run.
3. Get a SimConnect log file. There's a FAQ subforum thread on how to do that. Paste that here too. "
Hnla, if you have not supplied all this info, maybe you can do it now, before Pete returns from vacation??
I did notice that you have FSX loaded into your Program Files. I often see reference to a warning to always install FSX outside of the Program File to give you better control. In my case, I have D:\FSX. To de-install and reinstall is a big pain, as it will involve all your flight sim programs. But, that said, plenty of people have FSX installed inside their Programs File with no issues.
FSX, It works ok, then, you introduce a new add on, and BANG...it becomes very unstable, often in an area that you least expect, until you work out the connection.
-
Well I talked to Pete D. He basically said it must be scenery corruption. And you guys claim that it isn't.
-
Yeah, frustrating Hnla, If FSDT and FSUIPC can't help further. I did see your post in the FSUIPC forum. Pete was suggesting a rogue memory variable, possibly weather as a cause, due to the weather system constantly changing. He also considered FSUIPC was only reporting some thing it saw, rather than the cause. He seemed very sure, your problem is weather related and indicated how to turn off the weather reading. If this failed, then remove and reinstall KMEM, which no doubt you have done.
Unfortunately, all our machines differ to varying degrees with both hardware and software. The developers try to code a program to fit between these variances. For what ever reason, your system maybe just outside the KMEM envelope...some times.... This variable crash situation will need lots of sleuthing to find the cause.
For the purposes of testing, I would disable FSUIPC, and not fire up the weather add on. Then load your same scenario and see if KMEM loads every time or still crashes your system, making sure you keep track of your RAM usage, as each re-load, after a successful previous load will be depleting your memory unless you have been shutting down FSX between successful loads.
If or when your machine crashes, see what the error log says, as it can no longer blame FSUIPC or weather add on.
There might be a time when you have to admit defeat and accept KMEM will not run on your system set up the way it is.
-
And of coarse.. I get no crashes when AI is disabled.
I do get some COUATL crashes though
Faulting application name: couatl.exe, version: 3.1.0.3527, time stamp: 0x57923ce0
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x7ebd001c
Faulting process id: 0x12a0
Faulting application start time: 0x01d1e5ba65bfa365
Faulting application path: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\fsdreamteam\couatl\couatl.exe
Faulting module path: unknown
There might be a time when you have to admit defeat and accept KMEM will not run on your system set up the way it is
Sorry, I am not just going to "go away". Maybe I would if it was an airport by ImagineSim.. but KMEM is a brilliant product, and I truly believe there is some sort of incompatibility with something at KMEM that affects some users that nobody has discovered yet.
There is no reason why everything else in my sim works great but not KMEM for some "unknown" reason. Plus, I've gotten several PM's from users who also have crashes that have basically just given up and accepted that there is no solution (right now) to crashes at KMEM.
-
Good luck with the searching Hnla. I have had similar times when I did no "flying", but only repairs and maintenance for several weeks or months. I seemed to be for ever fixing things and not enjoying the flying.
Eventually, I stopped all "repairs" and reformatted my machine, reloaded Win 7, fully updated Win 7, then went through the process of rebuilding my system. Since then, all seems to work quite well....I wonder if P3D users have had better success, compared to FSX? as P3D engine may now be a bit more robust!
I think its great the FSDT make their products for FSX and P3D, and hope that this compilation has minimal risk of conflicts as compared with totally stand alone single products. Hope so, as this is the main reason I still buy FSDT and others with the 'mix and match' engines, as it edges my bets for future buying decisions for P3D or remaining with FSX.
I can understand other users sending you pm about their issues and giving up while waiting for a solution, though, better to keep it alive for FSDT guys to help figure out what is causing the conflicts.
-
Good luck with the searching Hnla. I have had similar times when I did no "flying", but only repairs and maintenance for several weeks or months. I seemed to be for ever fixing things and not enjoying the flying.
Eventually, I stopped all "repairs" and reformatted my machine, reloaded Win 7, fully updated Win 7, then went through the process of rebuilding my system. Since then, all seems to work quite well....I wonder if P3D users have had better success, compared to FSX? as P3D engine may now be a bit more robust!
I think its great the FSDT make their products for FSX and P3D, and hope that this compilation has minimal risk of conflicts as compared with totally stand alone single products. Hope so, as this is the main reason I still buy FSDT and others with the 'mix and match' engines, as it edges my bets for future buying decisions for P3D or remaining with FSX.
I can understand other users sending you pm about their issues and giving up while waiting for a solution, though, better to keep it alive for FSDT guys to help figure out what is causing the conflicts.
Hi Geoff.
In MY case on MY system, g2d.dll crash is not due to a "conflict" between various addons but the way all those addons (typically Couatl, SODE and AI traffic) want to display their objects at the same place (KMEM) at the same time. Despite the latest updates improve a bit the behaviour, the only workaround I found ON MY SYSTEM to use KMEM today with SODE and AI Traffic is to slow down my Fsx performance at a specific time:
1°) If I want to start a situation directly at a KMEM stand:
- I set in Fsx.cfg Fsx frame limiter to 10 and fiber_frame_time_fraction to 0.33.
- I run Fsx and start the situation
- Once everything is fully loaded (without crash but with a very bad FPS around 5) I can set Frame limiter to unlimited via Fsx settings and fiber_frame_time_fraction to 0.10 via Addon Manager menu.
- I can start my flight with a good FPS (15-30) despite my 3860x1024 resolution and ASN+ASCA weather + many AI Aircrafts => No crash :)
2°) If I want to land at a KMEM arriving from another airport:
- Depending of the approach, I set arriving 15NM MEM Vor FPS limiter to 10 via Fsx menu and fiber_frame_time_fraction to 0.33 via addon manager menu
- The FPS becomes very bad of course but I stay like that until 5NM inbound
- Then I set back my previous settings to get an acceptable performance in final => No crash :).
If I try to start a default situation at KMEM or land at KMEM keeping my original settings (which work very well with all other airports addons using couatl engine) I always get a g2d.dll crash.
Skip.
-
Hi skip, Now that must be so frustrating. You just want to fly from A to B...Sounds simple. When you are using all other third party airports fine, every thing stable(well, as stable as FSX can be!!) then along comes KMEM, and BANG...Just like Hnla and I guess a few others, the enjoyment disappears from flight sim until you sort out the new addition. Having to tweak your settings while flying does not lend itself to immersion.
There is some thing "different" about KMEM, compared to other FSDT airports coding architecture. Sufficient to cause some users grief. As yet, I only have the demo version, so my testing of it very very limited due to the 5 minute use rule. Being a FEDEX guy, I can see I will have to take the plunge and buy, though hopefully I can hold off until FSDT have their sales, and then I might be joining you here.
-
Hi skip, Now that must be so frustrating
I can understand other users sending you pm about their issues and giving up while waiting for a solution
Yeah, frustrating Hnla
Good luck with the searching Hnla
Can we stop with the stereotypical support replies and get some constructive responses...
Despite the latest updates improve a bit the behaviour, the only workaround I found ON MY SYSTEM to use KMEM today with SODE and AI Traffic is to slow down my Fsx performance at a specific time:
Maybe it's our systems being over stressed?
-
YES!!!! And after one month fighting I FOUND how I can avoid the KMEM g2d.dll crash on MY system:
I SIMPLY DISCONNECT THE TV I USE SOMETIME AS 2ND DISPLAY ON MY COMPUTER.
I have a Nvidia 650 GTX graphic card with latest driver. On this card a Matrox Triplehead Digital 2G is connected via DVI as a primary display with 3x19" monitors on it = 3840x1024. I use Fsx in full screen mode on this display.
The TV set is connected to the Nvidia card via HDMI as 2nd display. I don't use it with Fsx as I'm in full screen mode (I have a networked laptop to display EFB moving map).
So it seems that my graphic card was over stressed when loading KMEM (and only KMEM?) with 2 displays. If someone can explain me why the issue is just with KMEM I'll appreciate. First time I see that with Fsx and my current hardware.
It's a chance I disconnected my 2nd display to check if I can get more FPS on KORD (wich is a FPS killer with AI Traffic) and go ahead with my usual crash test scenary on KMEM.
Sorry if I spamed everyone with my posts but you'll agree that the problem was very unusual. When I performed tests with Umberto connected with teamviewer we didn't have any crash but the second display was connected... So I imagine the graphic card was not stressed due to this screen mirroring.
Skip.
-
Great news Skip. Ummm, "Your" setup sort of typical of systems out there, with the second screen BUT, being a TV, it may have given the video card some issues. Anyway, Seems you are sorted.
Hnla, I am not in any way support. Just a user, just like you. I have been offering my thoughts as a way of trying to calm the waters being a "devils advocate" between you and FSDT. I can 'help' no more, sorry if my comments were not useful.
-
So it seems that my graphic card was over stressed when loading KMEM (and only KMEM?) with 2 displays. If someone can explain me why the issue is just with KMEM I'll appreciate. First time I see that with Fsx and my current hardware.
I guess it might just be that KMEM uses quite a bit of texture memory ( VRAM ) and of course, when driving 4 displays (it's not 2, it's 3 for the Matrox plus 1 for the TV ), you consume more VRAM than normal.
Or, if you have plenty of VRAM available ( you might try checking it with GPU-Z ) it might just be a video driver memory allocation bug.
I was quite sure the G2D.DLL couldn't have anything to do with our code, and this was the definitive proof.
-
Great- now it just leaves myself...
-
Don't forget to turn the light out
-
"that KMEM uses quite a bit of texture memory ( VRAM )"
Light out! bye.
-
"that KMEM uses quite a bit of texture memory ( VRAM )"
Light out! bye.
I'm not sure what you are trying to say, but I simply posted something, which included a suggestion to use GPU-Z to check if you ARE low in VRAM in that particular situation, because I cannot obviously imagine any other cause.
Note that, KMEM uses LESS RAM than, for example, KLAX, but it might use more VRAM instead. There's really no "free lunch", you either optimize in a way or in another. The correct way forward, especially under a 32 bit sim, when we don't have so much RAM available, is to push in the direction of using more VRAM, for the obvious reason that video cards with more and more VRAM are easier to get than having to wait for a 64 bit version of the sim and of course, even if we *had* a 64 bit version of the sim, pushing on VRAM usage instead of RAM, would always be faster, since newer video cards increase in speed WAY more than the main CPU would ever be able to.
Of course, users with a very unusual configuration ( 3 monitors AND a TV is, sorry, far from being normal, and you cannot expect we would anticipate or test under this conditions ), might be more exposed to VRAM usage, since they DO use more VRAM *BY DEFAULT*. Again, there's no "free lunch". You want to drive 4 screens ? There's a resource costs associated with it.
But this is just a THEORY, which is why I suggested to verify, using GPU-Z, if you *really* are low on VRAM when KMEM is loaded *and* your TV is connected. If you are low on VRAM, there are things that can be tried to reduce its consumption, such as reducing the texture resolution, for example.
But maybe you are *not* low on VRAM ( again, GPU-Z should tell you ), and the reason is just more mundane, and you simply found a BUG in the video driver, that will cause FSX crashing when so many displays are connected, that happens only at KMEM because you need to consume AT LEAST a certain amount of VRAM, without necessarily exhausting it all.
-
Great- now it just leaves myself...
I still get it and it's not my vram, single monitor operation, UT2 which I have turned off, EZdok which I updated and I have everything from FSDT updated. I just got tired of mention it. As a member of a large VA members have asked for my opinion of KMEM because they know I'm a scenery collector. I can not recommend KMEM as a stable purchase. I do recommend anything prior to KMEM, just not Memphis.
Sent from my iPhone using Tapatalk
-
Great- now it just leaves myself...
I still get it and it's not my vram, single monitor operation, UT2 which I have turned off, EZdok which I updated and I have everything from FSDT updated. I just got tired of mention it. As a member of a large VA members have asked for my opinion of KMEM because they know I'm a scenery collector. I can not recommend KMEM as a stable purchase. I do recommend anything prior to KMEM, just not Memphis.
Sent from my iPhone using Tapatalk
I have tested just about everything too. I wonder how many other users are on our same boat as well but not posting...
-
And of coarse, I am always still open to do a teamviewer. Even though it's impossible for us to find a time that works for both of us...
-
I have a single BenQ 32 monitor and I'm running a GTX960FTX video card. I find it hard to believe Memphis is maxing out my video card VRAM. I even used GPU app to monitor it and it's not stressing the card one bit. There is still some conflict going on.
Sent from my iPhone using Tapatalk
-
I still get it and it's not my vram, single monitor operation, UT2 which I have turned off, EZdok which I updated and I have everything from FSDT updated.
I wasn't responding to you, but to Skippy, which confirmed HE has entirely fixed HIS problem by disconnecting one display. So, in HIS case, I suggested to CHECK the amount of available VRAM, obviously adding that I'm not *sure* it's just a "lack" of VRAM, but might simply be a video driver bugs that, in HIS case, happens only because KMEM possibly use a bit more VRAM than USUAL.
That doesn't obviously mean you have the SAME problem, it's just you still haven't found YOUR reason for a crash.
I just got tired of mention it. As a member of a large VA members have asked for my opinion of KMEM because they know I'm a scenery collector.
Right now we still haven't been able to prove that *any* of the reported crashes are CAUSED by IT, and not something else. It's just that the "something else", it's not the SAME for everyone.
-
I kind of figured that. I have been trying every step I see posted to see if it helps my situation.
Sent from my iPhone using Tapatalk
-
Well... I thought all will be ok now removing the 2nd display (in Windows the 3 monitors connected to Matrox Triplehead are seen as one large display) but performing a "normal" flight from KDFW to KMEM I got the g2d.dll crash on ILS27 final :(.
I'll try the same flight with antipopup set to 30 instead of 21 but I can't stand reducing my Fsx performance.
Skip
-
2nd try was OK after PC restart (the first time I ran Fsx at KDFW and interupted the flight so the I can't be sure everything was clean when my crash occured). I set antipopup to 30 but as this 2nd flight was very diffrent (ILS09 with rain and storm on KMEM, no aircraft shadow, FPS slower) it's not significant.
So approaching KMEM is still a kind of russian roulette for me. The good news is that I can start a flight now without problem.
-
Have you installed the latest updated we had yesterday ? It's supposed to fix another crash we found only on exit but, who knows, it might behave differently on your system.
-
Installed the update.
Thought maybe for a second that the crash was fixed because FSX didn't crash right upon loading KMEM the first time.
After 8 trials I finally got it to crash as normal:
Faulting application name: fsx.exe, version: 10.0.61637.0, time stamp: 0x46fadb14
Faulting module name: MSVCR80.dll, version: 8.0.50727.6195, time stamp: 0x4dcddbf3
Exception code: 0xc000000d
Fault offset: 0x00008aa0
Faulting process id: 0x128
Faulting application start time: 0x01d1eaa39984c97e
Faulting application path: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\fsx.exe
Faulting module path: C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.6195_none_d09154e044272b9a\MSVCR80.dll
Report Id: 7e4683b9-5697-11e6-9548-8c89a51aac22
-
This "may" help you. http://forum.aerosoft.com/index.php?/topic/96119-fsx-crashes-telling-me-the-problem-is-msvcr80dll/
"
The Microsoft C++ Redistributables 2005 , 2008, 2010, 2012 and 2013, 32bit and 64bit.
And before you ask, I don't have any ready download links. Please use Google to find them on the Microsoft website."
-
This "may" help you. http://forum.aerosoft.com/index.php?/topic/96119-fsx-crashes-telling-me-the-problem-is-msvcr80dll/
"
The Microsoft C++ Redistributables 2005 , 2008, 2010, 2012 and 2013, 32bit and 64bit.
And before you ask, I don't have any ready download links. Please use Google to find them on the Microsoft website."
Thanks for your suggestion, but it isn't a problem with MSVCR. The module changes every crash. Something in KMEM makes my system go haywire.
-
See, here's another
Faulting application name: fsx.exe, version: 10.0.61637.0, time stamp: 0x46fadb14
Faulting module name: FSUIPC4.dll_unloaded, version: 0.0.0.0, time stamp: 0x575f3e3a
Exception code: 0xc0000005
Fault offset: 0x63d06340
Faulting process id: 0x8f8
Faulting application start time: 0x01d1eb40a1c495aa
Faulting application path: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\fsx.exe
Faulting module path: FSUIPC4.dll
-
Faulting module name: MSVCR80.dll, version: 8.0.50727.6195, time stamp: 0x4dcddbf3
Visual C++ runtimes. Nothing that has anything to do with KMEM, of course...
Faulting module name: FSUIPC4.dll_unloaded, version: 0.0.0.0, time stamp: 0x575f3e3a
Same as above. We don't have any interaction with FSUIPC.
Thanks for your suggestion, but it isn't a problem with MSVCR. The module changes every crash. Something in KMEM makes my system go haywire.
Obviously not. It's exactly the opposite. Something wrong in your system makes random loaded modules, even the one that don't have ANYTHING to do with KMEM, crashing for some reason, and you are mislead into thinking it has anything to do with KMEM, but only because it's something related to this area, either an AI or something that might affect FSUIPC.
Didn't Pete Dowson said the FSUIPC crash was somewhat related to weather ? We don't obviously touch anything in the weather, but maybe another 3rd party addon is playing with some bogus weather data AT KMEM, so you are mislead thinking it "must" be FSDT KMEM ?
A very easy question that should let you think:
- Why NOBODY else is reporting FSUIPC or MSVCR80.DLL crashes at KMEM, except you ?
-
Didn't Pete Dowson said the FSUIPC crash was somewhat related to weather ? We don't obviously touch anything in the weather, but maybe another 3rd party addon is playing with some bogus weather data AT KMEM, so you are mislead thinking it "must" be FSDT KMEM ?
We ruled out weather and he basically said it must be because something in the scenery is corrupt
Quote From Pete:
It could also be a corruption in one of the BGL's or textures loading for that scenery
If it is scenery corruption I guess the only solution would be to uninstall and reinstall that scenery.
Which I did, of coarse.
-
We ruled out weather and he basically said it must be because something in the scenery is corrupt
The scenery has no interaction whatsoever with FSUIPC so, I wonder how it could be able to crash it. Do you still have crashes if you disable FSUIPC ?
Which I did, of coarse.
Which indicates the scenery's fine.
-
Hnla, I'm back again. Every time I log in, I think about your issue.....which I see does not seem to be progressing.
So, How about taking your FSX system back to basic. Remove, or disable FSUIPC, any weather, (including clouds) any traffic, any other sceneries, GSX etc, and BGL's you may have created. Also, disable the FSX.cfg, so that FSX builds a new cfg file when it starts.(you should put in the HIGHMEMFIX=1 in [GRAPHICS] fix into the new cfg file) Remove all monitors, (ummm skippy, four screens!!!)other than one. So when you fire up FSX, it is if you had just loaded FSX from new in 2006.
Now, if you do not already have it, download this scenery editor, https://sourceforge.net/projects/fs-sceditor/ It is now version 1.17
Load it and you can actually see what scenery is loading in FSX. Use the 'List' tab, you can see which scenery(s) are loading into FSX. You can de-tick all the third party scenery to NOT load, so that when you fire up FSX, only stock airports and sceneries you left selected, loads. This neat little program also indicates if there are any scenery errors.
Just to make sure it all works, fire up FSX, choose a stock a/c, and load into any non third party airport like KLAX. Do a circuit. All fine? Great, your FSX system works as intended. Close FSX.
Open the Scenery Config Editor and select KMEM. Save file. Now fire up FSX. From splash screen, select KMEM, active runway. Use a stock a/c(trying to make sure memory is always conserved) If you can get to KMEM ok, do a circuit or two. NOW, if this works for several flights, load a PMDG a/c..it will give the memory a bit of a work out, see if this is ok. If so, you need to introduce the items you disabled one by one, making sure you close FSX. Sooner or later, you may experience the crash again after installing one of the add ons
Anyway, a long winded way to say go back to basic config and sort of creep up on your crashes. Probably by now, many people have purchased KMEM and are using it, proving it does work, you just have to figure out what is causing FSX to crash with KMEM.
-
Instead of actively defending your product I suggest you all go and run some tests because the fact that several customers have an issue with the scenery should warrant some investigation. This is VERY poor customer service on your part. I'm only in here because I tried to fly into Memphis not even 10 minutes ago and had a CTD AGAIN. Having spent our money the very least y'all could do is TRY to figure out why the thing is crashing when we try to fly into it. >:(
-
Umberto
I now able to reproduce the G2D.Dll error 95% of the time. If I load any of my pay ware aircraft like the Aerosoft A320, PMDG 777 & 737, SimCheck A300, CS 757 or LDS767 and I start in Windows Mode and cycle to Full Screen (Alt+Enter) I can get it too crash. I've had it crash a few time with default aircraft but now I can reproduce it the majority of the time if I use a complicated plane. Crashes only seem to happen when in Full Screen or switching to full screen. Of all the scenery this only happens @ KMEM.
I even down clocked my CPU. I turned off EZDok, SOD, UT2 in the EXE.XML and also turned off UT2 and my AI in SimObjects but that didn't help. I even went as far as disabling all my add-on scenery except for KMEM and If I (Alt+Enter) it crashes.
My specs:
i7 4790K
EVGA GTX960 FTX (not over-clocked, latest drivers) Previous drivers also did it.
Have the standard FSGlobal 2010, GEX, UTX installed on FSX w/Accell.
Latest EZDok and FSUIPC.
I'm up for a TeamViewer session.
-
Do you still have crashes if you disable FSUIPC ?
Yes.
So, How about taking your FSX system back to basic. Remove, or disable FSUIPC, any weather, (including clouds) any traffic, any other sceneries, GSX etc, and BGL's you may have created. Also, disable the FSX.cfg, so that FSX builds a new cfg file when it starts.(you should put in the HIGHMEMFIX=1 in [GRAPHICS] fix into the new cfg file) Remove all monitors, (ummm skippy, four screens!!!)other than one. So when you fire up FSX, it is if you had just loaded FSX from new in 2006.
This is basically what i've already done. I reset my FSX.CFG, Removed FSUIPC, Weather, Installed latest graphic drivers... nothing.
I'm up for a TeamViewer session.
I've already offered a teamviewer to him multiple times but It doesn't seem to be his priority
-
This morning I started by disabled everything in my dll.xml and I get the same result. As soon as I Alt+Enter, crash. My FSX pretty mush has everything disabled except KMEM. I am now trying a fresh FSX.cfg. Maybe it is an entry in there that may be causing the issue..
-
This morning I started by disabled everything in my dll.xml and I get the same result. As soon as I Alt+Enter, crash. My FSX pretty mush has everything disabled except KMEM. I am now trying a fresh FSX.cfg. Maybe it is an entry in there that may be causing the issue..
I doubt it, I've done the exact same thing to no result. It's unlikely a line in ur CFG is causing a crash ONLY at KMEM
-
Ummm, People have been using FSDT airports for years. Buy it, use it, enjoy... For some reason, the FSDT KMEM coding is different to the others, and seems to really stress computer systems.
-
This morning I started by disabled everything in my dll.xml and I get the same result. As soon as I Alt+Enter, crash. My FSX pretty mush has everything disabled except KMEM. I am now trying a fresh FSX.cfg. Maybe it is an entry in there that may be causing the issue..
I doubt it, I've done the exact same thing to no result. It's unlikely a line in ur CFG is causing a crash ONLY at KMEM
when I use my config file it always crashes but if I start with a fresh one I cannot get it to crash. I'm going line by line now to see what could possibly be causing it.
Sent from my iPhone using Tapatalk
-
I'm fairly confident it has todo with SODE. it will work if u reset ur FSX.cfg because it removed the SODE line
Sent from my iPhone using Tapatalk
-
I'm fairly confident it has todo with SODE. it will work if u reset ur FSX.cfg because it removed the SODE line
Sent from my iPhone using Tapatalk
I'll look further into this.
-
Well I spent the last 5 hours this morning going step by step trying to figure this out. I currently have everything disabled in my EXE and DLL XML files. I also disabled all add-on scenery except for default and FSDT KMEM. I have also started with a clean fsx.cfg and added line by line after each restart. So far I have been able to reproduce the G2D.DLL crash when I put the following lines back in the [Trusted].
C:\Program Files (x86)\12bPilot\SODE\SimObjectDisplayEngine.exe.crwbtaloqihzenbeawizobebkkttooikcakttelk=1
C:\Program Files (x86)\12bPilot\SODE\SimObjectAnimationModule.dll.koqaezirltlqzrwwqboaobertbklcnenraccwtaa=1
In DLL.XML I have the following for SOD
<Launch.Addon>
<Name>SODE Animation Module</Name>
<Disabled>True</Disabled>
<ManualLoad>False</ManualLoad>
<Path>C:\Program Files (x86)\12bPilot\SODE\SimObjectAnimationModule.dll</Path>
</Launch.Addon>
In the EXE.XML I have the following for SOD
<Launch.Addon>
<Name>SODE</Name>
<Disabled>True</Disabled>
<ManualLoad>False</ManualLoad>
<Path>C:\Program Files (x86)\12bPilot\SODE\SimObjectDisplayEngine.exe</Path>
<CommandLine>FSX</CommandLine>
</Launch.Addon>
I also have the SimObjectDisplayEngine.exe set to run as administrator.
SimObjectDisplayEngine.exe v1.3.3
SimObjectAnimationModule.dll v1.3.3
Any suggestions?
-
So basically we are no further than before. If you look back a few pages before with Skipp33, he did the exact same tests with SODE, and when he removed the sode lines, he got no crashes.
FSDT was unable to offer any solutions
-
Reading skipy33 fix, currently my BenQ BL3200PT monitor is connected via DisplayPort cable to my GTX960FTX. I was wondering if I should connect via HDMI or DVI. I moved all my original files (fsx.cfg, dll.xml, exe.xml) back except for all SOD references and it crashed again. I'm at a lose now.
-
G2D.DLL back again >:( >:( >:(. I give up. Now with no SOD entries or any other entries I get the error again. I'm pulling my hair out here. Just for kicks I loaded KLAX and KIAH, no problems. Just Memphis. I think it's time to toss in the towel. FYI, I have been using the Ultralight for all my test today.
I guess my next step is to test it out on my P3Dv3 install. I have a separate SSD with a mirror image of windows but separate from the other drive. On it I recently installed P3Dv3 with FSGlobal 2010, GEXP3D and UTX. Only add-on is FSUIPC. Lets see if I get the same problems.
As of 20 minutes ago I have no issues with P3D to report.
-
Instead of actively defending your product I suggest you all go and run some tests because the fact that several customers have an issue with the scenery should warrant some investigation.
I hope you don't honestly believe what you just wrote. And if you just followed this thread, you would have known that we already ran EACH and EVERY possible test, and not just on our systems, but on users systems too, having many Teamviewer sessions. There hasn't been any more through "investigation" than we made and still making constantly.
After EACH report, we start and restart the sim at KMEM dozen of times, with every possible combination of addons, but as of today, the only crash that we were ever able to reproduce so far, were on exiting the sim, they happened ONLY in kernelbase32.dll or ntdll.dll, and we fixed all the ones we could find.. Read the release notes.
The issues is, we haven't been able to replicate a SINGLE case of either G2D.DLL crashes or FSUIPC.DLL crashes so far.
-
I'm home now if your up for a TV session. I sent you a request.
Sent from my iPhone using Tapatalk
-
Instead of actively defending your product I suggest you all go and run some tests because the fact that several customers have an issue with the scenery should warrant some investigation.
I hope you don't honestly believe what you just wrote. And if you just followed this thread, you would have known that we already ran EACH and EVERY possible test, and not just on our systems, but on users systems too, having many Teamviewer sessions. There hasn't been any more through "investigation" than we made and still making constantly.
After EACH report, we start and restart the sim at KMEM dozen of times, with every possible combination of addons, but as of today, the only crash that we were ever able to reproduce so far, were on exiting the sim, they happened ONLY in kernelbase32.dll or ntdll.dll, and we fixed all the ones we could find.. Read the release notes.
The issues is, we haven't been able to replicate a SINGLE case of either G2D.DLL crashes or FSUIPC.DLL crashes so far.
You would if you did a team-viewer on my computer
-
I just came back from a Teamviewer session with Wise87. His situation was:
- With no 3rd party modules enabled, except the FSDT ones, immediate crash in G2D.DLL after switching to Full Screen, even with the default Trike Ultralight.
He previously mentioned that he didn't had any crashes when resetting the FSX.CFG file to default, but it reappeared as soon as he replaced a previous version so, I checked the FSX.CFG file, and found these lines:
[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!!
I then re-enabled ALL the 3rd party modules (which were a lot), tested it again, and no problems whatsoever: we could switch in Full Screen with no issues. While we were chatting, we kept FSX running for at least 15 minutes, with GSX doing service on the Aerosoft Airbus, and it worked normally all the time. SODE jetways worked too.
Searching on the web, resulted that it was very well known that setting PoolSize = 0 is very risky and can cause crashes, and this was years before KMEM was released: I found posts dated as far as 2010 discussing this. The general consensus is, unless you have a card with a lot of memory, it's best not use it.
-
Thanks a bunch for all the help today. Looking forward to flying into Memphis.
Sent from my iPhone using Tapatalk
-
Sorry, I have no Bufferpools line in my FSX.CFG.
Try again.
-
Sorry, I have no Bufferpools line in my FSX.CFG.
Try again.
This clearly fixed the issue for Wise87 and, since it wasn't clearly at "KMEM problem", we can safely assume yours isn't too.
Everything related to the Bufferpools section, is handled in G2D.DLL. So, it's not surprising it was crashing there. When users on the web found undocumented parameters, like the UsePools setting, it was found by peeking into the G2D.DLL itself.
Even if you don't have any line, that doesn't mean there isn't a setting: just the FSX default setting (4MB) is not right FOR YOUR SYSTEM, but it was for Wise87's. So, you might try to SET IT explicitly, and try different sizes and see if it makes any difference.
Of course, the Addon Manager can help you tweaking this too.
-
But my crashes aren't G2D.. They are just random stupid modules.. Why...
It always happens when KMEM is loaded
-
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.
-
Yes I am aware I am the only one. I guess the hard truth is there is no solution.
-
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 ?
-
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?
-
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
-
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.
-
Thank you for all your help.
Sent from my iPhone using Tapatalk
-
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.
-
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
-
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.
-
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.
-
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.
-
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^^^
-
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.
-
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.
-
Reducing textures size didn't make it go away.
Taking away traffic didn't make it go away.
Nothing seems to cure this problem.
-
Then you should try to enquire with PMDG since:
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.
Try to say this to PMDG support, maybe they have an explanation why the Aerosoft Airbus (and I guess any other default airplane too) doesn't crash at KMEM, but the PMDG does.
-
I run FSX Steam and KMEM crashes often with the Aerosoft Airbus 318/319. The crash almost always indicates EzDok and ntdll, but not always. I have the latest EzDok. I have also crashed when not running EzDok. If it doesn't crash shortly after startup with EzDok, then it sometimes crashes when I start radar contact.
I don't think that it is OOM. It happens at very low and very high graphics/texture settings. If it doesn't crash in the first few minutes, then I can run flawlessly from KMEM to KIAH or other complex payware airports without any problem. The crash is only at KMEM and not at KIAH or any "heavy" ORBX airport.
I am just mentioning this as an FYI. At most, I need to restart twice. If it doesn't crash in the first few minutes, it works perfectly and I cannot get it to crash no matter what I do.
If the problem is not KMEM, then perhaps KMEM is exposing a bug in some other misbehaving software.
-
I am just mentioning this as an FYI. At most, I need to restart twice. If it doesn't crash in the first few minutes, it works perfectly and I cannot get it to crash no matter what I do.
That's sort of what I am experiencing too... except if FSX is going to crash, it will always happen on the initial load of KMEM. If KMEM loads correctly, that FSX won't crash no matter what I do.
That's what Umberto experienced when he did a team viewer... it loaded correctly so he "thought" that it was all solved.
The reason why it's annoying is that I can never land at KMEM because of the risk of getting the crash.
-
If the problem is not KMEM, then perhaps KMEM is exposing a bug in some other misbehaving software.
Yes, of course the problem is not KMEM, I think we already proved this. The problem might just be that too many addons use different/wrong/outdated versions of libraries, and this will make the software more prone to errors, that will appear more frequently there, just because it's running more code.
-
Try running with all AI traffic disabled. Several years ago I had an issue with a flawed AI paint that would crash my sim at certain airports.
Jim
-
Hmm, I had the issue of loading to KMEM with the PMDG 737 at a gate and having an immediate crash of FSX. What I do now that works is load to an active runway first, let everything load in, then use GSX to relocate me to a gate, then load the panel state CLD at the gate. Works for me.
-
Hmm, I had the issue of loading to KMEM with the PMDG 737 at a gate and having an immediate crash of FSX. What I do now that works is load to an active runway first, let everything load in, then use GSX to relocate me to a gate, then load the panel state CLD at the gate. Works for me.
Interesting. Sort of sounds like you are creeping up on your memory boundary. By loading away from airport buildings until FSX settles down to load scenery, then when you move via GSX, for some reason the memory use is handled better.
-
Oh.. the errors go on and on forever...
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: 0x578e6097
Exception code: 0xc0000005
Fault offset: 0x6a9578f0
Faulting process id: 0x8e4
Faulting application start time: 0x01d1fed6856d7079
Faulting application path: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\fsx.exe
Faulting module path: bglmanx.dll
Report Id: 6a9d201f-6acd-11e6-8d5d-8c89a51aac22
-
Oh.. the errors go on and on forever...
Nobody ever reported such error in the whole forum, for the past years..
You are the only one that ever reported an error with bglmanx.dll_unloaded, a while ago (just search the forum), this is the 2nd report, again by you so, it's clear the problem is in your system.
-
And the KMEM CTD's continue...
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: 0x1318
Faulting application start time: 0x01d202c08a848fc8
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
-
And the KMEM CTD's continue...
On you system only, and nobody else ever reported them anymore. You are still the only one still reporting this, so it's clearly not a problem if the scenery.
-
and nobody else ever reported them anymore.
More like everyone has given up...
-
More like everyone has given up
Nobody is giving up. You seem to forget that KMEM, like everything else, is sold in TRIAL VERSION. If the problem really happened to many people, we would surely have noticed it by now, since nobody would buy it anymore...
No, that's only your own assumption, because you don't want to accept the fact that you are still the only one with the problem left. This assumption is hurting you, because by continuing to assume the problem is caused by KMEM, you are not finding what the real cause.
Again, the fact is happening at KMEM (which I believe this would be your next reply), it's only a symptom that your system has a problem that can only appear on a scenery that uses your video card more than the average scenery does.
Which is obviously an indication of how GOOD it is. CPU-bound sceneries might be more resilient to your video card quirks and bugs, but they are something for the past century, and you pay this dearly, with fps that do not go up, regardless how much hardware you have.
I also don't think running the old standard FSX from 2007 is a very smart thing to do in 2016. Not many 9-years old games runs correctly on the latest OS and video cards.
If you don't want to upgrade to P3D (which would be MY suggested course of action, since is SO MUCH better), at least consider updating to the *current* FSX version, which is FSX:SE.