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

[Guest jahman]

JahmanDon't think you need to do that, just do what I have just done, followed the route what Chris had taken. I'm getting more convinced that it looks like we both had the same scenery active.

Why not get as close to 100% replication of the CTDing flight as you possibly can? Why not go the whole 9 yards?

I flew in a beechcraft. The differences could be:1. FSX sliders set differently2. FSX.CFG totally different tweaks applied3. Different background programs running4. Different object libraries installed...

Too many variables!The trick to solving this CTD will involve isolating a single flight/Aircraft/scenery/LOD setup that will CTD 100% of the time at exactly the same location and for as many simmers as possible.Only once this crash-certain flight has been isolated will it make sense to start fiddling to find the cure:

1. Isolate the bug!
2. Study the bug!
3. Quash the bug!

Cheers,- jahman.

[Kosta 122]

Can we agree that BP settings has nothing to do with the g3d.dll crash?Agreed.Can we agree that AI settings has nothing to do with the g3d.dll crash?Agreed.Can we also agree that OC (assuming a stable OC) that it has nothing to do with the CTD?Agreed.Have we concluded that it's definitely an add-on scenery problem?Yes.Word Not Allowed, based on my experience, and my own personal test, and even your intuition, that the above is 100% accurate.

The above is accurate. Scenery causes those g3d.dll crashes, some do, some don't. So it IS scenery.How do I know? I repeated this quite more than once: two airports, one crashes, other doesn't. VAS has been manipulated by changing LOD_RADIUS as much as needed to achieve high VAS usage.I wouldn't go down and say it's because of the high usage, but the point is, one needs an a huge overhead on VAS to pass, other one doesn't.Basically like: flying towards EDDF, you need to keep your VAS below 3.4, which is REALLY hard with a big higher LOD, UTX, NGX, 4096 textures... otherwise you get a g3d.dll. VAS is going to go 100-150mb up when you reach the airport and it fully loads.Same test, just this time towards FT LOWW, VAS is 3.8, it will calmly go up to 4.0, almost before it crashes with OOM. No g3d.dll.So, why can one scenery be pushed up to 4GB VAS, and other can't. This is scenery fault.Bear in mind, flying around UTX with NGX only, without any addon airport, keeping VAS as high as 3.8GB, I am not going to see any error. Or at least I didn't yet...And all developers, ORBX or non-ORBX have to revise this. I found the reason and comparison. If it can be solved, it can only be solved by those who know scenery development AND who know their own sceneries.

[Kosta 122]

I would absolutlely agree, that 'addon scenery' is one major issue for CTD. Bear in mind that CTD/hangs are also caused by other system isuues also.The missing objects IMHO play a major part in this and by creating 'dummy' objects then we can elimate this from the equation. Yes I believe that the 'error trapping' once placed in cfg will help the crashes as it makes the FSX engine stop until you reply when the dialogue box appears.Maybe, just maybe as someone mentions earlier that getting FSX to 'save' a points whilst running helps, also.So I'm for elimating ALL missing objects, either by creating dummy bgl files and/or getting the way scenery designers create their scenery. that way we can 'tick the box on it', once and for all.I also think that the FSX code may not be as efficient in 'error handling' as it could be, hence as i started previously, it gets itself in a 'knot' and the only way out is to 'crash'

You might be right, that we are taking the potential problem out of the equation. But the point also is, there is no direct connection between the two.I think all those "I think it helped" etc, are usually only placebo effects. Or something has been changed on the configuration. Even aircraft change can mean no g3d.dll. Why? It minders the VAS load, maybe... I remember reading on some thread someone reporting flying with a NGX, getting g3d.dll, and then saying that he flew the same route with a 747 and didn't get any error! This is VAS, and VAS only problem combined with the scenery that has a problem I described above...

How can missing objects be the problem if you can get CTD even if there's no missing objects? Just wondering..

My point exactly. Fixing MLA doesn't fix g3d.dlls.

I feel so strongly its linked to FSX's inability to use add-on scenery per se not just ORBX stuff as many have the crashes around Aerosoft and other addon airports too.

I think it comes down to how scenery is made. I think many developers make sceneries in different ways, as it seems. Some are causing g3d.dlls, some don't.Say, anyone hear of g3d.dll on FSDT airport? Or FlyTampa? I haven't...

Did a 15 mins flight flying east towards OLM VOR nr Seattle with the FTX (Orbx) PNW (SP4) installed and active, at OLM I then turn to a bearing of 155 degrees towards Portland, within 1 or 2nm the sim crashed with a G3D.dll fatal error

Do you have any area beside PNW installed?

I don't think it really matters if you have the biggest PC in the world or a humble laptap, either will crash if pushed to far.

Would you please report your VAS when testing? I want to know how far your are "pushing" your system. I don't believe Autogen or Scenery Density are important - they simply slow down the FPS.

Why not get as close to 100% replication of the CTDing flight as you possibly can? Why not go the whole 9 yards?

I find this to be a great idea. A place to upload saved flight(s) to test. Default aircraft, a text readme with important settings.Not more than 2-3 situations.

[alpha117 73]

Word Not Allowed I would report on VAS if i knew how, please advise

[Guest firehawk44]

So, I was wondering, how many designers when converting FS9 to FSX have possibly left in FS9 objs?......thoughts?

As I recall, the G3d.dll CTD goes back to at least FS9 and maybe FS2K2 too. But it's a good point. Best regards,Jim

[Kosta 122]

Word Not Allowed I would report on VAS if i knew how, please advise

OK.Download: http://download.sysi...essExplorer.zipGo to Menu View -> Select Columns -> Process Memory -> deselect everything, leave Virtual Size checked, OKMain window now shows Virtual Size column, that is your VAS.

As I recall, the G3d.dll CTD goes back to at least FS9 and maybe FS2K2 too. But it's a good point.Best regards,Jim

I think the deal with FS9 might be pretty good. It's too bad we can't get all scenery developers in here to discuss this with us! And even between themselves - it would only serve them good, but that would be like getting Audi to tell BMW how to make a car.EDIT: I have made it over 5k posts, LOL. How sick is that...

[alpha117 73]

Ok, got it and have made the changes.Physical memory = 2.1GB...is that good or bad. No fsx running, that just my PC as iswhat should I be looking for/at?

[Kosta 122]

Ok, got it and have made the changes.Physical memory = 2.1GB...is that good or bad.    No fsx running, that just my PC as iswhat should I be looking for/at?

I don't know where you are reading Physical Memory, but this is what I set mine to look like (the number beside FSX is important, 2.045.896K):

[alpha117 73]

Ok my FSX figure is 1,724,784 and i'm sat at PAKTclimb out is 2,046,892

[Kosta 122]

Ok my FSX figure is 1,724,784 and i'm sat at PAKT

Alright, depending on the situation, you will notice this is going to shoot up as you load up stuff - like addon-scenery, UTX, addon aircraft... all those rise the VAS considerably. And LOD mostly.But the fact is, VAS in the beginning of the flight is not NEARLY the same as in the end. I often start with 3GB and end up landing with 3.8GB.This load you see in the pic is my default airport with default C172, fair clouds. My default flight.Now you can start observing when you get g3d.dll what the size of your VAS is. Use LOD_RADIUS to manipulate VAS if needed. I go as high as 15.5 on LOD to decently load VAS to be able to test quicker.

[alpha117 73]

OK, what the biggest this number can go?

[Guest]

I know you all probably think I am nuts, but I posted yesterday about an AutoSaver that somehow allowed me to fly for over an hour while I usually get an appcrash after 5 to 30 minutes. Remember me? ;) Today I started another flight (again with the Katana 4x above PNW with all graphic tab sliders full right apart from water one notch down) with that autosaver in the background. After two hours of flying without an appcrash I decided to post about my experience on another forum and while I was typing there FSX finally appcrashed. Just as yesterday I might have been flying still if I hadn't alt-entered out of FSX, who knows...Does anyone know if saving a flight somehow flushes memory...? As if some stuff is gone so FSX has more room...? I also noticed that when I landed at Darrington after 35 minutes, everything was still smooth. Usually Darrington is heavy on fps and specially after a flight: it's as if FSX becomes more and more sluggish over time. But not today: I never had such a smooth approach on Darrington and fps stayed at my max of 30 (using the external limiter).I have no explanation for this all but I can now fly longer then I want to without any appcrashes and with absolutely awesome graphics (4x multisampling, transparency multi on and trans supersampling 4x sparse grid), smooth performance and an fps that stays at 30. Even above Portland or Seattle it won't go under 25 or so (with Extremely dense autogen).This may not be a official and general solution for everyone but I am curious if others who have appcrashes get the same benefit from simply using an autosaver.

[Kosta 122]

OK, what the biggest this number can go?

4GB. You will notice textures slowly not being able to load, aircraft usually, I test this with NGX, engines are the first to go usually :)This is the limit of the 32bit app.EDIT: The thing is, the app shouldn't even think of crashing with g3d.dll. Only thing that should happen is OOM if you cross the threshold of 4GB...

[Guest jahman]

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.

[Guest]

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... ;) )