Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I run visual studio 2010 on a 32bit system and regularly run into issues with running out of virtual memory so I can no longer do things like copy / paste in VS.

I checked out a few options and the Microsoft line on this indicated running with less extensions open, and if that didn't work, use the bcedit /set IncreaseUserVA 3072 command.

That did seem to mitigate the issue, however after about a day of use, suddenly windows starts telling me I'm out of disk space - on a drive with over 100Gb available. For instance it would stop copying a file, saying there was no space to copy it. However clicking "retry" would succeed. Lots of other programs that were writing things to disk would fall over regularly. (Including Skype...why were you writing to the disk all the time, Skype?!)

I ran chkdsk and did other basic checks before concluding that my configuration change must be responsible. Fortunately restoring the default setting worked and I'm now back in action.

Most articles (except, notably, Microsoft's) on IncreaseUserVA say "Use at your own risk", and clearly I did, and lost. But can anyone explain why this behaviour was exhibited / what can go so wrong with what appears to be a legitimate change to Windows 7 configuration?

For the record - the machine was a dell Vostro Laptop with a 260Gb / 5400rpm disk drive, 3.2Gb (effective) RAM, running Windows 7 with all updates prior to SP1.

share|improve this question
    
If things goes wrong, how can I set it back to default. By running this command bcedit /set IncreaseUserVA 2048 ?? –  Saravana Kumar Dec 11 '11 at 7:16

3 Answers 3

up vote 5 down vote accepted

Windows partitions the available 4GB of address space on a 32 bit system in half, so that the kernel get 2GB and the program gets 2GB (its virtualized so each program gets 2GB). The "bcedit /set IncreaseUserVA 3072" command changes the partitioning so that each program gets 3GB and kernel space only gets 1GB. Mostly this works fine, but as you noticed you can run into trouble. It is usually some driver that runs in kernel space that has been hard coded to assume it has 2GB of address space available that causes the problems when it attempt to use the 2GB of address space without bothering to check whether it can.

share|improve this answer
    
Thank you for that - make total sense! –  Charango Mar 7 '11 at 10:57

If you have 8 GB of RAM and need larger user address space, best solution is to install Windows 2003 server. No tweaks are required and your 32 bit apps get 4 GB of address space each. There are some drivers which don't like this and that's why MS doesn't enable this on the desktop OS. The crashes caused by having a driver which does not support this are unpredictable and hard to diagnose and are mostly in drivers that aren't used in server environment.

It's possible to modify the Vista/Win7 kernel and add that as option to the boot menu to get the same memory as is available in the 32 bit Server editions:

www.geoffchappell.com/notes/windows/license/memory.htm

There's a pre-made patch that does this stuff but I haven't tested it and there's no source to it ...

share|improve this answer
    
As mentioned, The patch is called patch2pae. A copy is found in wj32.org/wp/2010/05/04/pae-patch-updated-for-windows-7 What it does it patched the windows loader and kernel to access beyond 4GB address space through the PAE extension. –  g5thomas Oct 17 at 16:55

I've been setting IncreaseUserVa on occasions to 3g in order to get a big project to compile. I notice that if the system goes into hibernation, it becomes very unstable upon waking up. Servers typically don't hibernate, I guess.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.