Archived

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

ACS

The "impossible" OOM ?

Recommended Posts

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 ?Impossible-OOM.jpgAs 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

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

ACSI thought Bill explained it pretty well. You may not understand it ,or believe it, but it is fact. If you run a 32 bit system, with 2 to 9zillion MB of ram, you may run into an OOM without the 3GB switch.Bob

Share this post


Link to post
Share on other sites

I've been following this topic, and have been just amused by it, how some people just won't accept the fact that OOMs happen if you don't run 64bit or use /3GB switch. Just accept it, otherwise its like searching for holy grail.

Share this post


Link to post
Share on other sites
I thought Bill explained it pretty well. You may not understand it ,or believe it, but it is fact. If you run a 32 bit system, with 2 to 9zillion MB of ram, you may run into an OOM without the 3GB switch.
Bob, my point with this thread is not to believe or not this fact, my point is to testify with my example, that the theory found everywhere on the Net, about the reasons why these OOM's happen, is probably simply incorrect.I love to really understand things !
I've been following this topic, and have been just amused by it, how some people just won't accept the fact that OOMs happen if you don't run 64bit or use /3GB switch. Just accept it, otherwise its like searching for holy grail.
Word Not Allowed, I prefer to amuse you rather than bother you !!! LOL !!!But again, my point wasn't to believe or accept anything.In my search & read about this matter here and elsewhere, I didn't found a previous testimony that this apparently unanimously accepted "theory", about the reasons for these OOM's to occur, could be totally wrong?So, this is my stone in the building !!!Again, I love to understand things and if the reason given is wrong, I though that maybe they were other tracks to explore ? Of course, I didn't knew, when I started the thread, that even ACES itself just gave up on that. So I am going to give up myself too !!! LOL !!! Like you said, otherwise, it would be like the holy grail quest !!!Apparently, it is a long time you follow these discussions about OOM's. I saw your name in many thread's. So I can understand you start to become tired of that. But it isn't my case, sorry.By the way, many thanks to always take the time to answer & help peoples about that.ACS

Share this post


Link to post
Share on other sites

My explanation to the fact that over 1600-1700mb, you get an OOM on approach is following, is simple.An addon airport can be as heavy as 300-400mb, but not concerning installation data, but rather what it loads. How many times have I seen when approaching an airport, VAS grow for as much as 400mb, and if you are as high as 1600, there is a good chance of OOM.I would suggest you do a test, set the switch, don't forget to change the exe for largeaddressaware if FS9, repeat the SAME flight with same addons, and check the VAS in the end. You will see how much over 2GB it loads.Then remove the scenery, and repeat the flight.I did many days of testing for OOM, there were two test flights, which both OOMed just on approach. It is a simple game of remove addon, test, check etc... You will soon find which one loads lots of memory.Explanation enough?

Share this post


Link to post
Share on other sites
Explanation enough?
Sorry Word Not Allowed, not really. I don't believe you are right.In my tests, OOM occur far before biggest parts of an airport are loaded. In any cases, whatever provoke the OOM in my example, IT IS JUST IMPOSSIBLE it is provoked by the famous "theory".OK, let's even say, the approaching airport weight 300-400MB. Let even say when the OOM occur, FS try to load all this stuff, which I don't believe AT ALL on second. What is sure, FS is NOT going to do just a SINGLE memory request of 400MB. You will have a salvo of many requests of different sizes and only the last one, close from the OOM condition, will fail. So, if this "theory" was correct, Process Explorer should show a state much more closer to that famous OOM condition, which is obviously NOT THE CASE.Process Explorer display only OS informations in relation with the process. So, even if the process is hanged by a OOM error, Process Explorer continue to scan these datas. We can even see them still changing after the OOM and after you answer to the OOM error message (proof these datas are still alive & valid).Regards,ACS

Share this post


Link to post
Share on other sites
Sorry Word Not Allowed, not really. I don't believe you are right.
I give up and going back enjoying MY FS9, which is not OOMing. Believe what you want. Cya.

Share this post


Link to post
Share on other sites
I give up and going back enjoying MY FS9, which is not OOMing. Believe what you want. Cya.
Hi Word Not Allowed ! Don't be upset !Where did you see, in my initial message, that I was asking for explanations or solutions ?!?!? I said in further answers, this was just a testimony that, to my humble opinion, the generally accepted "theory" about FS OOM is simply not confirmed AT ALL by the monitoring of the events with Process Explorer. Period.Dont worry, I know perfectly how to fly without OOM on my system. It is very simple. I just have to desactivate Ultimate Terrain Europe and I never have any OOM again.Regards,ACS

Share this post


Link to post
Share on other sites
Bob, my point with this thread is not to believe or not this fact, my point is to testify with my example, that the theory found everywhere on the Net, about the reasons why these OOM's happen, is probably simply incorrect
First of all, this is not a "theory;" it is a well documented fact. Microsoft themselves have been quite clear on both the causes and the solutions for what they unfortunately chose to call an "Out of Memory Error...."I say "unfortunately" because it does imply that the error does -in fact- have something to do with physical memory and/or virtual memory! Hence, the source of your continuing confusion!If you go to the local library and use either the antiquated card catalog, or the now more common computerized catalog, and do a SEARCH by TITLE for a particular book, once you've retrieved the information, all you know at that point is......where the book is currently, physically located...That "catolog entry" is not the book! It points to the book, but is not the book...That sir is precisely what the "Virtual Address Space" table is... nothing more... nothing less...By default the VAS table is divided into two sections: 2GB of addresses for application programs, and 2GB of addresses for the operating system and any peripheral hardware addresss (such as video cards, sound card (including onboard sound) and any other device installed in an expansion slot.All the "3GB switch" and "userva=nnnn" entries do is move the dividing line between the two sections, giving more or less addresses to the applications section, by simultaneously decreasing/increasing the addresses available on the other section...More to the point however, is that there is no way to "monitor" or otherwise "display" the VAS table! None of the "tools" you've cited have anything whatsoever to do with the VAS table, or its size, or its operation.

Share this post


Link to post
Share on other sites

N4gix, thanks for these interesting explanations.What is the relationship between the applications VAS and the "Virtual size", respectively "Private Bytes" shown by the tool "Process Explorer" ?Isn't the "Virtual size", the "application VAS" of each process ?Shall I understand that a single PC system only have a single VAS ?Does the so called "OOM" error come from a VAS operation failure ?Thanks in advance for the further enlightments you may give to me on this matter.Regards,ACS

Share this post


Link to post
Share on other sites
N4gix, thanks for these interesting explanations.What is the relationship between the applications VAS and the "Virtual size", respectively "Private Bytes" shown by the tool "Process Explorer" ?
There is absolutely no relationship whatever. Once again, the "Process Explorer" utility is reporting on physical RAM and virtual RAM.
Isn't the "Virtual size", the "application VAS" of each process ?
No, in this context "Virtual size" is referring to the number of bytes of physical and/or virtual RAM...The following applies to that portion of VAS that is allocated to applications and the applications data. Please understand that it is very, very difficult for me to "simplify the explanation" to make it more easily understood. In truth, this "explanation" leaves out a great deal of technical details. It is as difficult as describing a spectacular sunset to a blind person, or the mathematical beauty of a Beethoven Symphony to someone who's tone deaf and can't count above ten without taking off his shoes... :( Every loaded application has a VAS table record of how the memory addresses for the application and its data are "arranged" while it is "actively loaded" in the physical RAM space. This way, even if you have so many programs running at the same time that the operating system has to shift the bytes off into virtual memory, when any specific application needs to "do something" it is copied back to physical memory, the operation is performed, and the bytes are copied back to virtual memory.In effect, the VAS table is a "dynamic shapshot" of how the application code and its data were arranged in physical memory as of the last operation.If you have eight programs running simultaneously, then you have EIGHT separate "VAS tables," one for each application+data+operating system "snapshot."OOM Errors are caused whenever there is a "collision" or "contention" or "insufficient contiguous space" problem. The last one is the most frequently encountered by FS, because the "currently executing instruction requires 1 MB of contiguous addresses, and the largest available block of addresses is two bytes less than 1MB......bam! "Your computer has run out of available memory..."

Share this post


Link to post
Share on other sites