Correct. Are you still running 32bit Windows?

 

Under 32bit Windows, each application has 2GB VAS (it's acutally 4GB, but only 2GB effectively usable).

Under 64bit Windows, each 32bit application has the full 4GB VAS (64bit apps have a lot more).

 

When the free VAS goes close to zero, you should get an OOM.

And you will be hearing the dings, dings from the fsuipc module warning you when you are close to running out of memory.

 

Best regards,

Jim

I do think the OOM circumstances have a lot more to do with fragmented VAS than complete saturation of VAS; I've set up exactly the same sequence of prep and flight and have had the FSUIPC chimes from the get-go one time, and then after a reboot (or even shutdown and restart, to be extreme), NO FSUIPC chimes in exactly the same 777 livery, same configuration, airport, etc. (I always use KSEA as my worst-case scenario for test, same gate).  Also run into this with another complex airliner, DC-9 Classic -- I'm sure the codebase for each is quite different.

 

Then, there are always the other factors; I'd forgotten to turn indexing off for instance (on my W8 system indexing on radically speeds up file search when I'm doing things other than FSX, so I prefer to leave it on), and simply initiating the Win8 "Do Maintenance" option cleared that up (among other things it refreshes file indexing for newly-added files and programs, so that that's not going on in the background while running FSX, for example).

 

Even if it's not using VAS, any other process that operates on a 64-bit OS that engages in heavy disk access can be in contention with what FSX is doing re: file cacheing, reading, swapping in/out of memory, and the c0000005 errors, regardless of module, I remain convinced are usually the consequence of FSX trying to read the "memory" in an on-disk cache, and not being able to get to it in time.

 

So even if Process Explorer or other Sysinternals utilities reflect a reasonable VAS address space useage (including contiguous blocks of sufficient size), there are plenty of conditions, even with FSUIPC installed to trap one of the most common ones, where c0000005 is going to happen.  And be virtually impossible to pin down.

 

Then, there are always the other factors; I'd forgotten to turn indexing off for instance (on my W8 system indexing on radically speeds up file search when I'm doing things other than FSX, so I prefer to leave it on), and simply initiating the Win8 "Do Maintenance" option cleared that up (among other things it refreshes file indexing for newly-added files and programs, so that that's not going on in the background while running FSX, for example).

 

 

Very interesting point. I am not sure right now if I disabled the indexing fro my FSX drive. I will check that and report back. Thanks!

 

 

VMMap can display the structure of the free address space. However, since the OP stated that he is getting OOMs at around 2.7G VAS usage, I doubt that the memory is that much fragmented at this point.

 

Thanks a lot for pointing me to VMMap. After using this tool I can confirm that a fair bit of fragmentation occurs, but I am now able to get to about 3.7-8 before I'm out of memory (according to VMMap). Still short of the 4 GB limit but I understand adverse effects can occur when FSX gets close to the limit so that could be explained by fragmentation.

Correct. Are you still running 32bit Windows?

 

Under 32bit Windows, each application has 2GB VAS (it's acutally 4GB, but only 2GB effectively usable).

Under 64bit Windows, each 32bit application has the full 4GB VAS (64bit apps have a lot more).

 

When the free VAS goes close to zero, you should get an OOM.

No, I'm on Win 7 64bit, but I was not aware that in 32-bit applications in the 64bit environment the per/app limit goes to 4Gb.   Can you elaborate a little more on:

 

'Your second indicator is the largest contigous block size of free VAS which shows in the bottom part of the screen. That should show at least 1 meg.'

 

Are you saying that there should be at least one entry showing a size of at least 1,000 Kb?

 

I must have things set up well on my new build as I flew from Flightbeam's KPHX to KDFW in the NGX with FTX night lighting and ended up w/ 1.5Gb free and pretty large contiguous blocks for about a 2h our flight.  As I say I've never had an OOM and apparently others do well with avoiding these also.  Tempting to pick up the 777 and see how it goes, though performance when you jump in the NGX at KPHX isn't as good as I'd like it to be, but it's decent for sure.  

On Process Explorer, can someone give a broad explanation on what we are exactly looking for with regard to VAS usage?  Are we looking for Private Bytes?  Virtual Size?  What is the difference? 

 

I searched around Google but couldn't come up with any broad explanations.  My Virtual Size is always slightly higher than my Private Bytes.

'Your second indicator is the largest contigous block size of free VAS which shows in the bottom part of the screen. That should show at least 1 meg.'

 

Are you saying that there should be at least one entry showing a size of at least 1,000 Kb?

 

The 1M size is just from my personal experience. Your mileage may vary.

 

Theoretically, if FSX needs to load some resource, say a 5MB texture, there must be at least one contiguous block of address space left that can accomodate these 5MB. If not FSX will OOM.

On Process Explorer, can someone give a broad explanation on what we are exactly looking for with regard to VAS usage?  Are we looking for Private Bytes?  Virtual Size?  What is the difference? 

 

Virtual Size is what you should be looking at. Private Bytes doesn't include address space used for DLLs for example.

 

The full explanantion can be found here:

http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/WCL405