32bit standard edition 4GB 32bit enterprise up to 64GB64bit standard up to 32GB64bit enterprise up to 1TB.Tom Fabian, Berlinhttp://status.ivao.aero/R/199017.png

The problem is entirely about these 2-3-4GB VS limits 32/64bit op systems have baked-in running 32bit programs. 32bit-er's VS function can schedule 2G, - per program - . With 100 programs/processes running in a 32bit op system environment, VS can schedule 200GBs just for the programs (100 x 2G or 200GB). The function of VS is to protect memory room for the op system. 32bit systems have 4Gs available for VS. If programs are limited to 2Gs, there is always (2Gs per program) left for the op system. Make sense? Not much, if you ask me. VS isn't a very smart cookie. However in the 80s when this was developed, no one imagined FSX even could exist. The suggestion initiated a big laugh 'round the bong.64bit systems have an 8 Terabits limit. Our pal VS is still with us though. The split will be 4 x 4 when running 64bit programs. VS will will have 4T available to schedule to each 64bit program and 4T for the op system (However, 64bit op systems still have a 4G limit for each 32bit program). That 2nd 4T should be Plenty for Any program, right? See it coming? In 20 years, we will be doing this all again. Right now no one imagines that FSFuture even could exist. The suggestion will initiate a big laugh 'round the blackberry.This OOM threshold is like a switch. It either works 100% or bang, it stops. These is no gradual approach to the OMM CTD (the texture fragging symptom is different. That's - Physical - memory starvation). It appears the 744X was right on the edge . . . but no one really knew it. I didn't. Did anyone have a problem? The MD11 solution would have been to dumb-down the systems. I'm telling you guys, ya'll have no idea the complexity that is going on behind the scenes. The Rnav tuning logic for the FMCs PP calculations is amazing. This is the LOD that needed dum'd-down to keep it under that non-switched 32 bit threshold. If PMDG had done that, it would have Not been a PMDG airplane.If this level if realism is Not what a simmer appreciates, or can even use, there are other fine addons available. The default P51 is MY favorite plane. However my involvement with this addon is Because of this LOD. Like a good RPG, the world is limitless. There is always a new quest available. Anyone start playing with the fuel panel, or electrics? That's why. Although I agree under max stress, it'll take out hardware. I crashed it consistently with max sliders and my 2FPS beta test flights. Uber-stressed hardware can do it too at more normal settings. If your hardware runs on Aquamark, that's a laugh, try Everest. That's more of a chuckle. If it'll run on Everest, try Prime. That's next. If it runs Prime, try a KJFK - EGLL run with the MD11x with high sliders and big clouds. That'll tell the story these days.

Although I agree under max stress, it'll take out hardware. I crashed it consistently with max sliders and my 2FPS beta test flights. Uber-stressed hardware can do it too at more normal settings. If your hardware runs on Aquamark, that's a laugh, try Everest. That's more of a chuckle. If it'll run on Everest, try Prime. That's next. If it runs Prime, try a KJFK - EGLL run with the MD11x with high sliders and big clouds. That'll tell the story these days.Why then build this plane that seemingly cannot run on many a machine?

I'm not seeing that. Widespread machine problems that are not responding the these proscribed therapies appear to be few and far between, if they exist at all. Anyone that has a problem, please report in. I'll bet we can fix it. Together, we can make this work.

I suffered with this problem and it progressivley got worse.Running Vista Ult 64 on 680iMLB GF9800 and 4gb on FSX.Took a chance uninstalling my AV software (BitDefender) and the problem went away.Reinstalled BitDefender and problem is still gone.Caveat is I upgraded to 64 bit, then went up and down on my ram size.4x1gb was not stable in FSX for me. So I had a unique situation compared to others I suppose.2x2gb was very stable, however, I think BitDefender got confused in the up/down process of troubleshooting my memory.My point is, Vista seems finicky when it comes to changing things around. If all the ingredients aren't perfect between Vista and FSX and your other software, it may result in any number of symptoms.So with the big issue out of the way .... I need to figure out why the MD-11 messed up my 747... ... Still haven't found the silver bullet on that one. If anyone else has, please send me a PM.Best of luck sorting out the low-mem / OOM.

Well I'm back, but with good news on my end thus far. I've done the next installs -- Photoscenery -- and it didn't effect my sim at all. Still no OOM. Did a full round trip flight between EGLL-LSZH-EGLL at dusk, real world weather, with Horizon VFR and Switzerland pro installed. Physical memory usage was still only 60%. And I still only have 4GB installed for memory. As I add stuff, memory usage isn't budging a bit. I think the real test will be active add-ons such as ActiveSky. That's tomorrow's test project.Unless i can again reproduce an OOM, I'm not going to update here anymore. But I did notice after a fresh reinstall of FSX and carefully picking my add-on installs, everything seems to be going smooth.

>OOMs occur because of an obscure function in the operating>system that keeps a running talley of forecast ram loads. When>that forecast goes beyond a certain level (beyond a 2, 3 or 4>G threshold), bammmm, OOM. It is NoT about any physical ram>amount installed anywhere, V or main.>>Your OOMs are most likely occurring because the 3G switch is>not set in your operating system. Get that set, and you'll be>set. It's not a video card issue, nor is it an XP v Vista>issue. I don't understand how "when that forecast goes beyond a certain level (beyond a 2, 3 or 4G threshold), bammmm, OOM".... Considering I have 6GB RAM with OOM errors.... All I know is I have a descent system, am using the recommended FSX settings (PMDG Ops FSX FPS Guide), and am experiencing OOMs. I was running at lower settings, but realized what the heck... I have a good system and had been using FSX SP1 with settings below those recommeneded while still getting an OOM error. I don't run anything else in the background except security with FSX directory excluded from scanning.None of this makes any sense.-BrandonCore 2 Quad Q9550; Vista 64-bit; 6 GB RAM; 1 GB NVIDIA GeForce 9800 GT

Remember, OOMs are about the operating system's ram use forecasting function. OOMs have nothing to do with the amount of physical ram onboard. This is the software wisdom MS decided to use with its operating system. Their design makes no sense to me either, but here we are.With Vista 64 and FSX - with SP2 installed - , OOMs are very hard to induce. The 6Gs of physical ram are not helping. Even with all the switches set, any 32bit program running on a 64bit operating system will OOM at ~ 3.5Gs of physical ram load. That's because the program/op system's forecasted/projected ram usage always runs higher than the current physical ram load. It's quite the greedy forecast too. Even with Vista 64 and FSX/SP2, with the physical loaded to (only) ~ 3.5G, the forecast will be at 4G and bamm, OOM. However, this will rarely happen. I did it, but it was a science project. I had to slider-up and just let the airplane hammer along at a slideshow 2 at SPF (Seconds per frame). My rig is within 10% of anything available today. I just can't imagine anyone actually playing at a +10%, 1.8 SPF; But it is possible to bust a 32bit program running on a 64bit operating system even with all the switches set. I did it.Make sure you have SP2 installed in FSX. That sets the program's switch. Vista 64 sets the operating system's switch. That'll do it. You betcha. (Darn, wouldn't she have been a hotttie VP!?)

>for memory. As I add stuff, memory usage isn't budging a bit.> I think the real test will be active add-ons such as>ActiveSky. That's tomorrow's test project.>>Unless i can again reproduce an OOM, I'm not going to update>here anymore. But I did notice after a fresh reinstall of FSX>and carefully picking my add-on installs, everything seems to>be going smooth.Chris curious how your progress will go with ASX hope it will be a success :-)What AI are you using?In my case I don't have OOM but just memory starvation with dusk/night...Daylight flights OK but dusk / night we have a problem so it's just filling up the graphics bus...Never understood the need to load all the panel graphics in to memory via a dll/gauge in memory around 300 mb (I think here lies the problem...)Hence this the only software I have problems with lol all other stuff is smooth and fast even the heavy stuff (talking not about FSX lol) http://i5.photobucket.com/albums/y156/awf1/sign.jpg

My apologies if I am posting too soon yet again. But I want to report that I have been following-up on my theory about DX9.Last night I installed the November 2008 DX9c redistribution package. It spent a little more time copying files/ "updating" stuff than these things usually do.Then I fired up my test flight in the MD-11: an approach at dusk into EGLL from the east (ie, over the city). Once on the ground and connected to Vatsim via FSInn, I can invariably trigger a crash in the MD-11 (but not, eg, the Level-D 767X) by spending a few seconds switching between the views (using the "A" key") for each of the available viewpoints (the "S" key), then cycling the viewpoints (holding down the "S" key), and then switching to and from windowed/full screen view. But guess what? No crash - yet.I still have to add back the stuff (UTX and MyTraffic) that I lost with my system restore. Also, the "Virtual Size" of FSX reported by sysinternals was lower than usual: it was an unusually clear night last night so maybe the absence of clouds is significant. So I may well be back here again. But I suppose at least that will be one other possibility excluded ...Tim

Where is VS running? Of course, that's the OOM'er. Below its crashpoint, all is 100% A-OK. Its approach to the crashpoint won't start texture problems, or any other problem. The pre-OOM problems occur because VS is allowing physical ram to load closer to the machine's total physical ram install. There has to be some other tracking function in the op system to keep a specified amount of physical ram-room for the op system to run in actual, physical ram. I don't know that that's called, but it has to exist. (My guess is that . . . ) The texture problems occur when the op system is squeezed into a physical ram corner by the program's newly unleashed greed. I'm calling this ram starvation, for lack of a better moniker. With 2G physical ram installs and no 3G switch, VS would just shut down the whole program - Before - the program had the chance to squeeze VS's operating system buddy in to a (marginally operable, texture corrupting) physical ram corner. OOMs would occur when the program hit ~ 1.5G physical ram loads, leaving .5G for the op system. We are over-riding that failsafe function with the 3G switch. VS itself though, won't effect anything. That is, until it shuts down the program, therefore effecting everything.

> VS itself though, won't effect anything. That is, until it > shuts down the program, therefore affecting everything. That's what puzzles me and makes me now suspect something else is causing the disappearing textures. In my case, the program does not "shut down". FSX continues to work in the sense that I can use Alt + F + Close etc to exit out of it in orderly fashion. I can even call up (for example) the weather and display settings from the menu. All that goes, is the graphics. To get them back, I have to exit & restart FSX.But obviously we are all stumbling around in the dark here: I am, anyway, So again, it would be nice to hear from PMDG that this problem is at least being looked into.Tim

>>for memory. As I add stuff, memory usage isn't budging a>bit.>> I think the real test will be active add-ons such as>>ActiveSky. That's tomorrow's test project.>>>>Unless i can again reproduce an OOM, I'm not going to update>>here anymore. But I did notice after a fresh reinstall of>FSX>>and carefully picking my add-on installs, everything seems>to>>be going smooth.>>Chris curious how your progress will go with ASX hope it will>be a success :-)>>What AI are you using?>>In my case I don't have OOM but just memory starvation with>dusk/night...>>Daylight flights OK but dusk / night we have a problem so it's>just filling up the graphics bus...>Never understood the need to load all the panel graphics in to>memory via a dll/gauge in memory around 300 mb (I think here>lies the problem...)>>Hence this the only software I have problems with lol all>other stuff is smooth and fast even the heavy stuff (talking>not about FSX lol)> >http://i5.photobucket.com/albums/y156/awf1/sign.jpgI have AI set at Ultra High and currently using only default. If I have no crashes with UTX Europe, then I'll be installing my AI traffic add-on -- Ultimate Traffic by Flight1 Software.

For the 2G installs:"(My guess is that . . . ) The texture problems occur when the op system is squeezed into a physical ram corner by the program's newly unleashed greed. I'm calling this ram starvation, for lack of a better moniker. With 2G physical ram installs and no 3G switch, VS would just shut down the whole program - Before - the program had the chance to squeeze VS's operating system buddy in to a (marginally operable, texture corrupting) physical ram corner.OOMs would occur when the program hit ~ 1.5G physical ram loads, leaving .5G for the op system. We are over-riding that failsafe function with the 3G switch."

>For the 2G installs:>>"(My guess is that . . . ) The texture problems occur when the>op system is squeezed into a physical ram corner by the>program's newly unleashed greed. I'm calling this ram>starvation, for lack of a better moniker. With 2G physical ram>installs and no 3G switch, VS would just shut down the whole>program - Before - the program had the chance to squeeze VS's>operating system buddy in to a (marginally operable, texture>corrupting) physical ram corner.>>OOMs would occur when the program hit ~ 1.5G physical ram>loads, leaving .5G for the op system. We are over-riding that>failsafe function with the 3G switch."Sam I think for the most of us we are talking about 4 gb of physical ram...http://i5.photobucket.com/albums/y156/awf1/sign.jpg