g3d.dll......help ..!

[Kosta 122]

I know what's causing the GD3.dll crash: There's a problem with FSX scenery load thread synchronization! Recall on a 4-Core CPU the FSX sim engine runs on one core while the other three cores (or only two, if one core is reserved for the system) load scenery.If there's a thread sync bug (a semaphore or spin lock not being set, reset, or checked), then internal inconsistencies will result that will cause the GD3.dll to CTD.It is also quite likely this thread sync bug is exacerbated when the fsx sim engine core falls behind due to excessive load (PMDG 737 NGX, 4096 clouds, ORBX PNW, etc.) because that's exactly when sync is most needed.Now the missing library obects check introduces a pause, so the sim engine catches-up and the threads all geat a chance to sync-up.On the contrary, a slew of missing object GUIDS hitting the FSX sim engine core all at once cause the engine to fall behind and lose sync which triggers the GD3.dll CTD. Same when alt-tabbing into FSX just when FSX is under stress.There is of course a beautiful test for this theory: Force FSX to run on a single core (via Affinity mask 0010), because although you can have multiple threads executing on a single core, the threads themselves can't run at the same time, so the need for thread sync is greatly relaxed.In case the GD3.dll bug is somehow due to a sync problem in (or together with) Win32, you can harden the test by turning-off all CPU cores except one.Go into the BIOS, turn-off HT (if you haven't already) and also turn-off CPU Cores one to three, leaving only core 0 active.IMPORTANT NOTICE AND LEGAL DISCLAIMER: Turn-off your OC, because the thermal-protection sensors Intel builds into the CPU chip assume all four cores are running, so if they are not then your thermal protection will fail and you will burn your CPU. You have been warned!Cheers,- jahman.

OK, I'll bite on this one.Without doing many BIOS changes, how about I set AM to 1, forcing FSX to run on only core0, would that do? Without disabling OC...

Ok, I had a go with that Process Explorer. I took of from Concrete going to Anacortes. Virtual Size was around 2.300.000K (not the EXACT number, of course). After a while it slowly climbed to 2.500.000K. I decided to fly towards a point near Anacortes where I often get a crash. I noticed when I got there that the number went up to 2.900.000 K. I tried to see what happened when I moved around a lot with my head (I am using TrackIR) and I noticed the number went up when I looked around EVERYWHERE. So I fiercly moved my head, the number went over 3.000.000K and BANG... appcrash!This is a crash I can now reproduce (if I make sure to look around and let FSX load stuff, so it seems) and it's always at that same spot (flying south from Anacortes). I did however fly over that place without problems sometimes: maybe I was sitting very still at that moment...When FSX crashed I briefly saw DXDiag in the Process Explorer, and then DW20.exe showed up followed by DWWin.exe. Apparently DXDiag noticed something went wrong and ordered DW20 and DWWin to tell me so? What if I could disable DXDiag from reporting an error...? Maybe FSX crashes because it doesn't like other programs showing errors...? (Yeah, I have no clue... ;) )

DXDiag can be completely disabled by disabling error reporting in windows 7. I have that. I only see which DLL crashed, basically all I need to know. Others give no useful info to me. DW is old DrWatson I believe...

[Guest jahman]

OK, I'll bite on this one.Without doing many BIOS changes, how about I set AM to 1, forcing FSX to run on only core0, would that do? Without disabling OC...

That would work, although the hard test would be to turn-off Cores 1-3 (easy to do if your MB lets you save and restore named BIOS settings) because the OS still can run on cores 0 and 2-3.Cheers,- jahman.

[Kosta 122]

That would work, although the hard test would be to turn-off Cores 1-3 (easy to do if your MB lets you save and restore named BIOS settings).Cheers,- jahman.

Yeah, I know all that. Kind of lazy to turn off windows now, got some really cool music running now DJ Quicksilver - Deep In Motion. Off to test with AM1.

[Guest jahman]

Yeah, I know all that. Kind of lazy to turn off windows now, got some really cool music running now DJ Quicksilver - Deep In Motion. Off to test with AM1.

You mean you pick listening to music when you could be "The One" known in perpetuity to have definitely solved the GD3 CTD? Cheers,- jahman.

[Kosta 122]

[You mean you pick listening to music when you could be "The One" known in perpetuity to have definitely solved the GD3 CTD? Cheers,- jahman.

Yeah, I know... lame... If I manage that, I'll be the one living in the Matrix.......

[Kosta 122]

OK, this one-core-thing, albait software, is not a solution for my situation with broken airports. But I would be highly interested in those flying ORBX and having crashes at certain points to test this one!

[Kosta 122]

Those having ORBX issues - do you have NRM installed? Or PNW only?

[Guest firehawk44]

Hi Jim,On my system, I got g3d.dll everytime I flew from Lanai toward Honolulu and Maui always at the same spot near Dillingham field and before I get to PHOG , it can be a Skymaster or NGX, LOD4.5 or 7.5 , VAS can be as low as 3.5. Yes g3d.dll can happen in Hawaii ( beside Seattle and Orbx...). I boot up my backup drive and run the same flight and found no problem. I reinstall UTX and UT2, FSDT PHNL and Hawaiian Airports, use fsx.cfg from the good drive and so far from the last 10 days I flew back and forth the same route and never get the error ( even with lod6.5). I don't know which one solved my problem.There is some difference in the cfg file like affinilty mask, fiber frame time fraction..... I enclosed the 2 files just for your information.FSX.cfg that didn't give the error:[bufferPools]RejectThreshold=131072[DISPLAY.Device.NVIDIA GeForce GTX 580.0]Mode=2560x1600x32Anisotropic=1[GRAPHICS]AC_SELF_SHADOW=0AIRCRAFT_REFLECTIONS=1AIRCRAFT_SHADOWS=0ALLOW_SHADER_30=1COCKPIT_HIGH_LOD=1D3D10=0EFFECTS_QUALITY=2ForceFullScreenVSync=1ForceWindowedVSync=1GROUND_SHADOWS=0HIGHMEMFIX=1IMAGE_QUALITY=0LANDING_LIGHTS=1NUM_LIGHTS=8See_Self=1TEXTURE_MAX_LOAD=4096TEXTURE_QUALITY=3Text_Scroll=1SHADER_CACHE_PRIMED_10=1693500672SHADER_CACHE_PRIMED=1693500672[Main]FIBER_FRAME_TIME_FRACTION=0.33HideMenuFullscreen=1HideMenuNormal=0Location=14,6,1713,1570,.DISPLAY1Maximized=2ProcSpeed=8398PerfBucket=7[Display]TEXTURE_BANDWIDTH_MULT=40TextureMaxLoad=12TransitionTime=4.000000UPPER_FRAMERATE_LIMIT=24WideViewAspect=True[JOBSCHEDULER]AffinityMask=14 //62 56[TERRAIN]AUTOGEN_DENSITY=1DETAIL_TEXTURE=1LOD_RADIUS=6.500000MESH_COMPLEXITY=70MESH_RESOLUTION=22SWAP_WAIT_TIMEOUT=2TEXTURE_RESOLUTION=29WATER_EFFECTS=6[sCENERY]DAWN_DUSK_SMOOTHING=1IMAGE_COMPLEXITY=5LENSFLARE=0MAX_ASYNC_BATCHING_JOBS=3SmallPartRejectRadius=4.0The FSX.CFG on the drive that give the error:[bufferPools]//UsePools=0RejectThreshold=131072[DISPLAY.Device.NVIDIA GeForce GTX 580.0]Mode=2560x1600x32Anisotropic=1[GRAPHICS]AC_SELF_SHADOW=0AIRCRAFT_REFLECTIONS=1AIRCRAFT_SHADOWS=0ALLOW_SHADER_30=1COCKPIT_HIGH_LOD=1D3D10=0EFFECTS_QUALITY=1ForceFullScreenVSync=1ForceWindowedVSync=1GROUND_SHADOWS=0HIGHMEMFIX=1IMAGE_QUALITY=0LANDING_LIGHTS=1NUM_LIGHTS=8See_Self=1TEXTURE_MAX_LOAD=4096TEXTURE_QUALITY=3Text_Scroll=1SHADER_CACHE_PRIMED_10=1693500672SHADER_CACHE_PRIMED=1693500672[Main]FIBER_FRAME_TIME_FRACTION=0.25 //.17 0.33ProcSpeed=8398PerfBucket=7[Display]RUNWAY_LIGHTS_SURFACE_SCALAR=1.2 //Runway LightsRUNWAY_LIGHTS_VASI_SCALAR=0.9 // VASI LightsRUNWAY_LIGHTS_APPROACH_SCALAR=1.0 // Approach BarsRUNWAY_LIGHTS_STROBE_SCALAR=1.0 // StrobesActiveWindowTitleBackGroundColor=0,28,140,64ActiveWindowTitleTextColor=255,255,255BLOOM_EFFECTS=0ChangeTime=4.000000InfoBrakesEnable=TrueInfoLowerLeftBackGroundColor=255,0,0,128InfoLowerLeftTextColor=255,255,255InfoLowerRightBackGroundColor=255,0,0,128InfoLowerRightTextColor=255,255,255InfoOverspeedEnable=TrueInfoParkingBrakesEnable=TrueInfoPauseEnable=TrueInfoSlewEnable=TrueInfoStallEnable=TrueInfoUpperRightBackGroundColor=0,0,0,0InfoUpperRightTextColor=255,0,0NonActiveWindowTitleBackGroundColor=24,33,87,64NonActiveWindowTitleTextColor=255,255,255RUNWAY_LIGHTS_APPROACH_SCALAR=0.9RUNWAY_LIGHTS_STROBE_SCALAR=0.9RUNWAY_LIGHTS_SURFACE_SCALAR=0.9RUNWAY_LIGHTS_VASI_SCALAR=0.9SKINNED_ANIMATIONS=1TEXTURE_BANDWIDTH_MULT=80TextureMaxLoad=9 //12TransitionTime=4.000000UPPER_FRAMERATE_LIMIT=25WideViewAspect=True[JOBSCHEDULER]AffinityMask=62[TERRAIN]AUTOGEN_DENSITY=0DETAIL_TEXTURE=1LOD_RADIUS=4.500000MESH_COMPLEXITY=100MESH_RESOLUTION=23SWAP_WAIT_TIMEOUT=2TEXTURE_RESOLUTION=29WATER_EFFECTS=4[sCENERY]MissingLibraryAlert=1DAWN_DUSK_SMOOTHING=1IMAGE_COMPLEXITY=5LENSFLARE=0MAX_ASYNC_BATCHING_JOBS=3SmallPartRejectRadius=4.0

Jimmy,I have taken a look at the two fsx.cfg's you provided -- one that gave you the G3D.dll crash and the other no crash (in your quote above, I cut the configs down to size to get rid of extraeous stuff). I didn't see much difference between the two. The fact that you had no crash with a LOD of 6.5 in the no crash config and 4.5 in the config that crashed is interesting. Even more interesting was the no crash config did NOT have the MissingLibraryAlert tweak and the config that caused crashes did have the LibraryAlert tweak. However, I didn't state (and neither did the developer John V) that a LOD above the max (4.5) would always cause crashes. There are many other circumstances, like settings in FSX and your video card display driver that might be triggering these crashes. One interesting item in the two configs was your Affinity Mask entry from the config that had no crashes was 14 (not an expert but I think 15 is the correct figure for your 980X CPU so 14 is a good figure). In the config that caused the crashes, the Affinity Mask was 62 and that might have been triggering your crashes. You might want to delete the Affinity Mask entry in the crash config or change it to 14 or 15 and see if this stops your crashes. In addition, in the config that crashes, in the [Display] section, you have the same entries twice regarding runway lights with different figures. You are confusing FSX!! Doubt that could cause the crash though. Otherwise it is a mystery to me why you are receiving G3D.dll crashes in one FSX.cfg and not in the other. For more info on the Affinity Mask settings, see this excellent post: http://www.simforums...topic35391.html. I'm beginning to think maybe individuals have the wrong Affinity Mask settings. As I recall, I had an Affinity Mask setting of 255 and I changed that to 15 and I believe my crashes stopped too (but I also lowered LOD and some other FSX settings). As I understand it, it is suppose to work with the BufferPool setting. Might be something for the guru's here to take a look at.Best regards,Jim

[ZKOKQ 984]

Jim,Does removing Bufferpools (which I have) have any positive or negative effect using AM ?

[mgh 89]

gd3.dll exports the following 12 functions. In other words these are the functions that FSX can call:const ISimSystemObject::`vftable'{for `ISimEventHost'}const ISimSystemObject::`vftable'{for `ISimUnknown'}const ISimSystemObject::`vftable'{for `IVarGet'}public: __thiscall IRunwayDisplay::IRunwayDisplay(struct IRunwayDisplay const &)public: __thiscall IRunwayDisplay::IRunwayDisplay(void)public: __thiscall ISimSystemObject::ISimSystemObject(class ISimSystemObject const &)public: __thiscall ISimSystemObject::ISimSystemObject(void)public: __thiscall RUNWAY_TEMPLATE::RUNWAY_TEMPLATE(void)public: class ISimSystemObject & __thiscall ISimSystemObject::operator=(class ISimSystemObject const &)public: struct IRunwayDisplay & __thiscall IRunwayDisplay::operator=(struct IRunwayDisplay const &)public: struct RUNWAY_TEMPLATE & __thiscall RUNWAY_TEMPLATE::operator=(struct RUNWAY_TEMPLATE const &)public: struct SystemObjectCreationParams & __thiscall SystemObjectCreationParams::operator=(struct SystemObjectCreationParams const &)It would appear that:public: __thiscall IRunwayDisplay::IRunwayDisplay(struct IRunwayDisplay const &)public: __thiscall IRunwayDisplay::IRunwayDisplay(void)public: __thiscall ISimSystemObject::ISimSystemObject(class ISimSystemObject const &)public: __thiscall ISimSystemObject::ISimSystemObject(void)public: __thiscall RUNWAY_TEMPLATE::RUNWAY_TEMPLATE(void)are constructors which if repeatedly called without a corresponding call of the destructor could use up VAS

[Guest firehawk44]

Jim,Does removing Bufferpools (which I have) have any positive or negative effect using AM ?

Good question Julian. I don't know. I have little or no knowledge of it other than the link I provided above provides more info about it and there are many more forum posts around the FS community about AM/BP via a Google/Bing search. Since reading the link I provided in the post above, I have commented out Bufferpools and Affinity Mask, and flew my "crash flight" from Eugene Oregon to Seattle w/o incident. I saw little or no changes to smoothness or fps from previous flights where both were enabled. I am going to try it again with both BP and AM disabled and also disable the Missing Library Alert tweak to see if I can create another G3D crash. I haven't had one for some time now since employing the Missing Library Alert tweak and lowering some of my fsx settings....Best regards,Jim

[Guest jahman]

...are constructors which if repeatedly called without a corresponding call of the destructor could use up VAS

The standard definition of a memory leak! But most folks are getting the GD3.dll CTD below 4 GBy VAS...Cheers,- jahman.

[Vuong 0]

[You are confusing FSX!! Doubt that could cause the crash though. Otherwise it is a mystery to me why you are receiving G3D.dll crashes in one FSX.cfg and not in the other. ]Hi Jim,Thank you for pointing out the light scalar. Beside swapping the CFGs I did reinstall UT2, UTX, FSDT PHNL, FSDT Hawaiian Airports, so I don't know what solved my problem.Jimmy

[scott967 62]

I like the theory of a race/sync problem, but I have a scenario where I will get a g3d.dll appcrash during initial load. Started 6 times and it crashed 5, between 88-93% on the load bar. My VAS was around 700Mb when it crashes and if it completes loading it gets to about 1133Mb. So I tried changing AM from 14 to 2 and it crashed 2 out of 3.scott s..

[Guest jahman]

I like the theory of a race/sync problem, but I have a scenario where I will get a g3d.dll appcrash during initial load. Started 6 times and it crashed 5, between 88-93% on the load bar. My VAS was around 700Mb when it crashes and if it completes loading it gets to about 1133Mb. So I tried changing AM from 14 to 2 and it crashed 2 out of 3.scott s.

Can you try running that scenario on a single core to see if you still get the CTD?Cheers,- jahman.