Jump to content
Sign in to follow this  
James Bennett

Why does FSX run out of memory?

Recommended Posts

I have done a search but couldn't quite understand fully. Why does FSX run out of memory after long flights? What is it loading into the memory that causes it to overload?

 

Are things in the memory not removed from the memory once they're used and no longer needed? That would surely be far more efficient.

 

I admit I don't have a huge understanding of these things, it just seems like such a widespread issue from something that surely offers no benefit.

Share this post


Link to post
Share on other sites

FSX is a 32bit program so you can only load around 3gb of textures at once. With tons of addons like the PMDG 777X, high resolution clouds, ai traffic, addon scenery you can see why you might hit that limit fast.

 

I'd suggest scanning for dulicate afcads as that can also cause OOM errors. AFX from Flight1 is great. Corrupted textures can also be a problem. DXTfixer in the avsim library is a huge help with that.

 

Lastly dial back your sliders for autogen to normal. You shouldn't see OOM errors anymore, although you might hear that DING from fsuipc once you land and maybe change views a few times.

 

Also make sure you have the latest versions of all your scenery. Aerosoft has a lot of little patch updates for sceneries like LFPG and EDDF. EBBR has an important one that fixes a dll crash too. Get the latest fsuipc. Move your fsx.cfg file to your desktop and let it rebuild, then add tweaks like bufferpools and highmemfix (you don't need much more than that)

Share this post


Link to post
Share on other sites

FSX is a 32bit program so you can only load around 3gb of textures at once. With tons of addons like the PMDG 777X, high resolution clouds, ai traffic, addon scenery you can see why you might hit that limit fast.

 

I'd suggest scanning for dulicate afcads as that can also cause OOM errors. AFX from Flight1 is great. Corrupted textures can also be a problem. DXTfixer in the avsim library is a huge help with that.

 

Lastly dial back your sliders for autogen to normal. You shouldn't see OOM errors anymore, although you might hear that DING from fsuipc once you land and maybe change views a few times.

 

Also make sure you have the latest versions of all your scenery. Aerosoft has a lot of little patch updates for sceneries like LFPG and EDDF. EBBR has an important one that fixes a dll crash too. Get the latest fsuipc. Move your fsx.cfg file to your desktop and let it rebuild, then add tweaks like bufferpools and highmemfix (you don't need much more than that)

 

I don't own FSX (until next week anyway) but thanks. My point is, if you can fly for 3 hours in a long haul flight before an OOM occurs, surely the program could have simply removed the texture files from the page file since it no longer needs half of them? Is it simply an inneficient/bugged programming error?

Share this post


Link to post
Share on other sites

If you are talking about an OOM where only FSX crashes then the post above is not strictly correct.

The problem with FSX OOM's are due the following:

Why does FSX run out of memory or more accurately the Virtual Address Space (VAS) is a difficult concept to understand. It has NOTHING to do how much Physical RAM you have onboard.

 

The Virtual (Process) Address Space (VAS) is part of the Windows OS - in the first versions of windows if a piece of software crashed it crashed the whole of windows with the dreaded BSOD. So to protect itself Windows it now loads all software into the VAS ( sort of virtual cocoon) so if the program crashes (OOM) it does not usually crash Windows as well.

 

Using say Win XP 32-bit or any 32-bit OS - loading an app like FSX (with the Large Adress Aware Flag set) it will have a MAXIMUM of 4 GB of VAS to load into. This was an enormous figure 20 years ago when the usual PHYSICAL RAM on-board was <1GB. However in a 32-bit OS 2GB (HALF) of this VAS is allocated to the system leaving only 2 GB available for FSX MINUS the VRAM on the videocard, so if you a video card with 1GB of VRAM it can nearly exhaust all of the VAS before you have even loaded FSX - let alone run for any length of time. The workaround was to use the /3GB switch (via the boot.ini) which can increase the VAS up to 3GB minus the VRAM. (Better to switch to a 64-bit OS)

 

In a 64-bit OS, FSX gets a whole 4GB of VAS to itself and this is not impacted significantly by the VRAM. In a 64-bit OS like Win 7 - the OS can load into 8 TERAbytes of VAS and so has little impact on FSX. (when I use Photoshop CS5 64 -bit it also loads into 8 TERAbytes of VAS - if this was anything to do with physical RAM how many sticks of 4GB RAM sticks would you need for 8 TERABytes of RAM.)

 

You think you are safe in a 64-bit OS where FSX gets a whole 4GB of VAS - but maybe not so safe after all. As you run FSX the VAS it tends to defragment and the contiguous space starts to lessen and if FSX cannot load into the VAS by NOT having enough contiguous space to load into (and this can be as little as 1MB that FSX needs) a OOM will follow.

 

Note: Not all OOMs when running FSX are due to VAS issues. During flight certain software add-ons or FSX itself can inadvertently instruct FSX via the OS cpu, etc to make an "illegal memory call", This could be that the code is still in the VAS and the OS has not passed it to the cpu and into the working set in the RAM – an OOM will follow as night follows day.

 

There is a registry hack that can help the VAS from defragmenting (in a 32-bit OS only so far as I know) and the reference is here http://support.microsoft.com/kb/315407 its called by its short name "HeapDecommitFreeBlockThreshold" registry key. It was used for Windows server editions but I used to use it in Win XP 32-bit before I moved to a 64-bit OS.

 

I'm sorry this is technical but if you can understand the concept of the VAS you can see why you get OOM errors that are nothing to with the amount of Physical RAM + Paging file installed The VAS is part of the Operating System and the RAM is part of the hardware two totally different things.

 

I haven't deliberately explained how the OS and the VAS interact with the cpu and the Physical RAM (the working set) but that relationship could also be a trigger for some OOM's.

 

Read this to see what Phil Taylor, FSX developer, said about VAS: http://blogs.msdn.com/b/ptaylor/archive/2007/06/15/fsx-and-win32-process-address-space.aspx

 

Regards

pH

Share this post


Link to post
Share on other sites

 

 


In a 64-bit OS, FSX gets a whole 4GB of VAS to itself and this is not impacted significantly by the VRAM. In a 64-bit OS like Win 7 - the OS can load into 8 TERAbytes of VAS and so has little impact on FSX.

 

I don't believe this is entirely accurate. True System functions and video memory are allocated in the 64 bit  address space, but DX9 specifications call for a second copy of video memory to be stored within the applications VAS (Shadow copy). I don't believe that part goes away on a 64bit OS. This I believe is why we're still seeing OOM's in FSX with 64bit OS, especially on systems with large memory video cards. What 64 bit does give you is freeing up the extra gig of address space for the APP. DX10 and DX11 specifications doesn't require the APP to shadow copy ram, which is why running FSX in DX10 doesn't have the same OOM issue. Although there is a caveat that may or may not cause a OOM on a DX10 App. As stated, VM is not shadowed copied normally and can be released in a DX10 App, unless the allocated space is declared lockable. Then it will not. Whether or not FSX declares it's space this way I don't know. Remember DX10 wasn't fully developed, so it may or may not have been done this way. 


Thanks

Tom

My Youtube Videos!

http://www.youtube.com/user/tf51d

Share this post


Link to post
Share on other sites

Tom

 

I was talking specifically about VRAM which does have a significant impact on the VAS in a 32-bit OS but very little in a 64-bit OS (see below).

Today we have 4GB video cards if they affected the VAS (4GB max for FSX) in a 64-bit OS - FSX would never start.

If you look in VMMAP whilst FSX is running you will see that there is no significant effect caused by the video card VRAM, shadow copy or otherwise, on the FSX VAS. However every program that interacts with FSX - weather, complex physics programs, aircraft, plus other add-ons that has its own exe file and VAS do have quite an impact on the FSX VAS. The main issue is fragmentation and loss of contiguous space and that has been documented on many forums and by the FSX team

 

Regards

 

This was about Vista but it is relevant in win 7 32-bit http://support.microsoft.com/kb/940105

"A modern graphics processing unit (GPU) can have 512 MB or more of video memory. Applications that try to take advantage of such large amounts of video memory can use a large proportion of their virtual address space for an in-memory copy of their video resources. On 32-bit systems, such applications may consume all the available virtual address space."

 

However AIUT Win 7 no longer keeps an in-memory copy of the video resources so the impact should be less.

Share this post


Link to post
Share on other sites

However AIUT Win 7 no longer keeps an in-memory copy of the video resources so the impact should be less.

 

This is where we disagree, I don't believe the issue is a 32 bit vs 64 bit issue, but a requirement of the DirectX 9 specification. If you notice on that support link there is also a 64 bit  fix to the  excess allocation of VRAM in the APPs VAS  issue as well as 32bit. If it was as you state, no patch would have been necessary for 64bit OS. Only using DX10 and later doesn't require the app to store a copy in it's VAS. (Except in the situation I described above).

 

"If an application creates its own in-memory copy of its video resources, or the application uses DirectX 9 or an earlier version, the virtual address space contains the WDDM video memory manager's virtualized range and the application's copy. Applications that use graphics APIs that are earlier than DirectX 10 and that target GPUs that have large amounts of video memory can easily exhaust their virtual address space.


Thanks

Tom

My Youtube Videos!

http://www.youtube.com/user/tf51d

Share this post


Link to post
Share on other sites

All good info, I feel a lot more informed now. Im still confused as to why it can't simply remove files from the VAS before its about to crash though, surely even unloading some non critical files like scenery would be beyter than crashing.

Share this post


Link to post
Share on other sites

All good info, I feel a lot more informed now. Im still confused as to why it can't simply remove files from the VAS before its about to crash though, surely even unloading some non critical files like scenery would be beyter than crashing.

 

There's 2 reasons. One is FSX does not cleanup after itself as efficiently as it could. For example it was shown that scenery from the origin was still allocated in  VAS at destination. The other issue, is VAS must also be contiguous. So for example say FSX requires 50MB address space for data, and you have 300MB free, but the largest contiguous space you have available in that 300MB is 48MB, then FSX will still OOM. This is why most OOM's occur toward the end of the flight, when a large amount of data, for the destination airport/AI is loaded, usually on approach or just after landing, and VAS is at it's most fragmented state.. This can be managed to a point by freeing up unnecessary space up front. The way I do it is to set  ManualLoad to True to all my optional startup dll's in the dll.xml file. Usually the dll's for aircraft addons (No sense loading Captain Sim DLL's when I'm flying a PMDG aircraft). When FSX starts it will then ask which dll's you want to load, say no to all that are not being used. With our craving though for High 4096 Res scenery (The SDK specifies FSX only officially supports a max 1024 res graphics) and high detailed complex system aircraft,  somethings gotta give. You can't get away with sticking 10 pounds in a 5 pound sack for long with out it coming back to bite you once in a while.


Thanks

Tom

My Youtube Videos!

http://www.youtube.com/user/tf51d

Share this post


Link to post
Share on other sites

You can either

 

  • start with a lower VAS usage (lower your graphics settings, texture sizes, disable addon scenery before starting FSX)
  • or save your flight (before your TOD, for example), shut down FSX, fire FSX up again and reload your flight. This mimics a "VAS cleanup".

Share this post


Link to post
Share on other sites

You can check VAS (space left). Only with registered FSUIPC.

 

1-Open the FSUIPC setup screen. Go to the “logging” tab, and in one of the “specific value checks” enter the value 024C (first character is zero, 
 
not the letter”O”.
 
2-Change the “type” for that value from S8 to S32.
 
3-Click on the checkboxes to display the value either at the upper window bar, or within the main FSX screen.
 
Now save and exit. Going forward, you will have a continuously-updated readout in-game of free VAS remaining.

Share this post


Link to post
Share on other sites

You can permanently monitor VAS with the freeware Process Explorer from Microsoft.

I like the FSUIPC approach, because it shows you what is free not what's used, which is more useful info to me.


Thanks

Tom

My Youtube Videos!

http://www.youtube.com/user/tf51d

Share this post


Link to post
Share on other sites

If FSUIPC can see the nearing of the VAS limit, FSX/P3D could too. Then it should either stop loading new objects or flush out any one ones but not just unceremoniously bomb like it does now..

 

 IT should throw out the eye candies but let me continue flying


Manny

Beta tester for SIMStarter 

Share this post


Link to post
Share on other sites

So why can't the processes in FSX be offloaded to another program and that program handle processing to get around this vas limit?

 

Do we need an emulator for FSX?


 

 

supporter.jpg

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...