This is very very strange. I have not had a crash in G3D.DLL for many many weeks. Then I started reading this thread a week or so ago, and today, on my first serious flight since, I got a G3D crash on long final approach (about 15m out) to Eiresim's EIDW runway 28.So, I've decided to try and work out a "fix". One possibility which I'm going to experiment with is hooking the actual code where it crashes, testing whether it will crash (i.e. accessing an invaid address), if if so exiting from that specific routine n the hope that it will carry on regardless.With the crash I had it looks possible because the external "result" of the routine is simply a "TRUE" or "FALSE" return. I can see which works best.But, to see if it is worthwhile going down this route (it isn't as trivial amount of work) I need to check whether most if not all of the crashes folks are getting are in the same place in G3D.DLL. You can get this information form the Windows error log. I need the version number of G3D.DLL (eg 61472 for the SP2 version, 61637 for the Acceleration version), and the offset.The place I get in version 61637 is offset 000BA79F. I searched a couple of threads here and the only other sufferer I found reporting this data is using version 61472 and his offset was 000B50DF. That is actually the very same point in the code, so it is encouraging. If they are all at that point it is excellent news because it MIGHT mean I can implement avoiding action.No promises mind. I'll do some experiments here and let you know.RegardsPete

Man Pete, that sounds great!Any way I can help, you give me a chime.I went through the log, and checked some 50 or so last faults on fsx.exe, and this is a result:Faulting application name: fsx.exe, version: 10.0.61472.0, time stamp: 0x475e17d3Fault offset: 0x000b50dfThis is the main offender. I see it basically every time.Faulting application name: fsx.exe, version: 10.0.61472.0, time stamp: 0x475e17d3Fault offset: 0x000b5129This one is also appearing often. I can't say what I did back then. I am backlogging through the log...I'll try loading my situations to see which one crashes with which offset.

This is very very strange. I have not had a crash in G3D.DLL for many many weeks. Then I started reading this thread a week or so ago, and today, on my first serious flight since, I got a G3D crash on long final approach (about 15m out) to Eiresim's EIDW runway 28.So, I've decided to try and work out a "fix". One possibility which I'm going to experiment with is hooking the actual code where it crashes, testing whether it will crash (i.e. accessing an invaid address), if if so exiting from that specific routine n the hope that it will carry on regardless.With the crash I had it looks possible because the external "result" of the routine is simply a "TRUE" or "FALSE" return. I can see which works best.But, to see if it is worthwhile going down this route (it isn't as trivial amount of work) I need to check whether most if not all of the crashes folks are getting are in the same place in G3D.DLL. You can get this information form the Windows error log. I need the version number of G3D.DLL (eg 61472 for the SP2 version, 61637 for the Acceleration version), and the offset.The place I get in version 61637 is offset 000BA79F. I searched a couple of threads here and the only other sufferer I found reporting this data is using version 61472 and his offset was 000B50DF. That is actually the very same point in the code, so it is encouraging. If they are all at that point it is excellent news because it MIGHT mean I can implement avoiding action.No promises mind. I'll do some experiments here and let you know.RegardsPete

Great Pete !For me :- Version 61637- Offset 0x000ba79fAttached the saved flight for the PMDG737NGX above ETTN and near Cologne.I am using VFR Germany West 2010 ( photoscenery as well ) and Colgone-Bonn addon airport.For anyone who wants to try here a downloadlink for the saved flight : http://members.casema.nl/gsalden/737NGX G3Ddll Flight Simulator X Files.rarWithin 5 minutes the CTD , caused by the G3D.dll error , will appear.

I went through the log, and checked some 50 or so last faults on fsx.exe, and this is a result:

I can't handle all FSX crashes. At least not all at once. Let me concentrate on G3D at present. Just check the Module name in the log, FSX is the process name -- we know that. ;-)

Faulting application name: fsx.exe, version: 10.0.61472.0, time stamp: 0x475e17d3Fault offset: 0x000b50dfThis is the main offender. I see it basically every time.

Good, that's the same G3D one I got, but in SP2 instead of Acceleration.

Faulting application name: fsx.exe, version: 10.0.61472.0, time stamp: 0x475e17d3Fault offset: 0x000b5129This one is also appearing often.

I assume that's also G3D -- it's the same value being tested, just a difference branch.

I'll try loading my situations to see which one crashes with which offset.

No need. If they are both G3D I should be able to deal with both with one hook.RegardsPete

I can't handle all FSX crashes. At least not all at once. Let me concentrate on G3D at present. Just check the Module name in the log, FSX is the process name -- we know that. ;-)

Yeah, I know that - I think you misunderstood me - those errors are all g3d.dll errors. All the same, as I posted above, those two offsets. Just I can't sort them as I have 3-4 situations saved in which I can provoke g3d.dll if I want to.

Yeah, I know that - I think you misunderstood me - those errors are all g3d.dll errors.

Yes, all two different offsets, but I identified that by checking the code in G3D.DLL at the second offset to see it was essentially the same crash, on a bad value (probably 0) in ESI. I should be able to deal with both, and therefore ALL those you mentioned, with one hook.

All the same, as I posted above, those two offsets. Just I can't sort them as I have 3-4 situations saved in which I can provoke g3d.dll if I want to.

No need to do any sorting, as I said. I only want the Module (G3D or whatever), the Version number, and the offset -- oh, and the error if not C0000005 (access violation).So far they are all the same as my one crash (I couldn't repeat it BTW).Thanks,Pete

Yes, all two different offsets, but I identified that by checking the code in G3D.DLL at the second offset to see it was essentially the same crash, on a bad value (probably 0) in ESI. I should be able to deal with both, and therefore ALL those you mentioned, with one hook.No need to do any sorting, as I said. I only want the Module (G3D or whatever), the Version number, and the offset -- oh, and the error if not C0000005 (access violation).So far they are all the same as my one crash (I couldn't repeat it BTW).Thanks,Pete

The g3d.dlls are apparently connected to the high VAS usage, something we've concluded in the past 16 pages.They happen with some sceneries and ORBX, as reported.All mine are access violation, C0000005.What are you doing here, just interested? If I can understand it correctly, the routine asks for true or false, if it gets false, it crashes?

Hi Pete, in the past I had CTD in many different scenery , with this error:fault offset 0x0006b4f0g3d.dll, version: 10.0.61472.0than, after inserting the line "MissingLibraryAlert=1" in thr FSX.cfg the error disappeared (but I had many alerts), and started a new error, this:fault offset 0x00055a3eterrain.dll, versione: 10.0.61472.0At the end, deleting all the UiAutomationCore.dll files (renamed), I had no more errors so far today (a couple of weeks).Don't know if this can be of any help, but I tried

Don't know if this can be of any help, but I tried

Neither of those locations have anything in common with any of the others so far reported with details. I'm pretty sure that the one I got and those Word Not Allowed reported aren't related to VAS at all. Mine certainly occurred at a point where there would have been much less demand for memory than when I started, and my heaviest area, EGLL, has never so far given me a G3D crash. NTDLL ones, yes -- to do with video drivers, but not G3D.I'll make a note of your original offset in any case. See if there's any corroboration for that one.Thanks,Pete

The g3d.dlls are apparently connected to the high VAS usage, something we've concluded in the past 16 pages.

Yes, I've actually read them all. but it doesn't agree with my observations, and my crash was in exactly the same place as all of your own. I think it is something different, a bug in table addressing beyond allocation..

They happen with some sceneries and ORBX, as reported.

I've been using EireSim's EIDW ever since it's been available, and my standard test flight has always been EGCC to EIDW, and this, today, is the very first time it has crashed at all.

What are you doing here, just interested?

I'm trying to establish if all, or at least most, of the G3D crashes are at the same place, because if so then I may be able to hook the code and force that routine to exit before it accesses the bad address. In order to do this I have to actually test the address (in a non-crashing context) to see it is valid. That involves calling a Windows function, so my main concern if I do this is whether it will affect performance.So my first test will be to just hook it and count how many paths through there occur per second. If that isn't inordinately high, I'll try putting the suspect value through the validity check and measure performance again to ensure it isn't noticeably affected.Finally, assuming all that is okay i have to determine what the effects are of exiting directly with a FALSE or TRUE result, and choose the path which has the least noticeable affect on the visuals. For instance, it might omit some bit of scenery or put the right bit in the wrong place. I've no idea. As long as it is transient then it probably doesn't matter -- better than a crash, certainly. However, if the same thing then happens over and over forever after, it indicates broader corruption, and what I'll have done will be a waste of time.That's why I'm making no promises. I'm just going to experiment.

If I can understand it correctly, the routine asks for true or false, if it gets false, it crashes?

No, the TRUE or FALSE results are being derived from operations which depend on the bad value, the one causing the crash, so obviously i cannot determine whether to return TRUE or FALSE. Hence the experiments.RegardsPete

I have version 61637, and get offset 000BA79F in my log.

Quite interesting Pete. I know as much as jack$hit about programming, but this is real cool.

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...errorexception 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

errorexception code c0000005, offset 000ba7e9.

I assume this is with Acceleration, else that offset is completely different from any of the others.If it is Acceleration, it is the same bad value as in Kostas and my cases.Pete

Sorry should have mention it, Acceleration yes !Alain from Montreal