The "impossible" OOM ?

[ACSoft 3]

Hello,Running FS9.1 on Windows XP SP3 standard (no 3GB tweak) on a system with 2GB of memory + 512MB of video RAM, a pagefile.sys file of 4GB, It happen to me to have sometimes the hated OOM error.I read all about these damned OOM errors, in this forum and other places. What I mainly understood, is that OOM will occur as soon as FS9 fail to get memory, because there is no more available memory into the 2GB adressable range for the process.If this is true, why do I get OOM error in the following case ?As you can see, OOM occured when FS was using "only" 865MB, inside a virtual size of 1,655GB. It occured, as usually, during the approach of my destination airport.1,655GB of virtual size, mean probably that the 865MB of private memory usage are quite heavily fragmented into this space. But, nevertheless, 345MB of remaining adressable space, should have been far enough, even in the case the memory request wouldn't have fit into some of the holes inside the used range.Do I missunderstood something ?If some Guru's out there have an explanation for this case, I would love to know it.Thanks in forward.ACS

[Mike T 208]

ACS:If you've read the years of posts about OOM errors you should know that the only true VERIFIABLE fix is to move to a 64-bit operating system, period, end of story. This has been discussed and even Microsoft ACES has agreed that this is the case. Trying to make sense of it all will simply waste your time trying to troubleshoot something that everyone, including ACES, has tried to figure out but cannot.Some addons are known to cause OOM errors, such as PMDG 747 in both FS9 and FSX, and also Ultimate Terrain. Additionally, duplicate AFCADs have caused OOM, having a texture subdirectory directory in a landclass directory has been notorious also. For instance, in FSX I CANNOT run PMDG 747 at Dreamscenery KORD because it always gives an OOM error. In FS9 I've also experienced many OOM errors over Boston, descending into New York, but only when flying from Europe. I upgraded to Vista 64-bit and all of this went away. I've not seen an OOM since.SO save yourself the headache, if you are one of the unfortunate experiencing OOM errors, upgrade to a 64-bit OS.

[kerosene31 348]

For what it is worth, I've been flying FS9 since the day it came out, and I've never seen an OOM error. The only crashes I've ever seen have been from bad scenery or bad addon aircraft (an uninstall or patch always clears it up). I run regular Win XP 32 bit with no issues. I'm not sure if it is certain add-ons that cause this or not (maybe something I don't have?). I run a good number of add-ons and never seem to have this problem. (Ultimate Terrain, ASA, traffic, 3rd party scenery and aircraft, etc). What I do is regularly run scanafd to search for and eliminate duplicate afcad files. I also keep a detailed database of every scenery I install, and if something causes a problem, it gets uninstalled right away. Maybe it is because I rarely fly complex heavies?

[Kosta 122]

If you've read the years of posts about OOM errors you should know that the only true VERIFIABLE fix is to move to a 64-bit operating system, period, end of story. This has been discussed and even Microsoft ACES has agreed that this is the case. Trying to make sense of it all will simply waste your time trying to troubleshoot something that everyone, including ACES, has tried to figure out but cannot.

I can only confirm this one-hundred-percent.I have seen a great deal of OOMs around 1700mb-ish virtual size. They mostly happen when you have lots of addons.An example: fly from a heavy addon airport, to the heavy addon airport, using a heavy aircraft (example: PMDG MD-11, 747, 737, PSS 777, DA Fokker...), UT has to be installed, possibly using AES for both, and possibly fly over one or two addon airports on the way (this is not a must though), and you WILL see an OOM - your memory usage will be somewhere inbetween 2300 and 2800mb.Tested it all under 64bits...

Maybe it is because I rarely fly complex heavies?

This is for sure ONE of the reasons. Though its more factors, and no addon for itself causes trouble.

[ACSoft 3]

I have seen a great deal of OOMs around 1700mb-ish virtual size. They mostly happen when you have lots of addons

So something, relatively close to my case, but in contradiction with the "theory" too and that was my point.

An example: fly from a heavy addon airport, to the heavy addon airport, using a heavy aircraft (example: PMDG MD-11, 747, 737, PSS 777, DA Fokker...), UT has to be installed, possibly using AES for both, and possibly fly over one or two addon airports on the way (this is not a must though)...

Of course, almost right my configuration !!! No miracle !!!

If you've read the years of posts about OOM errors you should know that the only true VERIFIABLE fix is to move to a 64-bit operating system, period, end of story. This has been discussed and even Microsoft ACES has agreed that this is the case. Trying to make sense of it all will simply waste your time trying to troubleshoot something that everyone, including ACES, has tried to figure out but cannot.

Very interesting !!!This mean there is, in fact, no valid "theory" about FS OOM.I didn't knew that.

SO save yourself the headache, if you are one of the unfortunate experiencing OOM errors, upgrade to a 64-bit OS.

Fortunately, I have only very few of them and like you said, in some particular flights.But I notice, Thanks !!!Upgrade to a 64-bit OS is the solution, if I cannot accept anymore those few OOM's.ACS

[Kosta 122]

The worst thing for me, back in my 32bit days, were approaching the airport with the thought "is it going to OOM now or will I have a safe landing?".Since I went 64bit, flights were something different for me: not scared any more of any panel change or opening something while on approach - since I upgraded, *every* landing was a smooth one (this is due to new fast HDD) and without any problem.

[Guest Ocala 1]

So if someone has a 32 bit system what do they have to buy to get a 64 bit system???

[Guest Boeing Skunk Works]

I've seen this error once in the four years I've been using FS9 on a WinXP 32bit system. I have the usual add on's; UT Europe, several other hi density airports, etc.Deleting and rebuilding the page file will fix this. At least it has for me.

[aentwis 61]

On an unpatched (I mean the 3Gb switch and treatment of the programme executable here) 32 bit Windows installation, when the virtual memory size of a running application threatens to reach the 2Gb mark, the application will quit with the OOM error message. At the point of quitting, it is likely that the virtual memory size has not reached that figure, but would have done so if the operation to be carried out had been carried out. You will most likely never see much greater than 1700-1800Mb VM size for the unpatched max. 2Gb executable...Adding more RAM will not have any effect, nor will increasing the page file in size. It is simple, the application needs more virtual memory than can be allocated to it. The only fix on a 32 bit system is to use the 3Gb switch, and modify the userva variable accordingly. With a rather stripped down Windows installation and a 320Mb VRAM graphics adapter, I get around 3.25Gb RAM available physically (because of the issues of address space for 32 bit systems and the requirements of the OS for critical applications).Since I set the 3Gb switch, userva=2560, and patched the FS9.exe file, I have not experienced an OOM with any addon (I have sinced logged 100 hours on the MD-11, into and out of some of the more complex airport addons around, such as EDDF, EGLL, and so on...) at all.The other solution of course is to switch to a 64 bit version of Windows, but I won't be contemplating that until the release of Windows 7. So far, FS9 with the 3Gb switch is working like a dream... whatever I throw at it...Andrew

[Kosta 122]

I've seen this error once in the four years I've been using FS9 on a WinXP 32bit system. I have the usual add on's; UT Europe, several other hi density airports, etc.Deleting and rebuilding the page file will fix this. At least it has for me.

Disable and delete pagefile.sys and you will still suffer of OOMs if you suffer from them now.Pagefile has nothing to do with the OOM. Only if there really isn't enough memory in the computer, and you disable pagefile, then you will get not enough memory even with 1GB, of course.

The other solution of course is to switch to a 64 bit version of Windows, but I won't be contemplating that until the release of Windows 7. So far, FS9 with the 3Gb switch is working like a dream... whatever I throw at it...Andrew

You know, weird thing is, no matter how often some people repeat these facts, those who are new, will often or should I say always, attempt to contradict the proven theory. Love it.I completely agree with you, the switch or 64bit, even XP, will do just fine for FS9. I love my FS9 now, flying without any worries, everything is working just great!

[n4gix 4,947]

Folks, for about the thousandth time... the "OOM Error" has absolutely nothing whatever to do with either physical memory or virtual memory...It has everything to do with Virtual Address Space. Think of VAS as the "dynamic index" to both physical and virtual memory.The "OOM Error" occurs whenever any running application cannot locate a contiguious block of "addresses" in the VAS table. While I don't the precise size required by FS9, for FSX the size limit is 1MB minimum contiguous addresses.OOM Errors are not something unique to FS, but as I stated above can affect any program, especially those which require a rather large "footprint" while running.The cause and cure for "OOM Errors" is covered in detail in this Wiki post I created quite awhile ago: http://forums.flightsim.com/fswiki/index.php/OOM_Error

[Kosta 122]

There was also some other game, I believe it was Supreme Commander which also caused OOMs at 2GB.

[ACSoft 3]

It has everything to do with Virtual Address Space. Think of VAS as the "dynamic index" to both physical and virtual memory.The "OOM Error" occurs whenever any running application cannot locate a contiguious block of "addresses" in the VAS table. While I don't the precise size required by FS9, for FSX the size limit is 1MB minimum contiguous addresses.

You put the finger right on the point of my initial message the "IMPOSSIBLE" OOM.If you look carefully on my image, you will see that private bytes where 865MB, repartited into a virtual size of 1655MB. So, from the theory you have developed here, we have potentially about 1135MB still available and the largest known contiguous space is 345MB.I simply cannot believe that a single memory request operation would requiring over 345MB !!! This sound impossible to me !!! Therefore, we are missing something here. Does FS9 return us an OOM error, but, in fact, it is NOT a real OOM ? FS9 just get lost with his own internal memory management ? I have even had OOM's with private bytes under 800MB and a virtual size under 1500MB !!!It is also interesting to observe the evolution of "Private bytes" and "Virtual size" during a test flights (over "high graphical" regions). It is symptomatic to see that the "Private bytes" remain relatively stable (in my case, a variation inside 750 to 780MB interval). But, what is bad, very bad, is the permanent growing of "Virtual size" during the same time. In this case, I started with 1098MB and finished with 1365MB !!! Here also, we can suspect that the OS memory management is doing rather poor things.OK, a 64bits OS and the 3GB patch seem to solve the problem (I would say overturn the problem !!!). But, for those who cannot upgrade to such a system (almost not now, like me), it is really sad to think that a 2GB RAM / 32bits OS PC would be probably widely enough powerful to run FS9 and all these beloved addon's, if the memory was simply managed as it should.Unfortunately, most of the time, "The way things goes with Microsoft".ACS

[N60JBravo 27]

Just 2cents worth from an acknowledged non-expert.Looking at your screenshot makes me think that the report is for memory usage of FS9 only and does not include services running in the background? If I read it correctly it does show memory used and not memory available.Could it also not take into account the 512mb of memory that will be reserved for your memory card?The error box says you may not have enough space on your hard drive. What percentage of your drive is available? If it's packed full it does not matter what you set your pagefile at, Windows needs empty hard drive space for virtual memory.

Unfortunately, most of the time, "The way things goes with Microsoft".

What's the alternative?Joe

[ACSoft 3]

Looking at your screenshot makes me think that the report is for memory usage of FS9 only and does not include services running in the background? If I read it correctly it does show memory used and not memory available.

As far as I know, this is not determinant, as long as you don't have a hudge quantity of stuff's running, who would be able to overflow the total capacity of your RAM and swap page file.Each process receive this famous 2GB of adressable space called "Virtual size". Then, the private bytes used in this space, are physically mapped into the RAM and/or the hard-disk swap file "pagefile.sys".If you look on my picture, you will see that 852MB of the 865MB are located into RAM (physical memory). This mean obviously that my PC is optimized to run FS2004 in the best possible conditions. Apart FS, you just have the strict minimum.

Could it also not take into account the 512mb of memory that will be reserved for your memory card?

As far as I know, this is a separate memory mapping.

The error box says you may not have enough space on your hard drive. What percentage of your drive is available? If it's packed full it does not matter what you set your pagefile at, Windows needs empty hard drive space for virtual memory.

I have two physical hard disks, one for the system and another one, for FS and other games. Both disk are about 3/4 empty. Both disks are optimized with "UltimateDefrag".My cache page file is defined on system disk and has the max possible size (4GB fixed). I tried also with 2 cache files (one on both disk), but it does not make any difference.

What's the alternative?

LOL !!!That's a good question, unfortunately !!!ACS