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

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.

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

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?

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

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.

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

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.

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

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..."

There is absolutely no relationship whatever. Once again, the "Process Explorer" utility is reporting on physical RAM and virtual RAM.

OK, but the informations reported by "Process Explorer" in section "Virtual Memory", are more or less in correlation, or if you prefer, "in connexion" with the VAS.

No, in this context "Virtual size" is referring to the number of bytes of physical and/or virtual RAM...

In other words, you mean we cannot deduct from the behaviors of "Virtual size" and "Private Bytes", what really happen on the level of VAS table.More or less that !!!

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... :(

Yes, I undersand it is very difficult to explain such a complex way of managing memory in a computer (with Microsoft, I always thought his phylosophy should be: "Why to make it so easy, when you can do it soooo complicate" ). But, I must say you succeed really well to enlight the darkness in which we are all plunged !!! After the Library, the antiquated card catalog, the books, now, the mathematical beauty of a Beethoven Symphony !!!I love your imaged explanations. It really help understanding !!! :(

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."

I understood that "Virtual size" was the memory address "interval" into process VAS and "Private Bytes" the quantity of used memory repartited into this interval.So I was looking at "Private Bytes" thinking it can, "IN THEORY", grow up to a maximum of 2GB (the section of the VAS allocated to applications) and the maximum contiguous space still available could be deducted from 2GB minus "Virtual size".But in fact, all this stuff is muuuuch more complex, as you try to explain here.NOW I AM CONVINCED that we are just totally BLIND.That the single tool we have is not even a "blind person's stick" !!!That Microsoft, as usually, created a "Monster" on which we don't really have control.

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..."

Yeah, bam! That's what happen when the Monster wake up :oBut something really shock me:To have a computer with absolutely all unecessary task's & services shuted down, 2GB of good physical memory, 4GB of good cache memory defined on the HDD, so in all, a virtual memory of maximum 6GB, just running FS2004 version 9.1,... and this computer come to the conclusion that it is out of available memory when using ""only"" 750MB.I also do not understand why the "Virtual size" grow up so much when you are flying, even if the "Virtual Bytes" remain stable (no memory leak). This is for me, the only visible symptom that FS just make the Microsoft Monster crasy.So, in conclusion, we know how to avoid to wake up the Monster (64bit OS and/or 3GB tweak), but we will NEVER have a real solution to OOM's, because we don't even know what really happen when FS return this error."n4gix". Again many thanks for your patience and your imaged explanations. :( Regards,ACS

Wow, this thread got more and more technical real quick.My story:I have NEVER had an OOM in years of simming. I have xp 32-bit, 2 gigs of ram. This includes my old system and my new top end system. I run all popular add-ons with all complex planes, and complex airports, traffic..etc etcBig thing for me...look into each add-on you download..and look for patches..both official and unofficial and look at what people are saying about them. Example: UT USA has a well known problem that causes OOMs around the coast because of a memory leak or a missing texture or something like that. The official patches don't fix it, a unofficial patch does. I discovered the missing file while trying to work out stutters using FileMon. After I patched it..no problems.Just my 2 cents.

I have NEVER had an OOM in years of simming.

Touch wood Red1 !!!ACS

To have a computer with absolutely all unecessary task's & services shuted down, 2GB of good physical memory, 4GB of good cache memory defined on the HDD, so in all, a virtual memory of maximum 6GB, just running FS2004 version 9.1,... and this computer come to the conclusion that it is out of available memory when using ""only"" 750MB.

Okay. If it helps at all, substitute the words "address space" for "memory" in the error message!For sake of illustration, imagine that each "card" in an old-fashioned "library card catalog" represents one "byte" of memory.You have a hundred card drawers, each of which can hold precisely 10,000 cards maximum. So you can store -at most- 1 megabytes of information... one million index cards... The other restriction is that once cards are filed, they cannot be moved from their current location.Currently, your card catalog has a total of 999,702 cards, leaving room for only 298 more cards...You have 100 new cards to place in the catalog, but these cards must be in sequential order since they are part of a new, 100 volume encyclopedia.The problem is that you have only "room" for 98 sequential cards (contiguous space!). Bam! Your task suddenly ends because "You have run out of available address space" :(

Hi,I had a very odd OOM error recently - it would occur at the initial loading of the sim. Found out it was due to an apparently corrupt AFCAD file!