Okay. I've made a change in FSUIPC version 4.749a which patches G3D.DLL in the routine which was responsible for my crash and all of those of Word Not Allowed and several others. It doesn't cover all of the possible G3D crashes I'm sure. But these are known reproducible ones and I need to see if my technique for avoiding them works or simply leads to further, different, failures because I'm allowing corruption to continue further.I can't tell. The one I had was the only one I've had in many months and in a place I regularly fly without problems. So I am unable to prove anything one way or the other.So, please let me know. downloadhttp://fsuipc.simflight.com/beta/FSUIPC4749a.zipand put it in the FSX Modules folder (you have to have previously installed a FSUIPC 4.7xx, but you need not be Registered, though of course I'd hope you all are <G>).Note that this only applies to FSX SP2 or Acceleration versions. The SP1 and RTM version of G3D is quite different. I might consider extending it to ESP, and even Prepar3D, if it helps at all, but I suspect ESP should be forgotten and Prepar3D should be fixed properly by Lockheed-Martin. I'm only really interested in helping FSX because it's got no developer (and because i'm using it, of course! ;-) )..That's all. If you can reproduce the G3D crash, or get another, please report it, again with the Version, the Module and the Offset. If your session runs to a conclusion, after you close down FSX, get the FSUIPC4.LOG file (not the Install log), and look at it. Near the start there should be a line like this: 2907 G3D.DLL fix attempt installed okand, more importantly, right near the end there will be a line like this:G3D fix: Passes 493, Null pointers 0, Bad reads 0, Bad writes 0The first number is how many checks for a bad pointer have occurred. Oddly enough, the routine I'm hacking isn't used all that often -- it has a lot of passes during loading, and then, I assume, when loading new scenery or scenery textures, but it isn't as often as you might think. The above lines are from my development PC which only has a default FSX installed. Tomorrow I'll run it only my full cockpit which has loads of add-on sceneries, and REX, UTX etc etc.The other three counts are of any bad pointers detected. Please let me know if that's ever non-zero and you didn't have a crash, because that means it succeeded is averting a crash. Let me know if there were any noticeable side effects too.Good flying!RegardsPete

Before I go to bed, I quickly tested the file. Preliminarily nothing really changed - those AS sceneries I have still crash with the same offset error, g3d.dll as usual.Now, tomorrow I'll do some extensive testing, now it's 2AM...

The place I get in version 61637 is offset 000BA79F.

Are you guys with that number combo using AES? Does it help when you disable it for testing?Otherwise the g3d error should happen in close proximity to an AES enabled airport, e. g. when catching the localizer.The Aerosoft airports often use the Vistamare module for their ground traffic. So even when not running the AES activation there, the AESlite part is active and initializes some nm out I think.

Okay. I've made a change in FSUIPC version 4.749a which patches G3D.DLL in the routine which was responsible for my crash and all of those of Word Not Allowed...If you can reproduce the G3D crash, or get another, please report it, again with the Version, the Module and the Offset. If your session runs to a conclusion, after you close down FSX, get the FSUIPC4.LOG file (not the Install log),

Can I suggest opening a socket via LUA for auto-reporting to a web of yours? Perhaps fixing this bug (and other fixable bugs that might occur) could be an interesting line of future development for FSUIPC. :Big Grin:Alternatively, Microsoft ought to have a database of FSX CTDs it has collected from us over the years that they could share with you in statistical/summary form.Cheers,- jahman.

After copied the new FSUIPC.dll I finished 3 times flying over the same AS underground and the G3D.dll error is still there.Version 61637Module g3d.dllOffset 0x000ba79fIn the FSUIPC.log I did not find the line with the passes, null pointers etc.Do I have to do something to make it appear ?********* FSUIPC4, Version 4.749a by Pete Dowson *********User Name="xxxxxxxxxxxx"User Addr="xxxxxxx@casema.nl"FSUIPC4 Key is providedWideFS7 Key is providedRunning inside FSX on Windows 7Module base=61000000 47 System time = 29/11/2011 09:17:28 78 FLT UNC path = "SERVERFlight Simulator X Files" 94 Trying to connect to SimConnect Acc/SP2 Oct07 ... 110 FS UNC path = "SERVERMicrosoft Flight Simulator X" 390 LogOptions=00000000 00000001 390 Wind smoothing fix is fully installed 390 G3D.DLL fix attempt installed ok 390 SimConnect_Open succeeded: waiting to check version okay 390 Trying to use SimConnect Acc/SP2 Oct07 390 VRI port 2 "com5" opened 406 VRI port 1 "com3" opened 936 Running in "Microsoft Flight Simulator X", Version: 10.0.61637.0 (SimConnect: 10.0.61259.0) 936 Initialising SimConnect data requests now 936 FSUIPC Menu entry added 968 SERVERMicrosoft Flight Simulator XFLIGHTSOTHERFLTSIM.FLT 968 SERVERMicrosoft Flight Simulator XSimObjectsAirplanesAircreation_582SLAircreation_582SL.AIR 1748 VRI CDU ("CDU") detected on port com5 1857 VRI FMER ("MCP Combi") detected on port com3 15117 SERVERMicrosoft Flight Simulator XSimObjectsAirplanesPMDG 737-800NGX WLB737-800WL.AIR 15117 Weather Mode now = Theme 15117 SERVERFlight Simulator X FilesPMDG 737NGX at cruise altitude coming from Schiphol going to Frankfurt rw 25R.FLT 19251 System time = 29/11/2011 09:17:47, Simulator time = 16:32:05 (15:32Z) 19360 Aircraft="Boeing 737-8K2NGX KLM Royal Dutch Airlines Winglets" 146548 Starting everything now ... 146563 LUA: beginning "D:Microsoft Flight Simulator XModulesipcReady.lua" 146563 LUA: ended "D:Microsoft Flight Simulator XModulesipcReady.lua" 146579 LUA: 146579 LUA: [iNIT]LINDA:: Loading... 146657 LUA: LINDA:: Aircraft: Boeing 737-8K2NGX KLM Royal Dutch A 146673 LUA: LINDA:: Aircraft module detected: PMDG 737NGX 146688 LUA: LINDA:: AivlaSoft library loaded... 146688 LUA: LINDA:: FSX standard library loaded... 146704 LUA: LINDA:: IAO library loaded... 146704 LUA: LINDA:: RealityXP library loaded... 146704 LUA: LINDA:: A2A MAP library loaded... 148591 LUA: LINDA:: Module: PMDG 737NGX Started... 148591 LUA: LINDA:: Ready to go, Captain! 148591 LUA: LINDA:: 148654 LUA: LINDA:: Offsets watching list cleared! 204253 Advanced Weather Interface Enabled

That line, 390 G3D.DLL fix attempt installed ok, doesn't appear here. Am I doing something wrong?

Before I go to bed, I quickly tested the file. Preliminarily nothing really changed - those AS sceneries I have still crash with the same offset error, g3d.dll as usual.Now, tomorrow I'll do some extensive testing, now it's 2AM...

Strange. If it is exactly the same offset then there should be a non-zero count in the summary at the end.Pete

After copied the new FSUIPC.dll I finished 3 times flying over the same AS underground and the G3D.dll error is still there.Version 61637Module g3d.dllOffset 0x000ba79fIn the FSUIPC.log I did not find the line with the passes, null pointers etc.Do I have to do something to make it appear ?

BA79F is the place I've hooked, so I don't quite understand -- I'll re-check the code in that area to see.[LATER] Ooops! There's a loop I missed seeing. The bad value points to data in a chain, and is replaced iteratively in the loop.Sorry guys, I'll work on a 'b' version for later today. It looks like the original pointer is okay for the chained list it processes eventually bumps into a bad'un! I'll move the patch to inside the loop.BTW the summary you refer to occurs at the end of the Log, when FSUIPC terminates normally. If FSX still crashes you won't get that far, and there's no need in any case. The point of the summary was to see if it WOULD have crashed without the attempted fix.RegardsPete

That line, 390 G3D.DLL fix attempt installed ok, doesn't appear here. Am I doing something wrong?

The "390" is merely the elapsed time since FSUIPC started. That's not relevant. But if the text is not there then either you are not using 4.749a (check the title at the start of the Log), or the patch couldn't be applied because the code doesn't match. Did you say you were using SP2 or Acceleration? If SP2 maybe I mad an error. I'll see if I can swap over the G3D.DLL only for a test here.RegardsPete

The "390" is merely the elapsed time since FSUIPC started. That's not relevant. But if the text is not there then either you are not using 4.749a (check the title at the start of the Log), or the patch couldn't be applied because the code doesn't match. Did you say you were using SP2 or Acceleration? If SP2 maybe I mad an error. I'll see if I can swap over the G3D.DLL only for a test here.RegardsPete

You are quite right on this one - I downloaded it in the night. Did you maybe edit your post? Because I clicked on the link, and I have both files 4.749 and 4.749a here... I'll do the test with 'a' version.

OK, I got the file loaded, now the right version is being reported, still I getFaulting application name: fsx.exe, version: 10.0.61472.0, time stamp: 0x475e17d3Faulting module name: g3d.dll, version: 10.0.61472.0, time stamp: 0x475e180cException code: 0xc0000005Fault offset: 0x000b50dfFaulting process id: 0xd18And it's only happening with relatively high VAS usage.During the day today I'll try testing ORBX with NGX at the one crashing point (have the situation saved), but right now, those Aerosoft sceneries, EBBR, EDDF, when VAS usage is high, still crash with g3d.dll, as noted above.I'm now testing if this fix allows for higher VAS usage.

Did you maybe edit your post? Because I clicked on the link, and I have both files 4.749 and 4.749a here.

You must have been extremely quick. I always test my links immediately after I post (can't test them properly at the edit stage), found it still pointed to the current release, so changed it immediately. You must have caught it within the interim -- less than a minute, I'm sure!Pete

OK, I got the file loaded, now the right version is being reported, still I get

Yes, please see earlier reply. I have to move the fix in side the loop. I hadn't realised the pointer I'm checking is only the pointer to the head of a chained list. I have to check the links too!Version 4.749b coming up in an hour or so, maybe less. Don't bother more testing on the 'a' now.Pete

Are you guys with that number combo using AES? Does it help when you disable it for testing?Otherwise the g3d error should happen in close proximity to an AES enabled airport, e. g. when catching the localizer.The Aerosoft airports often use the Vistamare module for their ground traffic. So even when not running the AES activation there, the AESlite part is active and initializes some nm out I think.

Whenever I've had a G3D.dll crash, it has more often than not pointed towards the VistaMare module...

You must have been extremely quick. I always test my links immediately after I post (can't test them properly at the edit stage), found it still pointed to the current release, so changed it immediately. You must have caught it within the interim -- less than a minute, I'm sure!PeteYes, please see earlier reply. I have to move the fix in side the loop. I hadn't realised the pointer I'm checking is only the pointer to the head of a chained list. I have to check the links too!Version 4.749b coming up in an hour or so, maybe less. Don't bother more testing on the 'a' now.Pete

Alright, will keep an eye on my iPhone - this is why I get links so quickly - subscribed to the forum, on iPhone I see an email since it's coming over push, and all I gotta do is click on the link and voila... who needs a minute!

Pete, thank you for trying to fix this, my situation is repeatable: G3D crash with Orbx PNW, with the same flight KORS/KPDX @ 6000 with the Carenado t210, at EXACTLY 80 nm from KPDX over and over...error exception code c0000005, offset 000ba7e9. vas before the crash varies from 2.8 to 3.1, depending on the settings I use, I can complete a flight IF ONLY vas stay BELOW 2.8, elsewhere in the world I sometimes see over 3.5 and still can fly without crash... Alain from Montreal

I tried this flight, same aircraft, same altitude, and I can also repeat the crash at EXACTLY 80 nm. Oddly enough my offset was different though, here's mine:Problem signature: Problem Event Name: APPCRASH Application Name: fsx.exe Application Version: 10.0.61472.0 Application Timestamp: 475e17d3 Fault Module Name: g3d.dll Fault Module Version: 10.0.61472.0 Fault Module Timestamp: 475e180c Exception Code: c0000005 Exception Offset: 000b50df OS Version: 6.1.7601.2.1.0.256.48 Locale ID: 1033Additional information about the problem: LCID: 1033Read our privacy statement online: http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409If the online privacy statement is not available, please read our privacy statement offline: C:Windowssystem32en-USerofflps.txtI'll try it again now with the new FSUIPC and see what happens.Jim

Since the LOWI patch I have not 100% crashes as before, now on rare occasions.Tried the "fix" now (no crash, but that doesn't mean anything)Just wanted to share the lines in case it would help:Average frame rate for running time of 2351 secs = 26.0 fpsG3D fix: Passes 7447, Null pointers 0, Bad reads 0, Bad writes 0Memory managed: 1030 Allocs, 1030 Freed

I tried this flight, same aircraft, same altitude, and I can also repeat the crash at EXACTLY 80 nm. Oddly enough my offset was different though

No, that's exactly the same offset for an SP2 version of G3D. The other is Acceleration, but they are both the same.

I'll try it again now with the new FSUIPC and see what happens.

Wait for the 4.749b release. I'll post the link here within the next half hour.Pete