FSX, OOM and Addon VAS Usage

Dear simmers,

Due to the fact that an OOM discussion pops up every now and then, and it usually starts from beginning, today I’d like to start a page about Virtual Address Space. Please note I’ll try to keep this document as little technical as it can be – all the technical information about the VAS can be found on the pages like Wikipedia, Microsoft, Memory Management explanations etc. I’d like to keep this simple, for everyone to understand why is FSX crashing as of late more and more. I have been observing this development in the last couple of years, as the first OOMs appeared. I also have to give my thanks to many other fellow simmers, who also helped me understand the basics of memory management and how FSX works.

Simply explained, VAS is a working space of a program (let’s just call it that). DO NOT think physical memory or page file have anything to do with this. VAS is a specific space for an application, which can, under 64bit operating system be up to 4GB for the 32bit application.

64bit OS + 32bit application (FSX) = up to 4GB VAS
(32bit OS + 32bit application = 2GB of VAS, or max 3GB with a tweak)

Remember this, as this is the 101 for OOMs.
Does it matter if you have 4GB, 8GB, 16GB, 32GB of RAM? No. Does it matter how big or disabled your page file is? No.

So what does it mean? FSX has 4GB of VAS to work with. Everything you load into FSX, basically loads into VAS. Be that an aircraft textures, airport scenery, tree texture, whatever you install and run, is going to have its place in VAS.
Since we do have a limited space of 4000MB, we have to have concerns when this space is going to fill up. All those nice airport sceneries, HD aircraft textures, they take a very heavy impact on the VAS when loaded.

One of the biggest culprits when VAS is concerned is LOD_RADIUS in FSX.cfg. This setting alone offsets the VAS usage by couple of hundred MB when bumped from default 4.5 to 6.5 (I also suggest this in my guide, but with the caveat that it can pretty quickly cause an OOM).

When this space fills up, you are presented by windows with a very nice message that your memory is low and the application will now close. FSX is going to quit.

What we should be aware of, is how much our addons use. Some use more, some use less, but they always take some VAS space. And most importantly, due to nature of FSX, this space is not freed as you fly along, nor has anyone yet come up with a plan how to free it up or fix this problem. So for example: you start your flight with an addon aircraft and addon airport, and your VAS usage is 2800MB. When you fly along, this usage will slowly grow. If you don’t overfly any other addon airports, it is bound to grow maybe couple of 100 MBs. let’s say for the sake of an example: up to 3200MB. When you come into range of your destination, and let’s assume you have an addon airport, which loads about 300MB into VAS, you will successfully land, as you will end up with 3500MB VAS.
But, let’s assume another scenario, in which you overfly two airports on the way to your destination, or you have some photoscenery, or or or, and the VAS usage grows up to 3700MB until descend. Now you can pretty much sure your sim is 99% going to crash on landing with out of memory = OOM error.

So, what you can do is only counteract it through some sim-management!

1) Always know your VAS usage, keep a tool for measuring it at hand, so you can quickly check

2) Keep your other scenery deactivated – now, while I understand this might be a nuissance, there is a simple way of doing it – SceneryConfigEditor – this tool gives you a possibility to quickly disable all non-essential scenery with a bit of sorting-imagination.
Download here: http://sourceforge.net/projects/fs-sceditor/files/

A word of caution on this tool: while very helpful, it can cost you your whole scenery.cfg if you are not careful. My suggestion is to run it as FSX obviously, but uncheck the “Follow the NewScenery convention”. This will always change the scenery.cfg directly, which means, after you install a scenery, if the installer is following the NewScenery.cfg convention, you MUST start FSX first, before the scenery will appear in the scenery.cfg. Also always keep a manual backup of your scenery.cfg.

3) Keep away from really high quality textures, as much as you can – I know they are looking nice and beautiful. If you know what you’re doing, by all means, load them up, but flying NGX with McPhat HD textures over ORBX into UK2000 EGLL with 4096 clouds is not a possibility, so much I can tell you.

4) If you are in  flight, and notice a high VAS usage (meaning very high, so that you probably won’t be able to land): save and reload the flight, possibly lower the LOD_RADIUS in between. Make sure however you are flying the aircraft that supports that (PMDG stuff does for example).

So how do we measure VAS:
There are more ways than one, but for me, the simplest one is a tool called “Process Explorer”, can be downloaded here:
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
When you start it up, I suggest you press on the Process column, to sort the processes after their names, alphabetically. As the next step, in the menu -> View -> Select Columns -> [Tab] Process Memory -> [check] Virtual Size -> OK. Additionally you can deactivate any other columns that are displayed by default, if any. In the main window, press onto “Virtual Size” column, to sort after the virtual size. This will always put FSX as the first when running.
This will give you a neat view of FSX VAS so you can quickly monitor it.

NOTE: It is NOT possible to view VAS with a stock Windows Task Manager. Anyone coming to me with that idea, will be fully ignored. Use above approach or any alternative (but then again, you should know what you’re doing if using alternatives).

So, I’d like to urge everyone, before you start yelling at developers that their scenery is causing OOMs, reflect upon your system and see how many OTHER stuff you have running and question yourself which one is the biggest culprit and where can you optimize.

Most importantly, if you have something to add to this page, which might benefit everyone, please make a comment, I’ll be glad to add it into the page.

Additionally, I will start here with couple of VAS usages for addons I own and use a lot, so you get a feeling what each addon uses, and I hope to expand the list as the time passes:

PMDG NGX: 741MB
PMDG 747: 711MB
UK2000 EGKK: 140MB
ORBX ENGLAND: 200MB

(Also please keep in mind these measurements are not 100% accurate, simply because they can’t be, they are more like guidelines)

ADDENDUM (Microsoft Fix, Heap Limit change):

FSX/P3D OOM (Out Of Memory) helper/fix