Interesting read at Anandtech:http://www.anandtech.com/showdoc.aspx?i=3034Makes you wonder why 64bit isn't commonplace by now... 32bit addressing was introduced in '86... over TWENTY years ago, and 64bit on the desktop isn't even close to prime time yet. "A messy transition" is an understatement!

Yes, it is a shame that 64-bit is so slow to accumulate. The article didn't seem to mention the amount of work that has been done on the FSX forefront to aleviate the limit and the resulting OOM CTD. You can read my tip #3 in the first reply in thread: http://forums.avsim.net/dcboard.php?az=sho...&topic_id=27027I wonder why they aren't tagging more games for "LargeAddressAware" and using the "userva" trick?Between that and using FSAutostart to defrag the memory before starting FSX, I have not had one single OOM CTD with many addons running in many weeks.

Well for me the "LargeAddressAware" and using the "userva" trick resulted in the same OOM issue I have with the LDS 767 at ZBAA and, new to me, FS Build no longer loading due to OOM. I had to turn it all off. As always YMMV!Gary

>Well for me the "LargeAddressAware" and using the "userva">trick resulted in the same OOM issue I have with the LDS 767>at ZBAA and, new to me, FS Build no longer loading due to OOM.> I had to turn it all off. As always YMMV!Wow, that's weird. Especially FSBuild giving erros. Something's not right. Also, were you using FSAutostart to defrag the memory prior to starting FS to see if it made a difference. Off the top of my head, it kinda sounds like a bad stick of RAM or too tight on the timings.

I can now duplicate that pesky OOM message (and shut down FSX) at will on my system. It seemed to me this article finally explains what's going on with that mysterious "Out Of Memory" error that has been plaguing everybody. It doesn't seem to complicated . . . to understand, that is. It seems that fixing it will turn out to be generational endeavor. To draw an airplane analogy, it seems Windows has a fuel burn / remaining / required monitoring system just like an airplane equipped with a Flight Management System. In this comparison, fuel is the memory and the running engine is the program running. For instance an MD-11's FMC will auto-load fuel to various tanks to accommodate the current engine burn / aerodynamic (weight and balance) requirements. Windows does the same thing with memory. Ever notice your tower about to tip over then suddenly right itself. Really? Well, watch next time. Windows will auto-load memory into either physical ram (your ram sticks) or the Page File (the hard drive, sometimes called "Virtual Memory") based on some-darn-thing. See, you thought I was kidding. And like the MD-11, the Windows is not done yet either. The MD11's FMCs will also keep up with fuel forecasting; the fuel required to safely complete the flight. It is constantly looking at winds, temperatures, flight plan changes, engine burn rates, etc. With this information, it continually recalculates how much fuel it has and how much it will need to reach the FP'd destination. If at any point the FMC calculates it will not have enough fuel to reach the destination, it will throw the "Insufficient Fuel" message. Window's FMC also is hard at work to make sure the program will be able to continue normal operations. If Windows foresees an impending catastrophe (in its little Windows world) it will take action. It will -- entirely inaccurately -- throw the (dreaded) "Out of Memory" message, simply shut down the program and send its operator directly down to Circuit City to buy more ram. But of course, we already know that won't help. What's going on here? Anandtech describes that 32 bit operating systems have a 2 GB memory limit for programs to use. It seems that our forefathers foresaw that 4 GB was the most anyone sane human being would ever need to run a computer. They determined that it was imperative that 2 GB of this precious memory resource be under absolute reserve to protect the operating system's integrity. The program's could NeVer have this. Therefore, Window's FMC was programmed to absolutely limit any program's memory use to (the other) 2 GB. As Windows ticks along monitoring an operating session, it is always looking ahead and receiving information from programs about their predicted memory needs. If a program gets too greedy with its reserve requests, windows is right there to enforce the law. An "OOM" message is NoT about current ram usage. It's a forecast of what Windows believes a program will need In The Future. If windows recognizes that a program will need more that 2 GBs, the Window's "FMC' will throw the "Out Of Memory" message and summarily shut down program in question. I was able to duplicate this circumstance exactly with FSX. I was also able to watch it happen in real time with Microsoft's "Process Explorer" addon program. We all need to get this little program. It's a gem. http://www.microsoft.com/technet/sysintern...ssExplorer.mspxMy poor old system took one for the team, but smoke and all, it OOM'd FSX. I used the Amazon mission because of the heavy autogen/terrain. I have a dual monitor setup and ran FSX in one and Process Explorer in the other. I could see it coming a mile a way. It shut down FSX with the OOM message right on schedule as Window's hit that 2 GB reserve. Just as advertised. Ref the Pic: Notice actual ram usage is well under my available ram. I have 4GB of physical ram and only 2.33 GB is in use. That new program "Process Explorer" is really hard to read. The terms are simply terrible. Thank goodness for AnandTech. I don't see how anyone could have figured this out without a CS degree. Here are the 3 parameters to watch."Private Bytes." This is the total memory in use, both physical ram and Page File (the Harddrive Virtual-Ram) . "WS Private." This is Working Service part of the Private Bytes. Out of the total ram in use (Private Bytes), it is the actual Physical Ram in use. Geeeze, could they make this more complicated? . . . just wait. "Virtual Size." -- THIS IS IT -- This is Window's prediction of what it believes a program will need. In this shot, notice FSX.exe just hit 2.016 GBs. As soon as this number exceeded 2 GB, FSX shut down with the OOM message . . . "Your computer has run out of available memory. Bla Bla. . . " Am I out of memory? Not a chance. FSX is using 1.4 GB of physical ram out of 2.33 GB of physical ram in use. I have 4 GB installed. FSX has .4 GBs in the page file with 4.6 GB available. I haven't come close to running out of memory. What Windows did see FSX's PROJECTION of needing greater than 2 GBs (called here "Virtual Bytes'). As this projection hit 2.016 GB, Windows shut down FSX with an OOM message. Bam.So there we have it. Down load this little program and play a bit. You have to go into the View > options set to get the right column up. Watch the Virtual Size column. Run it hard. Over 2 GB here will shut down any program.There's some chat about resetting this limit to 3 GB. Anandteck cautions, you are taking available addressing locations from the kernel. Again, this is NOT about actual memory usage. This is about Window's need to reserve parking spaces for VIPs (operating system dignitaries) that have not arrived yet. How will these VIPs react to a proletarian program using their spots. Wanta poke the tiger? This is kernel level stuff. Are we having fun yet?http://forums.avsim.net/user_files/175410.jpg

Yea, and look at all the other stuff you have running chewing up the virtual-memory. FS likes to run all by itself. Kill the sidebar, AVG, jusched, groove, etc... Go get FSAutostart or something similar and shutdown all uneccessary processes ans services. Also very important is to defrag your memory before starting FSX. Remember, if you don't have a large single-block of free virtual-memory, FSX can show the OOM error because of this as well. Vista especially...

The 2 GB space Virtual Size allotment is allocated - per-program -. Every program has an independent Virtual Size allocation of 2 GB. It doesn't matter how many programs are online. Running out of physical (or page-file) ram is NoT what is causing these OOM / program shutdown events. Even more, reducing one program's - Virtual Size - forecast will not "free-up" additional - Virtual Size - availability for any other program. This is where we are missing the point. FSAutostart, defragging, adding physical ram, increasing the page file size, etc, are certainly good strategies to address some issues, but not this one. This is not about actual ram loads. It's about Window's FORECAST of ram loads for that particular, individual program. If Windows FORECASTS that a program will use over 2GB, bam, it will shut down. It doesn't wait for the ram load to actually get there. That's what that (poorly named) "Virtual Size" number describes. It's only a forecast . . . and the program is being shut down solely on the basis of this forecast. It doesn't matter how much ram is actually on board or in use. In this case, reducing the fuel requirement of one airplane will not allow the next airplane to go further. Relative to these Virtual Size, forecast based, shutdowns events, all programs are independent.

Exactly. The other point is that process explorer is a much better tool for these evaluations than the task manager.scott s..

D17S is correctWS private is working set private - the amount of bytes usedby the program and only accessible by a program and loaded inphysical RAMPrivate bytes : total bytes used by the program and only accessibleby the program, some of this is paged (on disk), the amount pagedis the difference between private bytes and WS privateVirtual size : total bytes attributed to this process.So the difference between Virtual size and private bytes is thespace that is "public" ie space used by the OS to service this application but still accessible by other processes - called sharedmemory. Could be disk IO buffers, more likely graphics space.The magic number here is Virtual size : this is the number that hits2Gbytes and results in OOM. It is NOTHING to do with the amount ofRAM you have, the size of your computer, the number of processors,your graphics card. You are running a 32 bit OS and only 2Gbytesof memory is available to 1 process in windows. You can increasethis with /3Gbytes switch - but be warned this can cause seriousproblems - within the boot.ini. Them main problem is that there isa hard limit of 4Gbytes that must include all the device drivers,IRQ space and graphics memory shadow - got a big graphics card thenyou are using lots of main memory to shadow your GPU memory andthis must fit in the last bit of addressable space.All to do with address space for memory and 2^32 = 4Gbytes.Tom