G3D.dll CTD related to Virtual memory?

[ryanbatc 12,857]

A lot of people who encounter g3d.dll ctd's are flying planes that are hard on fps, or over scenery that's hard on fps.Do we know if these errors are related to the virtual memory exceeding the 4GB limit?Also, is there a way to monitor this value because I've been getting hammered with g3d's, especially in PNW scenery.nm I found this cool little program:http://www.hashpling.org/asm/I doubt it's the adress space then... FSX is sucking more than 3.5 GB of virtual address space and it's not CTDing. (oops I posted the earlier pic... it was eating 3.5 GB at max)Ugh, thought I was on to something here...

[Sesquashtoo 2,846]

Try this setting under [GRAPHICS]STALE_BUFFER_THRESHOLD=2147483647That should clean up your g3d.dll issues.

[catchman 13]

I think that has something to do with it. I can name a couple of instances that I can routinely get the g3d.dll error to trigger:

1. Ultimate Traffic 2 loads an aircraft with a blank (bad or missing) texture - see here for my write-up. The user who posted last may be onto something as I also get a java error when UT2 begins to generate traffic. Although, this doesn't cause any errors and everything functions as it should.
2. Two afcads covering the same airport. Use Airport Scanner to check for any doubles. I use this program over AFX or ADE because it will pickup additional .bgl files that are not necessarily afcads by nature but affect them.
3. Memory overwhelmed - nothing to do but decrease the load on the computer. Turn down ai traffic, scenery, or weather. Sometimes this can be keyed up at dawn/dusk since FSX is loading both the day and night textures. FSX determines these texture colors by splicing them. Thus, your pc is processing many more texture calls during these period. Also remember that advanced aircraft tend to take a lot of juice away from your pc as well. I can get the g3d error on approach almost always when using the HD v/c texture set on the QW757 but not with the standard v/c textures. Don't take that as gospel, though, because it depends on your personal FSX settings and whatever else you may have running.

[Illegitimi non carborundum 4]

RyanAIUI it is the VAS (Virtual Address Space) that is most important and if exceeded then you get an FSX OOM (only not a system OOM). If you are considering Virtual Memory as the VAS then it's the same. If you are considering VM to be the 'paging file' or another system resource then you wouldn't get an FSX crash but a total system slow down and eventually a Windows crash.There are tools from MS to measure the VAS, PF, RAM,etc but they are not always intuitive! :( The first is event viewer in that if the OOM is due to a MS reportable event then it will be logged in the event viewer, similarly with the inbuilt reliability monitor. The next step up is PERFMON and XPERF (very advanced and complex) which are available from sysinternals, and you can set these to log paging file, VAS, Physical RAM parameters, usage etc and so on. (PROCMON can be useful if it is a process affecting OOMs)There are also a couple of other tools that can also help: VMMAP and RAMMAP again part of the MS sysinternals suite.http://technet.microsoft.com/en-us/sysinternals/ .I've long held the view that these OOM errors in FSX are possibly due to the way 3rd Party add-ons react with the "heaps" "handles" and "stacks" in Windows and how that may stop the Windows Garbage collector in effectively clearing the VAS. What people forget is that FSX needs 1GB CONTIGUOUS space in the VAS, ie it could be using only 1 or 2GB VAS but still crash as there is not enough contiguous space for it to operate. Meanwhile,I will continue with my research into heaps, stacks, handles, GC and the like but probably the new MS Flight will be here before I see a pattern! It's a mysteryRegardsPeterH

[mgh 89]

FSX needs 1GB CONTIGUOUS space in the VAS, ie it could be using only 1 or 2GB VAS but still crash as there is not enough contiguous space for it to operate.

I think it should bw 1Mb contiguousm not 1Gb. I know that's often been said here - Iv'e probably said it myself - but thinking about it I've never seen any other source for that than forum posts. Have you?

[Illegitimi non carborundum 4]

I think it should bw 1Mb contiguousm not 1Gb. I know that's often been said here - Iv'e probably said it myself - but thinking about it I've never seen any other source for that than forum posts. Have you?

Good point - I've always thought that it was 1GB but you could well be correct. Further, I have to say that I cannot find the reference to the 1GB - I seem to recall that it was on Phil Taylors Blog - later - this might be it: http://blogs.msdn.com/b/ptaylor/archive/2007/06/15/fsx-and-win32-process-address-space.aspxPhil states:"1)the app is running out of contiguous blocks in the 2G process address space (referring to a 32-bit OS)2)the app is running out of virtual address space period"I assumed it would be 1GB contiguous space possibly erroneously due to the /3GB switch, but I see that even he does not define the size of the contiguous block!! He actually says: "OOM can be caused by either really being out of virtual address space or fragmentation such that contiguous blocks of size x cannot be allocated, as I mentioned"FS developers certainly state 1MB but to me that seems quite small for a program such as FSX as I would have thought that it would occupy more than 1MB contiguous space in the VAS. If it was only 1MB why would you bother in a 32-bit OS to increase the VAS by up to an extra 1GB or so? I do seem to recall that it is 1MB in size on 32 bit windows, on 64 bit windows it can be 4MB. Ah Well, Back to the drawing board! :( PeterH

[Illegitimi non carborundum 4]

mghAfter reading this it may be that the contiguous space required may be any size and failures may occur without having a specified size:Address Space FragmentationAnother concern with memory allocation is that if you allocate memory in non-contiguous blocks, over time "holes" will develop. For example, if you allocate 10 KB and it is taken from the middle of a 20 MB chunk of memory, then you can no longer allocate that 20 MB a one chunk of memory. Doing this enough times will cause you to no longer be able to allocate 20 MB at once. This can cause allocation failures even when there is free memory. Note that this is true even with virtual memory because what matters is that you need a continuous block of addresses, not a continuous block of physical memory. [http://www.cprogramming.com/tutorial/virtual_memory_and_heaps.html]It looks like that the allocation of non-contiguous blocks is the most important aspect of vm allocation. But it does mean that you may well get an OOM error even if you have not exceeded the 4GB VAS limit (64-bit).This describes it better than I ever could:"Here's a simplistic "worst case" example: assuming you manage to allocate the first byte of every virtual memory page (let's say the page size is 4096 bytes) and the virtual memory address space size is 4GB, you will see only 1MB of physical RAM used but all of the virtual memory used... and you get Out of Memory on the next allocation. In other words, over 99.99% memory is "free" yet you get "Out of Memory". Crazy, right? But that's memory fragmentation for you..." (http://blogs.msdn.com/b/david.wang/archive/2006/02/14/more-on-virtual-memory-memory-fragmentation-and-leaks-and-wow64.aspx)Regards and thanks for your input.PeterH

[Tomaz Drnovsek 440]

Is anybody by any chance using Antilag FPS limiter? When I removed this thing out of my FSX folder the g3d.dll errors completely stopped even on demanding settings and situations.

[dazz 69]

mghAfter reading this it may be that the contiguous space required may be any size and failures may occur without having a specified size:Address Space FragmentationAnother concern with memory allocation is that if you allocate memory in non-contiguous blocks, over time "holes" will develop. For example, if you allocate 10 KB and it is taken from the middle of a 20 MB chunk of memory, then you can no longer allocate that 20 MB a one chunk of memory. Doing this enough times will cause you to no longer be able to allocate 20 MB at once. This can cause allocation failures even when there is free memory. Note that this is true even with virtual memory because what matters is that you need a continuous block of addresses, not a continuous block of physical memory. [http://www.cprogramm...and_heaps.html]It looks like that the allocation of non-contiguous blocks is the most important aspect of vm allocation. But it does mean that you may well get an OOM error even if you have not exceeded the 4GB VAS limit (64-bit).This describes it better than I ever could:"Here's a simplistic "worst case" example: assuming you manage to allocate the first byte of every virtual memory page (let's say the page size is 4096 bytes) and the virtual memory address space size is 4GB, you will see only 1MB of physical RAM used but all of the virtual memory used... and you get Out of Memory on the next allocation. In other words, over 99.99% memory is "free" yet you get "Out of Memory". Crazy, right? But that's memory fragmentation for you..." (http://blogs.msdn.co...-and-wow64.aspx)Regards and thanks for your input.PeterH

Peter, just wanted to point out that in 64b systems the VAS limit is not 4GB, that's in 32b + LAA. I know it probably was simply a typo, but just in case :smile:Very good read BTW. Is the VM allocation size constant? does it depend on the app? What I seem to conclude is that the bigger the allocation blocks, the more probably or faster it will run out of big enough free contiguous VM slices, hence a OOM will happen faster. Using smaller allocation sizes is likely less efficient however, and will make fragmentation worse overtime anyway.If 1MB is the minimum contiguous space needed for FSX, I take it that's the maximum VM block size it will try to allocate, or that it's a constant allocation size. I'm guessing it's not constant

[mgh 89]

I can't track down the source for "FSX allocates VM in 1 Mb blocks". When a process starts all its VM is free. The process can reserve VM without putting anything into it and then later commit data to it. Window has different ways to manage VM. 1 - using the Virtual Memory Functions. These work with pages - multiples of 4096 bytes. Memory can be committed as little as one page at a time. The maximum amount of memory that can be committed is based solely on the maximum range of contiguous free or reserved addresses (but not a combination of both). The VM Manager swaps these pages betwen physical memory and hard disk as required.http://msdn.microsof...y/ms810627.aspx2 - Using the Memory-Mapped File Functions. These also work with pages and enable all or part of a file on disk to mapped a specific range of addresses within VM. The VM Manager swaps these pages between physical memory and hard disk as required.http://msdn.microsof...y/ms810613.aspx3 - Using the Heap Memory functions. These reserve VM in 1 Mb blocks but enable memory to be commited as little as a byte at a time. If this is the source then it's a Windows limitation - not an FSX one. Heaps don't seem to be swapped.http://msdn.microsof...y/ms810603.aspxProcess Viewer (available here http://www.pcworld.c...escription.html) shows the usage of virtual memory. With FSX running, right click on fsx.exe in the list of processes then Memory in the drop down list to see details. The memory usage is summarised in the status-bar at the bottom.It gives interesting results. On my mine PC, fsx.exe appears 4 times and d3dx9_34.exe 18 times! With the default C172 loaded, the Cessna 172.dll is loaded 4 times as is the Cessna182s.dll, and the Bell206b.dll.

[ryanbatc 12,857]

Is anybody by any chance using Antilag FPS limiter? When I removed this thing out of my FSX folder the g3d.dll errors completely stopped even on demanding settings and situations.

I'm not sure what that is - I do use an external limiter. It was the original one posted on these forums, v.02 I think.I went for quite some time without errors after I downclocked from 4.5 to 4.0 GHz. But I still received them on occassion, and especially with FSDT scenery. Now I've been getting them in Orbx land but I admit I've been running LOD 6.5 with dense or very dense autogen.And I was talking about virtual address space, that program above displays VAS remaining in teal.

[mgh 89]

And I was talking about virtual address space, that program above displays VAS remaining in teal.

Which program?

[Tabs 2,790]

Try this setting under [GRAPHICS]STALE_BUFFER_THRESHOLD=2147483647That should clean up your g3d.dll issues.

That's actually a bogus tweak - ******* Altuve originally had it in his list of tweaks because that number is the max 32-bit integer and he thought it might do something, but we were then later told by one of the graphics programmers on FSX that the actual range is 5-1024 with a default of 60. He recommended leaving it at the default. This setting is the number of frames the sim will wait before clearing unused vertex buffer pools - it doesn't make sense for it to be super high because that's actually adding additional load to the buffer system.g3d.dll is the sim's main renderer - usually whenever I've seen this crashing it's a system stability issue like an unstable overclock.

[ryanbatc 12,857]

g3d.dll is the sim's main renderer - usually whenever I've seen this crashing it's a system stability issue like an unstable overclock.

That's what I thought too but I've had this error with my system at default settings. And I know there's plenty of people on the forums encountering it who do not OC as well. I've also heard it's scenery library related. In fact I've heard a lot of things but I would love to get to the bottom of it. Too bad nobody from the old ACES team could chime in here.Not to mention my system passes all the normal OC tests (P95/OCCT 12+ hrs - haven't tried Intel burn in yet) at 4GHz, with no errors detected by multiple passes of memtest. It is possible fsx is more demanding in general than some of those stable OC tests.I've also come to a general conclusion that we are pushing FSX far beyond its normal operating limits and introducing these errors (addons). I don't recall having these g3d errors at all when it first came out, or when I was using Vista. There's another factor - Win7 has been extremely problematic for me since I started with it - especially in the User Permissions realm.... UUuuhh. Some days I just want to go back to XP.

[Illegitimi non carborundum 4]

Peter, just wanted to point out that in 64b systems the VAS limit is not 4GB, that's in 32b + LAA. I know it probably was simply a typo, but just in case :smile:Very good read BTW. Is the VM allocation size constant? does it depend on the app? What I seem to conclude is that the bigger the allocation blocks, the more probably or faster it will run out of big enough free contiguous VM slices, hence a OOM will happen faster. Using smaller allocation sizes is likely less efficient however, and will make fragmentation worse overtime anyway.If 1MB is the minimum contiguous space needed for FSX, I take it that's the maximum VM block size it will try to allocate, or that it's a constant allocation size. I'm guessing it's not constant

Dazz \I was referring to the 4Gb VAS limit for 32-bit programs (LAA) running in a 64 - bit OS ie FSX.Your other questions are excellent - they are similar to what I asked Mark Russinovich over at sysinternals - only problem is - he didn't reply so I don't have the answers. I too believe that allocating large blocks (or heaps I'm not sure) can mean that the Windows Garbage Collection doesn't work as efficiently and an OOM follows. Its a complex issue, but I have never seen an OOM running a basic FSX SP2 install no matter the sliders positions or the weather/ world region.RegardsPeterH