On my pc I only have those freezes if I :- switch several times between windowed mode and fullscreen With FSX just fired up I can do this 4-5 times before the grey screen appears, but when already flying for 30+ minutes it happens either immediately or the second time I switch from one screen mode to the other. I have Hattrack and when using it I can only go from Windowed mode to Fullscreen and not back, because then the grey screen appears immediately.My workaround is starting up FSX in Windowed mode on the middle screen. Then start Hattrack and than I switch to Fullscreen. When trying to Save a flight while already flying for an hour, I first Pause the sim and let it stay that way for allmost1 minute. Than I Save the Flight.Doing it quicker sometimes also cause a grey screen. Summary : I think it has to do with the load that is being put on the pc. Using Pause as I do loosens the stress on the system a bit.

Geoff,Does having a non windows managed swap file make any difference ? I have 8GB ram, have set page file at 3172. Have not experienced OOM's but still does not mean I won't get one.Just wondering if setting your swap file instead of windows managing it would decrease the likley hood of fragmentation, and improve memory management. Your thought's ? Cheers

Good question !!! The easy way is to TRY it , and see what works best (for FSX )

Ok, thanks Geoff.

In one test, i was able to cure the freezes by reducing the size of the textures, and in a second test i got rid of it by removing a dll from another addon from dll.xml.. there is some precedent that theres more of a connection than memory being involved there, but i dont truly have a real clue. If it continues for you, simply remove a DLL from DLL.xml and try again..Pam

I think you are on to something there.You don't have to delete the entry from the dll.xml file to stop it from loading. All you need to do is set Manual Load to True. Then it will ask you on FSX startup if you want to load it. This way you can turn it off when running the NGX, and on when you use the LDS-767 (or other addon) without having to modify the file all the time. I've been trying a specific flight plan KJFK to KTPA (Flytampa) all week, about 20 flights now. It has failed each time with a panel freeze, and a OOM shortly after (Sometimes preceeded by graphic corruption). I just tried this solution, and was able to fly this flight for the first time error free Gate to Gate. No freeze, and no OMM. The only anomaly was I had very few AI (2) aircraft at KTPA on arrival (Ut2 traffic.) I can live with that!! This lends credence that it is a memory issue, as each one of these DLL's takeup memory when loaded, leaving less for the NGX to work with. You can probably do the same with the exe.xml for addons you aren't currently using.

they also make use of Simconnect, And therein lay the one suspect that keeps me from saying its a memory problem. But yeah. i completely spaced that you could just turn off auto load on the dlls. All of my test flights are done between ksfo and klax. Both are default scenery on my machine so i can eliminate anything that isnt the airplane or the files pertaining to the airplane.. Even if it were a memory problem, its not me running out of memory. I have 8 gigs which i monitor very closely during testing. The most memory that fsx has ever accessed is 1.75 gigs, and yes, that was with the ngx, but that still leaves 1.25 gigabytes free for fsx to use. Thats why I'm looking at other things. Bad memory management conflicting dll's.. the whole spectrum. Perhaps one of those other dlls leaves a piece of itself behind in memory when its unloaded and when the ngx goes to write to that memory address, theres a collision. The only way to test that is to start fsx with nothing being loaded except the ngx and then try to reproduce the problem. My guess is that it wont. i very highly suspect poorly written dlls that dont get cleared from memory when they are no longer needed or simconnect misbehaving which it is notorious for doing.. Of course, thats a guess..

they also make use of Simconnect, And therein lay the one suspect that keeps me from saying its a memory problem. But yeah. i completely spaced that you could just turn off auto load on the dlls. All of my test flights are done between ksfo and klax. Both are default scenery on my machine so i can eliminate anything that isnt the airplane or the files pertaining to the airplane.. Even if it were a memory problem, its not me running out of memory. I have 8 gigs which i monitor very closely during testing. The most memory that fsx has ever accessed is 1.75 gigs, and yes, that was with the ngx, but that still leaves 1.25 gigabytes free for fsx to use. Thats why I'm looking at other things. Bad memory management conflicting dll's.. the whole spectrum. Perhaps one of those other dlls leaves a piece of itself behind in memory when its unloaded and when the ngx goes to write to that memory address, theres a collision. The only way to test that is to start fsx with nothing being loaded except the ngx and then try to reproduce the problem. My guess is that it wont. i very highly suspect poorly written dlls that dont get cleared from memory when they are no longer needed or simconnect misbehaving which it is notorious for doing.. Of course, thats a guess..

No it's not you, FSX is still a 32bit application, whether it runs on a 32bit OS or a 64bit OS. That means it's still limited in Virtual Address Space of 4GB. despite the 8GB physical memory you have on your PC. In that space FSX, your video memory, and whatever the OS needs. This means space has to be allocated for FSX. Normally on a 32bit OS an application is limited to 2GB VAS, exceed that and OOM! There is a boot option though to allow the use of 3GB VAS, Remember the video memory, and system has to fit in the last Gig. Usually this is enough for a 256MB video card. So there is another flag to adjust the size of the VAS allocated to applications. Setting it to 2816, allows use of 512MB cards, 2560 for 768MB, and 2306 for 1GB cards. 64 bit OS/s have this limitation as well but I don't think it has these options, rather it manages it internally. With so many of us using large video cards with 1GB or more, this leaves less space for FSX to run in. I have a GTX460 1 GB card, If I set my USERVA to 2306, FSX OOMs on load, 2560 I could last a few more minutes. 2816 seems to be where I can run this from origin to destination with the NGX (Well close to it) This though means I am encroaching on space allocated normally for other purpose. This usually doesn't cause me a problem, as FSX doesn't use the full 1GB video memory. If though it did use more, it's likely I could overwrite memory, cause graphic corruption a CTD or OOM. Which might explain the corruption I see shortly before the OOM.

It might.. i dont ever set those values.. Communication being my weakest point, i guess i messed up. I assign fsx 3 gigs in my head. theres 8 on the machine so video, system and whatever are all running somewhere in that extra five gigs that fsx doesnt have assigned in my head. But if fsx is only using 1.7 gig then theres still 1.3 gig left for it to access, whioe everything else is still up in that untouched 5 gig somewhere.. this last flight, fsx used upwards of 2.43 gigs. The beauty of SLI and 520 extra processing cores and cuda.Now my problem is, I cant make the plane fail when i need it too.. I've been trying to collect data for Ryan and the team here to use, but if i cant make it fail, theres no data.. I'm useless..

I think this is definitely the solution I ran all flights before that I have been unsuccessful with a freeze and/or OOM, and have completed them error free. after not loading unused aircraft DLL's, especially the other PMDG dll's for the 747-400 and MD-11 and memory usage, has gone down from a 1.8GB to 1.5GB. Commit size is also down, from 2.1GB to 1.6GB. This gives the room necessary for the NGX to run. I'm running a long range flight now, (KBOS to KLAX) just another hour to go and no problems so far!

I think this is definitely the solution I ran all flights before that I have been unsuccessful with a freeze and/or OOM, and have completed them error free. after not loading unused aircraft DLL's, especially the other PMDG dll's for the 747-400 and MD-11 and memory usage, has gone down from a 1.8GB to 1.5GB. Commit size is also down, from 2.1GB to 1.6GB. This gives the room necessary for the NGX to run. I'm running a long range flight now, (KBOS to KLAX) just another hour to go and no problems so far!

This flight completed, without incident. So far since doing this, I haven't seen a panel freeze, or OOM since.

No it's not you, FSX is still a 32bit application, whether it runs on a 32bit OS or a 64bit OS. That means it's still limited in Virtual Address Space of 4GB. despite the 8GB physical memory you have on your PC. In that space FSX, your video memory, and whatever the OS needs. This means space has to be allocated for FSX. Normally on a 32bit OS an application is limited to 2GB VAS, exceed that and OOM! There is a boot option though to allow the use of 3GB VAS, Remember the video memory, and system has to fit in the last Gig. Usually this is enough for a 256MB video card. So there is another flag to adjust the size of the VAS allocated to applications. Setting it to 2816, allows use of 512MB cards, 2560 for 768MB, and 2306 for 1GB cards. 64 bit OS/s have this limitation as well but I don't think it has these options, rather it manages it internally. With so many of us using large video cards with 1GB or more, this leaves less space for FSX to run in. I have a GTX460 1 GB card, If I set my USERVA to 2306, FSX OOMs on load, 2560 I could last a few more minutes. 2816 seems to be where I can run this from origin to destination with the NGX (Well close to it) This though means I am encroaching on space allocated normally for other purpose. This usually doesn't cause me a problem, as FSX doesn't use the full 1GB video memory. If though it did use more, it's likely I could overwrite memory, cause graphic corruption a CTD or OOM. Which might explain the corruption I see shortly before the OOM.

There's more to it than that too actually - the VAS has to be contiguous - we believe it's possible to get an OOM at really low working set values because of memory fragmentation as well. FSX is just really starting to show its age here unfortunately - we need a 64-bit sim.

There's more to it than that too actually - the VAS has to be contiguous - we believe it's possible to get an OOM at really low working set values because of memory fragmentation as well. FSX is just really starting to show its age here unfortunately - we need a 64-bit sim.

IDEA: PMDG Flight Simulator. Now THAT would be good.