Your computer has run out of available virtual address space. Please restart... etc.

 

So thats pretty much the limit then.. Right?

 

MAnny

 

OK.. Try moving - increasing - the swap on C: back up to 3 gig, and deleting the swap on F: This should not make any difference, but I'll eat my shorts if it works!

 

Nope.. I tried 12,000mb page file on C as well.. No go.

 

Manny

So thats pretty much the limit then.. Right?

Right. I authored the Wiki for Flightsim.com some years ago. I have no idea why the quotes from Phil Taylor are now literally blank lines now...

 

At the same time, I wrote the Wiki entry for FS Developer, which is frankly quite a bit easier to read: http://www.fsdeveloper.com/wiki/index.php?title=OOM_Error

3 gigs is way more than enough, Manny - I can load my beast to the hilt, without running out of VAS - it barely shows on the chart. There's something else going on here.

 

Couple of other basic things you might do, Manny: 1). run an sfc /scannow, from the Start-->Search button/window, and 2). a chkdsk on c:. Do this in

Safe Mode -->input CMD in the Start-->Search window, type in CHKDSK C: /f /r

then grab a movie to watch while you're waiting. Did you run a pre-boot memtest yet?

 

@Douglas Marsten: -

Is FSX large address aware, or do we need to set it up for that?

I believe the LargeAddressAware flag was set in SP2, Douglas. Prior to that it was necessary to download something like CFFExplorer to look at (and change) the header entry, then to set the /3 gig switch, with a userva of 2560. (for e.g.) This puts a modest squeeze on the OS, but gives the running app. a bit more headroom above the 2-gig limit. (Of course, my memory might be beginning to fade into the nebulous realms of Al's Heimer, so you'd better look it up.)

Why worry about the size of the page file unless you are desperately short of space in your had disk - what's a few Gb more if you've got, many times that in free space.

 

Also, don't move the page file to another disk unless that's a physically separate disk to the Windows one. If tt's only a separate partition on a conventional hard disk it will worsen performamce because of the increased seek times.

Why worry about the size of the page file unless you are desperately short of space in your had disk - what's a few Gb more if you've got, many times that in free space.

 

Also, don't move the page file to another disk unless that's a physically separate disk to the Windows one. If tt's only a separate partition on a conventional hard disk it will worsen performamce because of the increased seek times.

 

That's what I was trying to tell Paul J. His OOM's has nothing to do with physical memory or page file size or location. It's about VAS (Viural address space). Allow windows to manage page file on windows intall drive and if he has 7x64, FSX sp1 or FSX Accereration exe installed that will eliminate OOM's. Nothing else is needed. OOM's are a thing in the past for me.

That's what I was trying to tell Paul J. His OOM's has nothing to do with physical memory or page file size or location. It's about VAS (Viural address space). Allow windows to manage page file on windows intall drive and if he has 7x64, FSX sp1 or FSX Accereration exe installed that will eliminate OOM's. Nothing else is needed. OOM's are a thing in the past for me.

 

That's not was I was saying.

Manny - do you have, or can you beg or borrow another GPU with less memory on board???

 

I just looked at your specs again........GTX 670.. 2-gig.... Cheesh! That 2-gig of video ram that's on your 670.... it gets mapped into the system memory as well..............and you only have 4 gig of VAS......

 

:Thinking: Hmmm Have we fixed it?

Manny - do you have, or can you beg or borrow another GPU with less memory on board???

 

 

Hi Paul

 

I have a GTX 550 or something on my core 2 duo pc... I don't mind mind switching the video card..but the thought of removing and reinstalling the driver and going through the settings... is giving me second thoughts.

 

Moroever with the 550, I wouldn't be able to hook up 24" x 3 monitors to test this out.. Not sure having three monitors take more memory or not.

 

 

And when you say that the system maps the vram into the actual memory? what happens to folks who have 4Gigs of VRAM? Wouldn't they run out of VAS sooner?

 

Manny

I don't know how the GPU driver and the OS handle it, Manny. The hardware technology increases faster than I can follow. The only people that could give you a correct answer are people like Nick, some of the devs, like Tabs (PMDG), Uncle Bill Leaming, and Nvidia themselves - who are playing with cutting-edge every day. My background may be (is) solid DEC and Sun Unix, with earlier heavy NT+, and and then moderate MS exposure to the newer MS server OS's, but that is no help when it comes to the latest breed of GPU. However - IF - you have deleted and created the paging files correctly, there should be, or can be, no reason for "running out of memory". Very few people are getting OOM's nowadays.

 

ScottEQ -

http://www.tomshardware.com/forum/280755-33-system-memory-question

has an acceptable answer (for me), but it is a little "aged" (Sept 2010). It's a good read - about 16 posts down. I will keep searching.

 

Anyway - do try the 550, Manny - no-one else here has indicated any other possible or probable cause, so it is a necessary step in proving your existing "Monster GPU" is, or is not - the cause. Just follow the Nvidia instructions.

 

Good luck.

And when you say that the system maps the vram into the actual memory? what happens to folks who have 4Gigs of VRAM? Wouldn't they run out of VAS sooner?

Well yes they would, actually. A VAS table itself doesn't really take up much physical RAM space, because it's really only like a table of contents in a book, not the contents of the book. For a process with 64MB address space, we need one 1^st-level, 32 2^nd-level, and 32*32 3^rd-level page tables – with the total overhead of 128 + 32 * 128 + 32 * 32 * 256 = 2^7 + 2^12 + 2^18 ~ 256KB per VAS table.

 

Each program loaded will generate its own VAS table, which keeps track of where all the bits of the program are at any given time in the physical memory, so that when swapped back and forth from the page file, they are put back in precisely the same addresses...

 

FSX itself demands that anything written to the VAS table have a 1MB contiguous block of empty addresses available. It is when there are no such remaining blocks to be had that an OOM error occurs.

Thanks Bill - I knew you were going to come back with the precise information.... :LMAO:

 

This issue is - with a good-sized, spanking clean, new VAS - why is he still getting the OOM? Can it possibly be that his system+FSX+ES CitationX/NGX+AS2012+LaGuardia+TIR + the still-large gpu memory - is actually Toooo much? If so - this is almost some kind of record, and it means that we can't run FSX "fully-loaded" with a 4-gig card..no?

Thanks Bill - I knew you were going to come back with the precise information.... :LMAO:

 

This issue is - with a good-sized, spanking clean, new VAS - why is he still getting the OOM? Can it possibly be that his system+FSX+ES CitationX/NGX+AS2012+LaGuardia+TIR + the still-large gpu memory - is actually Toooo much? If so - this is almost some kind of record, and it means that we can't run FSX "fully-loaded" with a 4-gig card..no?

 

We tend to forget that video cards take address space. If you have 4GB of ram and 2GB of video ram that means you have effectively halved your system ram capacity if you are using 32bit windows. Virtual memory is also limited to 2GB per application if it's coded as 32bit which FSX is. Once FSX or any other 32bit program reaches this limit it's over. If you run a 64bit OS you can "hack" FSX (or any other 32bit program) to use up to 4GB of virtual memory which is what I have done and it does help tremendously.

Paul, most likely the proximate cause is the 2GB of vram that's simply taking up too much of the available "virtual addresses" and thus contributing to the cause of the OOM condition. One way to mitigate some of this is to ensure that as many unnecessary "services" are stopped before launching FSX, or better still never launched during the boot process to begin with...

 

Keep in mind also that every program loaded, even when minimized to the taskbar still has to have its VAS table intact and available instantly in case one Alt-Tabs to another program. While the actual VAS tables aren't terribly large, they do add up to a significant size if a large number of programs are loaded and minimized.

 

On my flightsim computer, I've trimmed the fat from the boot process and only load the bare minimum of resources. I also have only those programs that are absolutely required by the sim loaded. Every other program (such as IE) is closed.

Agreed, Bill (and Zboe). Personally I use Ken Salter's "AlacrityPC" every time FSX starts up, as I want the very best FSX experience my pc can offer, and nowadays, since Stevejp's DX10 fixes,

http://library.avsim.net/search.php?SearchTerm=DX10+shader&CatID=root it's back to tweaking for DX10! Fun!

 

Seriously - given Manny's corrective efforts I have to conclude that this is the case with these large cards, and that he has to try the 550 to verify the diagnosis. I simply anticipated that, with a 3-gig, new paging file - he would have sufficient VAS. Why wouldn't PerfMon show this? My 580 is good for 1.5 gig, and I run 100 on C and 3 g on E...... I've run PerfMon many times, and have only ever seen the smallest Usage bar showing. Hmmph.

 

Let us know how you make out Manny. Thanks for jumping in, Bill. (Sorry - "Father Bill....") (I liked the old Avartar pic) :lol:

Personally what I did was buy 16GB of RAM and make 8GB a usable ram drive and put a 6GB pagefile on there. Solved a lot of problems and it keeps my SSD drives from getting thrashed by Windows which can hurt their lifespan.