(This article originally appears in the PMDG 777-200LR/F Introduction manual on pages 21-25)
We would like to acknowledge FSX community member Srdan “Kosta” Kostic’s research into the OOM problem and VAS usage on which a good portion of this article is based.
Background and theory:
FSX is a 32-bit application. Even under the recommended Windows 7 64-bit operating system, the FSX.exe process always faces the same mathematical limitations that all 32-bit applications do. One of these is a 4GB hard limit on something called “virtual address space” (VAS). When FSX crashes with an error message saying that your computer has run out of available memory (commonly called an “OOM” in the sim community), it’s actually talking about VAS, not physical memory like the amount of RAM in your system. Customers who have huge amounts of RAM like 16GB or 32GB are often baffled by this message for good reason – they certainly aren’t running out of physical memory. Microsoft probably should have made the error say “The application has run out of virtual address space.” instead of the vague “memory” term.
VAS is effectively a preallocation of everything the simulator can potentially access during a flight and will fluctuate over the course of using the simulator as you fly between different areas. Note that VAS is *NOT* the same thing as the “virtual memory” swapfile that you can set the size of in the Windows system options – they are two very different things and having a large virtual memory swapfile does not protect you from the 4GB VAS limit. The mathematical limit itself comes from the definition of “32-bit” – a bit is the most basic data structure in computer science and it can have two values, a 0 or 1, which can mean all sorts of things like true or false, on or off etc. This is why at the core a computer executes “binary” code. The amount of VAS a 32-bit process can access can be calculated by raising the number of possible values for each bit (2) to the power of the number of bits available (32). So 2^32 equals exactly 4,294,967,296 bytes (not bits). When you do the rest of the conversion math this value comes out to exactly 4 gigabytes of potentially addressable memory for a 32-bit process.
The reason we recommend using a 64-bit operating system like Windows 7 64-bit is due to the fact that it can give FSX.exe that entire 4GB block of VAS. In 32-bit Windows the default is a maximum of 2GB of VAS for FSX and 2GB reserved for the operating system. This can be increased to 3GB for FSX through an edit to the boot environment configuration (“the 3GB switch”), but this is still 1GB lower than you’ll get with the 64-bit version of Windows and it makes both OOMs more likely and OS crashes more likely because it reduces the amount of VAS the OS itself has to work with. 32-bit versions of Windows can also only ever access 4GB of total physical memory, so if FSX is using 3GB itself, there’s not much there for the OS and other applications. 64-bit Windows does not have this limit and with a lot of RAM you can essentially run as many other applications outside of FSX (browser, weather apps, flight planners etc) as you want with no effect on the system. There is literally no reason not to run the 64-bit version of Windows 7 on an FSX simming PC.
Mark is the author of the Process Explorer tool below, a member of the Windows kernel design team at Microsoft, and one of the most knowledgeable people in the world on how Windows actually works.
Using Process Explorer to monitor VAS:
With the proliferation of so many high detail aircraft and sceneries for FSX in recent years, the sim can easily approach and in many cases exceed the 4GB VAS limit. As the sim approaches the limit, very odd things startcan start happening like disappearing scenery, disappearing or transparent visual models on the aircraft, flashing artifacts, long pauses and so on. If it exceeds the limit you will get the OOM error window or the sim will just crash to desktop (CTD) without any error message at all.
If you’re having VAS issues, the first step is going to be to determine how much VAS FSX.exe is actually using throughout your flight. Fortunately Microsoft has a tool that allows you to do exactly this called Process Explorer – you can download it here:
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
Once you have it downloaded, unzip the files to a folder of your choosing and run the procexp.exe file. You’re going to see a rather bewildering looking list of all the processes running on your computer with various columns full of parameter values that are constantly updating. The first thing you’re going to want to do is enable the VAS display – to do this, right click in the area where the column names are and choose “Select Columns”. Go to the “Process Memory” tab in the window that pops up and put a check mark next to the one called “Virtual Size” and press OK. This is going to enable the column, but it will likely be at the far right of the Process Explorer display. We recommend maximizing the window and then dragging the Virtual Size column over so that it’s right next to the CPU column so that you can easily see it. Click the top of the column where it says “Virtual Size” until you see a downward pointing arrow, which means the list is now sorted with the highest VAS using applications first in the list. You can now resize the window to a more manageable size.
Now run FSX and monitor this number for the FSX.exe process while you use the simulator. It should quickly move to the top of the Virtual Size column as the sim loads. If you see it start to get close to 4,194,304K (this is 4GB in kilobytes) – you know you have a VAS problem.
Causes of high VAS usage:
The PMDG 777-200LR/F aircraft itself uses approximately 700 to 800MB of VAS based on our testing, split roughly equally between the VC and external models and the aircraft systems programming. This is in line with other high-end addons aircraft on the market and is not excessive given the advanced capabilities of the product. Great care was taken to optimize and not increase the VAS load of the aircraft beyond what is necessary to simulate it properly.
Here are some of the more common causes of high VAS usage we’ve identified:
Large amounts of photoscenery areas
Products that install photoscenery for whole US states or whole European countries are a particularly high source of VAS usage when a lot of them are enabled at once. There are several such packages on the market and all of them will exhibit this issue. FSX unfortunately allocates VAS for these areas *even if you are not flying over them and never go near them*. We have observed almost instantaneous OOM errors upon loading our products on customer PCs where they had for instance the entire eastern United States photoscenery installed. Disabling the photoscenery reduced the total VAS load by well over 1GB and allowed the simulator to function normally. Users have reported success with photoscenery and our products by enabling only the states or countries their route passes over. Use Process Explorer to monitor VAS and see if this works for you.
To the best of our knowledge the reason this happens is because photoscenery uses a unique texture for every single area within it. Normal FSX scenery uses a small group of textures that get repeatedly used via the landclass system. Having to precache and allocate for the presence of that many textures is likely at the root of the problem.
Here is a link to a very good open source utility called SceneryConfigEditor that will allow you to make groups of scenery areas that you can turn on or off with a single click:
http://sourceforge.net/projects/fs-sceditor
High amounts of AI traffic
Be reasonable with the amount of traffic you’re putting into the simulator. Often the high 100%-type levels become unrealistic anyway from the fact that FSX’s ATC system bunches them up and can’t handle vectoring them all. You end up with a ton of go-arounds, a massive line for takeoff and so on. That many airplanes also eats into the VAS allocation. Again, this is not dependent on the specific traffic product you’re using.
Ultra high resolution environment textures
Many “environment” type addons (as with the photoscenery and traffic there are several of these available) contain options to install very high resolution textures for things like clouds, water, runways and taxiways and so on. It is our experience that these maximum resolution textures often increase the VAS load disproportionally to the amount of visual improvement they provide. A 4096x4096 resolution texture actually contains 16 times the amount of pixel data that a 1024 resolution version of the same texture does. The 1024 or 2048 versions of the textures you’re installing are likely going to be visually indistinguishable to you from the maximum 4096 version and they will result in both lower VAS usage and lower GPU memory usage.
FSX.cfg LOD_RADIUS value
Some tweak guides recommend increasing this setting in the FSX.cfg file above its normal 4.500000 maximum value. While this does improve visual detail into the distance, that improvement comes at the expense of increased VAS usage because FSX has to load in more autogen, more high detail mipmaps for textures etc. Leave this setting at 4.500000 unless you’re actively monitoring your VAS usage and are sure that setting it higher isn’t putting you into OOM territory.
Autogen, water, weather
The usual culprits for lowered performance in FSX also are the main drivers of VAS usage. Lowering them can significantly reduce the VAS load if you’ve exhausted the other possibilities.
High detail addon airports
While the effect of these in our testing is relatively minor, if you’re having problems with OOMs, you may want to consider disabling the ones you’re not actively flying between.
Flying a lot of legs without shutting the simulator down
The reason is not exactly clear, but FSX appears to not fully release the contents of scenery areas that have been used during the session. We have observed OOMs happen when flying around to a bunch of different high detail airports over high detail terrain all over a long period of time. To avoid this, simply save your flight after landing and shutdown, close FSX, and then reload it and your flight and you should be in a reset VAS
state.
Conclusion:
There are real limits in the 32-bit FSX environment that you have to be aware of and manage. It all comes down to deciding what’s most important to you. It is likely impossible for you to run every high-end aircraft and scenery addon all together at their maximum settings without making compromises to stop the OOM error from happening. It is up to you to decide what’s most important to you and prioritize between different addons using the tools outlined here.