Archived

This topic is now archived and is closed to further replies.

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
Help AVSIM continue to serve you!
Please donate today!

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. 

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.

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.

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.

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

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?

Share this post


Link to post
Share on other sites

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. This really cleared it up for me.

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.

 

 

Nice tip! How in the heck did you find this out? I 've looked at FSUIPC's screens for years thinking they might have well been written in Greek. ^_^ Any way to check CPU/MB temps with any other values?! Anything else? Thanks!

Share this post


Link to post
Share on other sites

 

 


The way I do it is to set ManualLoad to True to all my optional startup dll's in the dll.xml file.

 

I was not having any OOMs but I thought what the heck, tweak away as usual. I spend more time tweaking that I do flying sometimes, ha!

 

I implemented this suggestion today. The results are TBD on a long flight with the PMDG NGX, but I also did some other messing around under the hood. I have disabled Hyperthreading and Virtualization in my BIOS (already had SpeedStep Tech disabled). I then set my Affinity to 14 and will take a long flight in a bit to check things out. I chose AffinityMask=14 based on a test scenario set of results (my proc is a Core I7 975 Extreme CPU):

 

Test scenario = KLAX about 500' AGL, SLEW mode, daytime, weather=clear, saved flight

Mask      Full Screen      Windowed

15           16 FPS             12 FPS

12            15 FPS            11 FPS

14           19 FPS              12 FPS

 

So my mask will stay at 14 for the next flight, and I will only load the modules I need for the flight.

Thanks for the tip.

 

BTW I will never understand why some folks report higher FPS in windowed mode over full screen mode. Since my FS9 days, I have ALWAYS gotten better FPS with full screen. I have always had nVidia GPUs too, never an ATI.

Share this post


Link to post
Share on other sites

This is an automatic message.

 

This topic has been moved from "MS FSX Forum" to "Crash To Desktop (CTD) Forum". This move has been done for a number of possible reasons.

  • The most likely reason is that the post was off topic.
  • The topic could also have contained images or a video that were not appropriate to the original forum it was posted in.
  • The images might not have been "illustrative" or "explanatory" in nature.
  • The topic could have been moved because we deemed it to be more appropriately placed elsewhere.
Please ensure that your posts are "on topic" and contain illustrative images or videos as appropriate. Do not post videos or images just for entertainment purposes anywhere but in the screen shot or video forums. See our image posting rules here.

 

Members who continue to post off topic posts can be denied entry to specific forums in order to reduce and remove the practice. Your cooperation is appreciated.

Share this post


Link to post
Share on other sites

This discussion is very interesting to me. I'm sorry if I sound a little Thick but I'm an old analog guy with little understanding of what goes on oon "under the hood (bonnet)" of my computer.

 

I run a very low spec (see profile) rig.  My expectations are fairly low (10-20fps) but I occasionally have OOM's in built up urban areas like LA.

 

Below is my dll.xml (I hope it's the one you refered to):

 

<?xml version="1.0" encoding="Windows-1252"?>

<SimBase.Document Type="Launch" version="1,0">
  <Descr>Launch</Descr>
  <Filename>dll.xml</Filename>
  <Disabled>False</Disabled>
  <Launch.ManualLoad>False</Launch.ManualLoad>
  <Launch.Addon>
    <Name>ObjectFlow_KCMW.dll</Name>
    <Disabled>False</Disabled>
    <ManualLoad>False</ManualLoad>
    <Path>C:\Program Files\Microsoft Games\Microsoft Flight Simulator X\ORBX\FTX_NA\FTX_AA_KCMW\Scenery\ObjectFlow_KCMW.dll</Path>
  </Launch.Addon>
  <Launch.Addon>
        <Name>Objectflow_CBB7.dll</Name>
        <Disabled>False</Disabled>
        <ManualLoad>False</ManualLoad>
        <Path>C:\Program Files\Microsoft Games\Microsoft Flight Simulator X\ORBX\FTX_NA\FTX_AA_CBB7\Scenery\Objectflow_CBB7.dll</Path>
    </Launch.Addon>
  <Launch.Addon>
        <Name>Object Placement Tool</Name>
        <Disabled>True</Disabled>
        <ManualLoad>False</ManualLoad>
        <Path>..\Microsoft Flight Simulator X SDK\SDK\Mission Creation Kit\object_placement.dll</Path>
    </Launch.Addon>
  <Launch.Addon>
        <Name>Traffic Toolbox</Name>
        <Disabled>True</Disabled>
        <ManualLoad>False</ManualLoad>
        <Path>..\Microsoft Flight Simulator X SDK\SDK\Environment Kit\Traffic Toolbox SDK\traffictoolbox.dll</Path>
    </Launch.Addon>
  <Launch.Addon>
        <Name>Visual Effects Tool</Name>
        <Disabled>True</Disabled>
        <ManualLoad>False</ManualLoad>
        <Path>..\Microsoft Flight Simulator X SDK\SDK\Environment Kit\Special Effects SDK\visualfxtool.dll</Path>
    </Launch.Addon>
  <Launch.Addon><Name>FS Recorder</Name><Disabled>False</Disabled><ManualLoad>False</ManualLoad><Path>C:\Program Files\FS Recorder for FSX\FSRecorder_FSX.dll</Path></Launch.Addon>
  <Launch.Addon>
        <Name>A2A Feel</Name>
        <Disabled>False</Disabled>
        <Path>Modules\A2A_Feel.dll</Path>
        <DllStartName>module_init</DllStartName>
        <DllStopName>module_deinit</DllStopName>
    </Launch.Addon>
  <Launch.Addon>
        <Name>AccuFeelMenu</Name>
        <Disabled>False</Disabled>
        <ManualLoad>False</ManualLoad>
        <Path>Modules\AccuFeelMenu.dll</Path>
    </Launch.Addon>
  <Launch.Addon>
        <Name>Flight Recorder</Name>
        <Disabled>False</Disabled>
        <ManualLoad>False</ManualLoad>
        <Path>Aerosoft\Flight Recorder\AS-FlightRecorder.dll</Path>
    </Launch.Addon>
  <Launch.Addon>
        <Name>FSUIPC 4</Name>
        <Disabled>False</Disabled>
        <Path>Modules\FSUIPC4.dll</Path>
    </Launch.Addon>
</SimBase.Document>


Do I change all the Manual Load entries to TRUE? If not, which entries can I do without to increase VAS?

 

Here is my boot.ini:

 

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect/3GB/Userva=2560

 

Thanks. 

 

Slim

Share this post


Link to post
Share on other sites

Yes set to True all the addons you are not going to use on every session, for example Aerosoft Flight Recorder which is for the A320X. Set that to TRUE, when FSX starts it will ask if you want to load it. Say no unless you are going to fly the A320 on your flight, then say yes. Leave the DLL's that you use on every flight the way they are. Looking at your list you don't have too many that would be considered optional. You can set the SDK ones to TRUE, many you have are scenery related. I usually don't touch ones that affect scenery. Most of my optional DLL's are from Aircraft Addons, which it looks like you don't have too many off. The only one I see is the A320X

 

Also, you only have a 512mb video card, so you probably don't need the /userVA=2560 switch (Leave the /3GB switch), This will give you more space. If you had a 784MB or 1GB card then you would need that switch.

Share this post


Link to post
Share on other sites

Thanks for the help.  Look at my boot.ini.  I think I have the 3GB switch enabled but I'm not sure.

 

Slim

Share this post


Link to post
Share on other sites

Thanks for the help.  Look at my boot.ini.  I think I have the 3GB switch enabled but I'm not sure.

 

Slim

Not in your default boot entry but in your 3rd boot entry. You also have the /userva=2560, switch, which I don't think you need with your size video card. If you aren't manually selecting that boot entry on startup, then no your not setup for LargeAdressAware.  Change your boot.ini

 

[boot loader]

timeout=30

default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS

[operating systems]

multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect

multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect/3GB/Userva=2560

 

To this

 

[boot loader]

timeout=30

default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS

[operating systems]

multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect

multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional 3GB" /noexecute=optin /fastdetect/3GB

 

Then on boot select the entry for "Microsoft Windows XP Professional 3GB"

Share this post


Link to post
Share on other sites

so you probably don't need the /userVA=2560 switch

 

Sorry for the cross post.  Irrelevant question now.

Share this post


Link to post
Share on other sites

 

 

Do I replace that value or just delete it entirely?

 

Slim

 

Just delete that  switch, like I shown. Be careful editing that file, a mistake may make your system unbootable.

Share this post


Link to post
Share on other sites