This solved all my OOM problems:

 

http://support.microsoft.com/kb/947246

 

Omni. I think you may have the answer to all my problems.

 

Manny

It is just that some of the info you gave was just not true. Yes I agree Husman Khan had his own seperate issues with limited HDD space. You started telling other users (FSXMan for example) that a larger HDD will fix their OOM errors when this is just not true.

Actually, the exhausted VAS issue is only applicable to the error message that comes up when eventually FSX crashes with the "You are out of available memory" message (which really should have been worded better!).

 

If one gets that error message while FSX is trying to load, that's another problem entirely, and indeed too small a hard drive, too small of a page file, or excessive fragmentation can be the proximate causes. Sometimes it is a combination of factors.

 

This solved all my OOM problems:

 

http://support.microsoft.com/kb/947246

Well, it certainly has helped eliminate Max9 from crashing on me with "out of memory" problems!

RCITGuy, the OOM errors in FSX have NOTHING to do with swap file or physcial ram...

 

There is another source of OOM on Windows caused by exceeding the Commit Limit. It gives a "Virtual Memory Minimum too Low" message.

 

The Commit Limit is the total of RAM plus all the page files on the system. Committed memory is the total amount of memory used/committed by the operating system and all processes running on the computer. It can be avoided by increasing the size of the page file(s).

 

Windows 7 Task Manager performance pane shows two numbers against Commit (MB). The first is the Committed Memory and the second the Commit Limi.t.

Hot damn, there may be something in that fix Omni suggested, although at first it doesn't seem like that at all when reading the related MS support ticket. Still, desktop heaps have everyhting to do with virtual address spaces, especially session view space, which values we just brought up in the fix: increasing session view space, we should decrease usage of VAS (and possibly windows is able to clean it up properly after that operation).

 

I tested this with P3D. Loaded default flight, then changed airport to different location and finally went to windowed and fullscreen mode a couple of times. Usually at this time my FSUIPC is bananas and clinging the warning of exhausting VAS and every time VAS just increases till the sim (FSX or P3D) crashes. But now nothing. My VAS was about 3.3 gigs, which is far from dared 4GB. I finally switched to another more demanding aircraft and switched again to windowed mode and back a couple of times and finally I got VAS to 3.9 Gigs and clingig sound started. But - when I switched back to fullscreen, VAS usage lowered again some 200-300MB and crash threat went away, which I never remember being happened before. It seemed that this time Windows was able to dump some s*** away and free up some VAS.

 

I don't know if this completely cures the problem or just alleviates it, but to me it seems to make a huge difference. There's no harm in trying. I will test this for the coming evenings more and try to find more info about all the 'heap' and 'stack' things of windows 7, because there may be some new stuff to find out. I know something about them, but not enough to head to right direction.

Just out of curiosity, which value are you changing? I have x64 and of course the second value is 20480.

 

 

 

SharedSection=1024,3072,512 ME: SharedSection=1024,20480,1024

 

Note By default, the second value for the SharedSection entry is 3072 in an x86-based version of Windows Vista. By default, this second value for this entry is 20480 in an x64-based version of Windows Vista.

 

We do not recommend that you set a value that is over 20480 KB for the second SharedSection value.

got VAS to 3.9 Gigs and clingig sound started

 

What are you talking about here, please?

 

What are you talking about here, please?

FSUIPC warning of VAS exhaustion.

 

Just out of curiosity, which value are you changing? I have x64 and of course the second value is 20480.

 

 

 

SharedSection=1024,3072,512 ME: SharedSection=1024,20480,1024

 

Note By default, the second value for the SharedSection entry is 3072 in an x86-based version of Windows Vista. By default, this second value for this entry is 20480 in an x64-based version of Windows Vista.

 

We do not recommend that you set a value that is over 20480 KB for the second SharedSection value.

 

My last value was 768 and I set that to 1024 as per MS support instruction.

FSUIPC warning of VAS exhaustion

 

Ah OK, never found it because it is only in the INI. And it is active, but I haven't had OOM for such a long time, so I probably never heard it... OK, lemme try incude an OOM ;-)

OK, I can confirm that this MS fix did something. Usually I would OOM after: loading KSEA with ORBX PNW with PMDG 747, then switching to NGX with McPhat textures and paning around in and out of the cockpit. That would push me straight up above 4GB and OOM. But now, I was happily paning around at 4050,000K, even up to 4070,000K, and system didn't OOM. The I loaded the LDS with McPhat, still no OOM, but the skeleton textures didn't load. Then I ended the flight with ESC, and the memory message appeared. I guess I'll leave this fix on the system.

 

But... I did not hear any dingdingding.

This is very exciting.

 

May i ask, what settings did You have before, and to what did You change them to Word Not Allowed?

 

- I ask because with my new machine, specs roughly like Yours, I´m getting OOM´s because

the new Build easily let me crank the graphics up very high without FPS penalty.

So i´m keen to try this.

 

Kind regards!

// Henrik owenius @ HMR VOR

Thanks Grunt. I must have changed that value a long time ago for other reasons than FSX. If I recall, IBM recommended changing it for a reason. I see MS states fix if you have a lot of programs running. Probably explains why I never see an OOM. Dedicated computer and the only program running is FSX. I found that to be the most reliable and stable setup yrs ago..

Yes, very good news indeed.

 

All this constructive discussion has been GREAT and this would be EPIC if the said fix above fixed the OOM issues (the address space issues as it should be called to save confusion)

Also determined there are various types of OOM and MS just lumped them into one error message?? OUT OF MEMORY.

 

-Still will get folks coming saying I have error. Out Of Memory so I bought more ram and it still happens.

Far less likely to bother in future.

 

Please don't feel that way. Your always going to get a few negative comments, but honest constructive help is always appreciated by the majority.

You have made me aware that I have to have and keep at least 50% free space on my harddrive that has FSX. I never realized that before. I am thinking, in the future, of doing a setup like you have with two large SSD connected in tandem to use like one harddrive. How is that setup?

I did a quick test with Omni's fix. I was monitoring the VAS consumed and the memory contiguity and I noticed my issue for OOM was not lack of contiguous memory. Its just consumption of VAS (due to many addons) and once consumed, the VAS does not reduce much even if I leave the area. Once I reach 3.9Gig, FSUIPC dings (I thought that was win 7 feature.. LOL ) and then at 4.0gig, FSX fails with that out of memory popup.

 

After this fix, I realized the VAS consumed was smaller than what it used to without this fix.

 

I couldn't test this more since I had to run to the airport. I plan to test this somemore this weekend.

 

I am so excited. Man, I knew something was wrong..because I never got OOM with my Win xp system with its 3g/ switch. I used to have tons of scenery addons with that system too.

 

Manny