Whoa whoa, wait a bit! There are people getting crashes at known positions even with default LOD 4.5 and 1024. How? You load lots of addons, have addon airports, and press to get VAS usage over 3GB. It's possible with NGX and some other addons. Especially if you keep flying over other addon airports.Still you won't OOM, but the error scenery is going crash because of high VAS usage. This is the error, not that we are trying high LODs. High LODs are only in place to cause a high usage on load, to be able to test the situation in place. I don't have to have LOD higher than 4.5GB to get usage higher than 3GB on some flights with NGX.And that said, I'm already waiting for the answer (from any developer) saying: in default FSX is working. Of course it does! Still badly programmed.

YUP! LOD 4.5 textures 1024, flying into ORBX payware Tamworth (YSTW) I get the missing textures alert and then a CTD with the GUID.

GHD you are right, it's west, typo on my part; "FSX stopped responding" happens to me in the same area once in a while, usually resume itself after 10 minutes.Alain from Montreal

I'll have to do the flights again, and continue down to PDX. I flew 4 test flights (ORS-PDX at 6k) and was unable to generate a CTD.- Test 1: Default Baron, UTX and ORBX turned off, no wx.- Test 2: Default Baron, UTX on, ORBX off, no wx.- Test 3: Default Baron, UTX on, ORBX on, no wx.- Test 4: NGX, UTX on, ORBX on, no wx.Other than slightly better climb performance experienced in the last test, each flight was the same track at 6k. Obviously not scientific in any way, results were:- Test 1: System started to see a climb in VAS usage about 5NM N of PWT. VAS peaked at around 1.2 GB, then settled back around .9 GB once abeam of SEA.- Test 2: Same results as Test 1, however VAS peaked at around 1.5 GB, then settled around 1.3 GB.- Test 3: Same results as Test 1, however at 4.3 NM N of PWT, I received about a dozen missing scenery errors. VAS peaked at 1.98 GB, settled around 1.89 GB.- Test 4: Same results as Test 3, however VAS spiked at 2.6 GB, settled around 1.95 GB.Like I said, not scientific in any way, just rather interesting. I don't think the ORBX issue I experienced is the root cause either (I do NOT have 2S1 installed).On a side note, did a flight BOS-EWR later, and for some mid-flight entertainment, opened up Procmon to see what was going on. I didn't think to save the log, but as it was scrolling buy, there where numerous file read operations on ALL my scenery. I even noticed multiple accesses to my Aerosoft Anchorage scenery which other than being in the same hemisphere, is nowhere near where I was.Hmmmm, perplexing.

Dan, are you sure you are reading VAS? 2GB usage for ORBX is really low.

Dan, are you sure you are reading VAS? 2GB usage for ORBX is really low.

Yup, columns I read from were the ones listed in this post.When I have a few hours free, I'll do a little bit more comprehensive test. Possibly swap out my OS and FSX drives and create a Win7 install with nothing but FSX and run the tests, then start slowly adding scenery.Would be useful if there was a tool that could monitor FSX (via SimConnect) and when it stops responding (i.e. crash) it immediately saves procmon logs and VMMap state.

HA! Yet another scenery: Aerosoft Arlanda X. Also has round 900 textures in the folder, VAS usage 3.5GB, boom. Just a heads up.Some other sceneries that have been tested, have all low texture count, like 100-300, and they don't crash even with 3.9GB VAS.

It could be just a coincidence, but here is my gd3.dll CTD story:I had too many flights in the past month without a single CTD. I had just recovered from a serious CTD situation (d3d9.dll due to ENB) which was solved by going back to 275.33 driver and deleting the 2 system uiautomationcore.dll files. I was extremely happy with my system's stability.Today I decided to 'play' once again with the fsx.cfg file. I run Bojote's online tool which, among others, added the following lines:TextureMaxLoad=10SWAP_WAIT_TIMEOUT=2MAX_ASYNC_BATCHING_JOBS=3 I was happily testing the config doing a flight from PAKW to PAKT (with FS Economy and FSPAX active) when at about 15 miles NW of PAKT I had my first gd3.dll crash.."Oh, not again", I thought. I immediately opened the fsx.cfg file and deleted the above 3 lines. Started again exactly the same flight which ended successfully without a crash this time.As most of you guys have probably run Bojote's online tool and have the above lines in your config, why don't you give a try deleting or commenting them out from your config file, just in case...On the other hand, as I said, it could just be a coincidence.

I have found the 'holy grail', the 'magic bullet' for fixing the g3d.dll/ntdl.dll/aiplayer.dll errors! It's working perfectly for me after exhaustive testing and I was one who received the CTD 100% of the time in certain locations. I have now successfully ran the same test flight several times at 4.5 LOD, with 4096 HD textures, with the PMDG 737NGX, with FTX PNW enabled, Shade, and with real world weather (it was pouring rain in Portland and Seattle during most of the testing) w/o a crash. Oh! And I also use MyTrafficX. The flight was from KPDX - KSEA via the OLM7 STAR and landing on Runway 34C. Prior to finding the fix, I was able to complete the flights most of the time with textures at 1024 and LOD at 4.5 but fps while on the glideslope into Seattle always fell into the single digits. Now, with this fix, I am able to get 15-30 fps (mostly in the 20's) while on the glideslope with HD textures! My fix involves a ONE tweak in the fsx.cfg and modification of memory in the BIOS which some of you may or may not have to do. I am also a hardcore believer the Microsoft technicians of Windows 7, 64 bit know what they are doing in regards to memory management so my virtual memory performance settings is set at "System Managed Size".I had a convoluted fsx.cfg with several tweaks that did not cause a CTD if I kept conservative settings such as 1024 textures and a 3.5 LOD. Ugly settings but they worked on my CTD flightplan. I figured one of the tweaks I had added must be the fix for g3d.dll errors so I started with a new fsx.cfg and added only one tweak to start with - the HIGHMEMFIX=1 (that's not the fix). I set LOD at 4.5 and 1024 textures. The sim crashed at WPT ARVAD, near Seattle. I read over at Phil Taylor's Blog (former lead developer of FSX on the ACES Team) about a scenery tweak that eliminates very small objects, such as airconditioners on roofs and aircraft doors, that can reduce rendering time and "cull out small model parts" if "their radius would occupy less than the specified number of screen pixels." This tweak was in my NO CTD fsx.cfg under [scenery]: SmallPartRejectRadius=1 (the default or 1 pixel) but Phil says it can go to 2 or 4 pixels. I used the default '1' and may try the other settings in the future. Adding this tweak stopped the g3d.dll errors but the sim was still crashing at WPT ARVAD. I checked the Event Viewer and the faulting module this time was the NTDL.dll and/or the AI_Player.dll. I already knew that the ai_player.dll was caused by the FTX PNW KSEA scenery but they had supposedly fixed that in SP004 (the latest SP). In any case, the ai_player.dll never crashed FSX; the Event Viewer just stated a crash occurred and it occurred when I closed FSX via CTRL-C. The NTDL.dll was really the only offending faulting module. In all cases of CTD's, the Exception Error 0xc0000005 was involved in the crash. This indicates there was a Memory Exception error which can be caused by almost anything but, in this case, we are talking about the NTDL, G3d, and AI_Player dlls. NTDL.dll: Ntdll.dll exports the Windows Native Application Programming Interfaces (API). The Native API is the interface used by user-mode components of the operating system that must run without support from Win32 or other API subsystems. Most of this API is implemented in ntdll.dll and at the upper edge of ntoskrnl.exe (and its variants) (http://en.wikipedia.org/wiki/Microsoft_Windows_library_files). Pretty complex to someone who doesn't know much about programming interfaces, etc., but I know things about the 'ntoskrnl.exe'. When I first put my system together I got BSOD's with the ntoskrnl.exe program always as the offender. Via Google, I learned any error with the ntoskrnl.exe program indicates there's something wrong with the installed memory. It could be timing, frequencies, wrong speed setting, memory not seated properly, overclocked, or the BIOS not identifying it correctly and providing the wrong settings. There could be other problems but it all has to do with your memory settings. I have my BIOS set up with XMP profile and that indicated the profile would manage my memory settings. I went back into my BIOS and saw that the Memory Frequency for my Muskin memory was set at DDR3-1333. CPU-Z indicated the speed for XMP should be 1600 so I change the Memory Frequency from DDR3-1333 to DDR3-1600. So much for XMP settings managing my memory settings!!! I then flew my known CTD route with minimal settings (LOD 4.5 and 1024 textures). No crash. I moved the textures to 2048, tried again and still no crash. Finally I moved my textures to 4096 HD. Still no crash and everything seemed extremely smooth during the flight. I have not tried raising the LOD higher than the FSX max but, as I stated above, the fps went up on the glideslope into KSEA and the sim seemed to be operating more smoothly.I don't want to take up space here to display my fsx.cfg but I will post the relevant parts below. I used the default settings Microsoft gave me when I first loaded a new fsx.cfg. What's important are the revelent graphics, display, scenery, AI traffic, and terrain settings:[GRAPHICS]TEXTURE_MAX_LOAD=2048NUM_LIGHTS=8AIRCRAFT_SHADOWS=1AIRCRAFT_REFLECTIONS=1COCKPIT_HIGH_LOD=1LANDING_LIGHTS=1AC_SELF_SHADOW=0EFFECTS_QUALITY=2GROUND_SHADOWS=0TEXTURE_QUALITY=3IMAGE_QUALITY=0See_Self=1Text_Scroll=1HIGHMEMFIX=1[Display]BLOOM_EFFECTS=0SKINNED_ANIMATIONS=1TEXTURE_BANDWIDTH_MULT=40UPPER_FRAMERATE_LIMIT=0 (works with fps limited to 30 too)WideViewAspect=True//TextureMaxLoad=6[sCENERY]LENSFLARE=1DAWN_DUSK_SMOOTHING=1IMAGE_COMPLEXITY=5SmallPartRejectRadius=1 (the G3D.dll fix!!!!) [TrafficManager]AirlineDensity=20GADensity=10FreewayDensity=10ShipsAndFerriesDensity=0LeisureBoatsDensity=0IFROnly=0AIRPORT_SCENERY_DENSITY=1 [TERRAIN]LOD_RADIUS=4.500000MESH_COMPLEXITY=75MESH_RESOLUTION=20TEXTURE_RESOLUTION=25AUTOGEN_DENSITY=2DETAIL_TEXTURE=1WATER_EFFECTS=6So I apologize for the long thread but felt I had to explain exactly my methodology during my testing. I sincerely hope this helps others fix this problem.Best regards,Jim

I have found the 'holy grail', the 'magic bullet' for fixing the g3d.dll/ntdl.dll/aiplayer.dll errors!

Interesting read, however you should have said "I have found my personal 'holy grail', my personal 'magic bullet' for fixing the g3d.dll/ntdl.dll/aiplayer.dll errors!" This won't be the holy grail for everyonem because a lot of people here (like me) have their memory already set accorindg to specs. Or have tried various settings. None of which fixed the errors... Nevertheless, it's of course great and awesome that you found a solution that works for you. Maybe it will work for others too, but this is certainly not THE holy grail or THE magic bullet.

Testing...And nothing. With Aerosoft sceneries it doesn't matter. When I get time or feel like it, I'll do a PNW test on the known places.Also, my memory is by the spec XMP 2000mhz. SB can't make it 2000, either 1866 or 2133. So it's running at 1866 now. Memtest and all is perfectly stable though.EDIT:Mmm, I take half back. EBBR still a problem, EDDF working with way higher VAS usage - 3.7 VAS approaching airport used to crash 100%. Now it doesn't.

Btw. if interests anyone: P3D is suffering from the same problem.

Testing...And nothing. With Aerosoft sceneries it doesn't matter. When I get time or feel like it, I'll do a PNW test on the known places.Also, my memory is by the spec XMP 2000mhz. SB can't make it 2000, either 1866 or 2133. So it's running at 1866 now. Memtest and all is perfectly stable though.EDIT:Mmm, I take half back. EBBR still a problem, EDDF working with way higher VAS usage - 3.7 VAS approaching airport used to crash 100%. Now it doesn't.

I suspect you still have your LOD above 4.5? In any case, you seem to have a good handle on your memory management and perhaps the one SmallPartRejectRadius is all you need to have. You might want to experiment with 2 or 4 pixels. As I recall somewhere in this massive thread, someone mentioned just parts on AI aircraft were known to cause crashes at KSEA. This 'tweak' probably eliminates some of those "bad" aircraft doors, tires, etc., that fsx is trying to render. Glad to hear EDDF working. Progress....Best regards,Jim

Interesting read, however you should have said "I have found my personal 'holy grail', my personal 'magic bullet' for fixing the g3d.dll/ntdl.dll/aiplayer.dll errors!" This won't be the holy grail for everyonem because a lot of people here (like me) have their memory already set accorindg to specs. Or have tried various settings. None of which fixed the errors... Nevertheless, it's of course great and awesome that you found a solution that works for you. Maybe it will work for others too, but this is certainly not THE holy grail or THE magic bullet.

Apologize Jeroen. It was more of an attention getter. This thread is getting long. I realize my fixes will not work on every system and that's why I made the comment at the end about hoping this fixes the problem for others. I doubt many people will have to worry about memory management like I did as I admit being a novice at programming the BIOS. Some may just have to make sure the one tweak in the Scenery section is there and that will fix their problem with the G3d error. As I stated, after I got rid of the g3d error, a new one popped up with ntdl and ai-player. I fixed that by adjusting my memory settings. I have flown several flights since posting my findings above and so far no CTD.Best regards,Jim

Jim and Word Not Allowed,I was testing AS Anchorage X and got aan OOM, I did this on purpose, as I have been testing all my Aerosoft airports, and as Word Not Allowed has stated many times, they seem to produce sceneries that cause memory exaustion.in my test, I used the MD11 with a McPhat HD texture, I took off from KSFO (flightbeam) and used 4x sim speed till TOD at PANC. At the FAF, sure enough, Kaboom, an OOM. I was still able to land. How is that possiable I hear you ask ?What I did was, I did not press OK on the OOM error dialouge box, instaead I mouse clicked the box a couple of times to make sure it was in focus, hit Cntrl+alt+delete and in the task manager, I selected the OOM error and closed it, the flight came back to life, I paused FSX and selected scenery libary, and pressed ok, FSX refreshed, un paused and landed and parked at the gate. Only mistake I made I did not have Process explorer running at the time so did not check the VAS after refreshing FSX. But will do this test again and check Vas usage before and after.Was it a fluke that I was able to continue my flight, after an OOM ? further testing will tell. BTW, I fly in Full Screen.CheersJulian

I was testing AS Anchorage X and got aan OOM

This thread is about the GD3.dll CTF, not OOM...Cheers,- jahman.