Low Virtual Memory
This message appears when Visual Studio crashes and virtual memory is low. However, this does not mean that that the virtual memory on your system is low, but rather that Visual Studio is running out of address space. Most commonly, this error occurs on machines with 32-bit operating systems, which limit Visual Studio to a 2GB address space. When working with 32-bit processes, only 4 GB of memory is addressable by the application (2^32 bits). However, on 32-bit machines, Windows reserves 2 GB of a processes virtual address space for internal purposes (for example, for working with the machine’s graphics card or other system drivers). This leaves 2 GB available for the 32-bit process to use for internal purposes. By setting the /3GB switch, users are telling Windows to change the default allocation for a process so that only 1 GB is reserved for Windows, and 3GB is given to the process. In most machine configurations, reserving only 1 GB does not impact the performance on the machine.
On 64-bit systems, the low virtual memory error is rare because all 4 GB of addressable space can be given to the process, and Windows can use 64-bit memory addresses for working with the hardware and system drivers. However, there are some data sets that when processed by Visual Studio, can cause memory utilization to exceed even the 3GB or even 4GB thresholds. For more information, see Visual Studio: Why is there no 64 bit version? (yet).
This error typically occurs in situations where Visual Studio is caching large amounts of data, or when running multiple memory-intensive processes.
The following scenarios involve caching large amounts of data, and can usually be fixed by a simple restart of Visual Studio.
Running Visual Studio for the first time after install.
Installing or uninstalling an extension.
Choosing or customizing toolbox items.
Changing your Visual Studio settings.
Allowing the system to go into sleep (hybernate) mode while Visual Studio is open.
The following scenarios require large amounts of active memory. In these cases you are advised to run Visual Studio with only essential components open, or run additional processes in a second instance of Visual Studio.
Building large solutions.
Working with large XML documents.
Upgrading solutions from a previous version of Visual Studio.
Retargeting solutions.
Running Team Explorer while editing code.
Running IntelliTrace on multiple projects.
If these measures are not sufficient to prevent the error, you can increase your available address space on a , or later system by running bcedit.exe with the following syntax:
bcdedit /set IncreaseUserVa 3072
This increases your user-mode virtual memory allocation from 2GB to 3GB on an x86-based system. Adding the /3GB switch allows the entire system to address more memory and gives each application a greater percentage of the available memory.
Note |
|---|
bcdedit.exe must be run as Administrator. If your system has BitLocker encryption enabled, you must first suspend Bitlocker, then make the change, reboot, and re-enable Bitlocker. |
Although you have now increased you virtual memory allocation to 3GB, you might continue to receive this error because there’s still a 2GB VM cap on any single application. If you continue to encounter this error, reduce the size of your solution by either refactoring the solution to remove projects that are infrequently used or unload projects that aren’t needed and then restart Visual Studio. Similarly, if the error occurs when building your solution, try building from the command line.
- 4/23/2012
- Sergiu Dudnic
- 2/28/2012
- Tadeusz
My system is VS2010 Ultimate + Win7 Enterprise. 32bit. Ram 3G with Q6600 (pretty old CPU but not an issue).
- 12/8/2011
- YoungjaeKim
Memory usage by VS increased drastically to more than 1.4 Gb of memory.
- 8/15/2011
- Xipho
- 7/10/2011
- NVDPassie for CS
- 5/25/2011
- TekzMekz
We didn't have it with VS2008: our machines all have 4gB of RAM and it wasn't a problem.
- 3/25/2011
- SteveClay
- 3/23/2011
- TuckerBlue
- 1/19/2011
- rohancragg
Note