About the author

Steven Harmansteven harman :: makes sweet software with computers!

For recent posts and more about me, scroll to the bottom.

Sponsors

Subscribe

  • Subscribe to my feed. via RSS
  • Subscribe via email via email

Hacking Visual Studio to Use More Than 2Gigabytes of Memory

Visual Studio can be a tremendous resource hog, especially if you have a large solution and you're using a productivity add-in or two.

On my current project we're running VS 2008, we've got just under 20 projects in the solution, and several of us are using the ReSharper 4.0 EAP nightly builds to enhance our dev-fu. And you know what... we're restarting VS at least a half dozen times a day to work around a nasty exception we regularly encounter while trying to compile:

Not enough storage is available to complete this operation.

Not enough storage...?

Yep - storage. But you should read storage to mean memory... RAM that is.

After running for a while the Visual Studio process (found under devenv.exe in process explorer) maxes out its available memory and the above exception is thrown. The only way to reclaim the memory and successfully compile the solution is to restart the process. Bummer!

Maybe we should just upgrade our hardware, right?

I mean, with cost of processor cycles and RAM falling as fast as gas prices are rising, why not just spend a few bucks and make sure we're all running multi-core boxes with 4+ Gigabytes of memory and storage space to burn. Well guess what... we are.

All of the developers are running nice beefy machines with lots of RAM, super-fast processors, and we even have nice 21" wide screen DVI monitors. So this ain't no hardware problem.

Its a software problem.

I will admit, we are running a mix of 32-bit operating systems - mostly Vista with a handful of XP machines mixed in for the devs that roll that way. And Jeff Atwood has covered the missing RAM problem before, but even switching to a 64-bit OS wouldn't solve our problem. At least not entirely.

The problem is with Visual Studio. Being a 32-bit application its limited to just 2GB of virtual memory, even if its running in a 64-bit OS. At least, its limited to 2GB by default... but we can hack around change that.

The hack... err, solution.

Gimme 3GB!The first thing to do is tell the OS to increase the amount user-mode memory from 2GB to 3GB. If you're running a 64-bit you can skip this step.

  • for Windows XP: Backup the boot.ini file and then put the /3GB switch in your boot.ini. (more information on the /3GB option)
  • for Vista: run the following from the Visual Studio command prompt (Brad Rutkowski has the full scoop):
       1:  BCDEDIT /Set IncreaseUserVa 3072

Then we have make Visual Studio large address aware.

  1. Be sure to backup devenv.exe
  2. Using the Visual Studio command prompt, navigate to C:\Program Files\Microsoft Visual Studio 9\Common7\IDE\
  3. execute the following command:
       1:  editbin /LARGEADDRESSAWARE devenv.exe

Finally we'll use the old Microsoft-fix-all - reboot the machine. Bounce that box!

Look at all that memory!

More memory, FTW! At this point Visual Studio should be allowed to consume up to 3GB of memory before throwing that ugly out of memory exception.

Just to show you I'm not lying, I grabbed a screen shot of my process explorer with devenv.exe process chewing up more than 2.5GB of memory. Sweet!

Note: even with our large solution and running the early, and memory-hungry, ReSharper bits, Visual Studio typically stays around or just above the 2GB mark. However it can spike up to 2.5+ GB while compiling, as show in this screen shot.

kick it on DotNetKicks.com

Technorati Tags: , , ,

What others are saying.

# Hacking Visual Studio to Use More Than 2Gigabytes of Memory
Gravatar DotNetKicks.com
Apr 29, 2008
You've been kicked (a good thing) - Trackback from DotNetKicks.com
# re: Hacking Visual Studio to Use More Than 2Gigabytes of Memory
Gravatar Damien Guard
Apr 30, 2008
I wonder if the editbin /LARGEADDRESSAWARE devenv.exe will also achieve the same result on Windows 2008 Server 32-bit without the /3GB switch (using PAE).

Will try it tonight!

[)amien
# Possible reason behind
Gravatar Leonid Shalupov
Apr 30, 2008
Another explanation of out of memory - address space fragmentation. We wrote the patch that keeps it to reasonable numbers.
# Possible reason behind (2)
Gravatar Leonid Shalupov
Apr 30, 2008
That's the correct link to fix:
www.jetbrains.net/.../OutOfMemoryException%2BFix
# Possible reason behind (2)
Gravatar Leonid Shalupov
Apr 30, 2008
That's the correct link to fix:
www.jetbrains.net/.../OutOfMemoryException%2BFix
# re: Hacking Visual Studio to Use More Than 2Gigabytes of Memory
Gravatar Simone
Apr 30, 2008
I wish I had more then 2GB of RAM on my laptop :)
# re: Hacking Visual Studio to Use More Than 2Gigabytes of Memory
Gravatar Steven Harman
Apr 30, 2008
@Damien, I think the PAE switch is a different beast that is meant to split up the your memory into a number of pages, thus allowing you to access more than 4GB of RAM... or in some cases just allowing you to actually use the full 4GB of physical memory installed in a 32-bit box. But, I've been wrong before.

Let me know how it turns out as I'll probably move to Server 2008 for my development environment when I finally order that MBP (this summer).
# re: Hacking Visual Studio to Use More Than 2Gigabytes of Memory
Gravatar Steven Harman
Apr 30, 2008
@Leonid, thanks for the heads up on the memory address space fragmentation - I'll give the wrapper a try and see if it makes any difference.
# re: Hacking Visual Studio to Use More Than 2Gigabytes of Memory
Gravatar Valued Customer
Apr 30, 2008
A 64-bit version of Windows will give you even more! A LARGEADDRESSAWARE app gets the full 4GB of address space. msdn.microsoft.com/en-us/library/aa384274.aspx
# re: Hacking Visual Studio to Use More Than 2Gigabytes of Memory
Gravatar Damien Guard
Apr 30, 2008
A 64-bit version of Windows will also consume more memory as every pointer is twice the size and also introduce you to the world of compatibility problems (32-bit vs 64-bit extensions for Windows and Internet Explorer with two versions of each), and the inability to run Windows 16-bit or DOS apps...

[)amien
# re: Hacking Visual Studio to Use More Than 2Gigabytes of Memory
Gravatar Valued Customer
Apr 30, 2008
Don't knock the 64-bit till you try it - took the plunge 6 months ago and I'll never look back. I've actually had *lower* memory usage on the devenv process with memory-hungry add-ins (CodeRush) running on 64 (to the tune of ~50MB). IE's a non-issue; you'll get the 32-bit version as the default; plugins run fine. All my 32-bit apps and dev tools I have thrown at it run with zero issues; I've only gotten stuck by one app that had a 16-bit installer, but that's easily mitigated by a VM. As for 16-bit DOS apps... DOSBox! Or, again, a VM.
# Visual Studio Links #23
Gravatar Visual Studio Hacks
May 02, 2008
My latest in a series of the weekly, or more often, summary of interesting links I come across related to Visual Studio. Jamie Cansdale announced the availability of TestDriven.Net 2.13 , which includes support for NUnit 2.4.7. Visual Studio 2008 KB: List of changes and fixed issues for Visual Studio... (read more)
# re: Hacking Visual Studio to Use More Than 2Gigabytes of Memory
Gravatar Matt Casto
May 08, 2008
Great post! You're the awesomest!
# re: Hacking Visual Studio to Use More Than 2Gigabytes of Memory
Gravatar Jim Holmes
May 14, 2008
Tweaking the OSes memory usage is something to be done carefully and with some forethought. While it's solving this problem in this instance, you may be causing subtle problems in the rest of your system.

I'm not saying don't do it; I'm saying understand the cons of telling a carefully crafted OS that you're really smarter than it about how it should use its resources.
# re: Hacking Visual Studio to Use More Than 2Gigabytes of Memory
Gravatar Steven Harman
May 14, 2008
@Jim, I agree that we need to be careful when tweaking the OS, but that's pretty true for pretty much any customization we do to our PCs. So I guess the warning was implied... or at least assumed to be well understood. :)

Besides, by our very nature we're going to want to turn some dials and flip some switches... we're geeks after all. However, unlike many of the other customizations and tweaks I've made to my machines over the years, at least this one is documented and pretty well understood.

Remember, all we are doing (w.r.t. the OS) is telling it to partition up to 3GB of RAM to user processes and just 1GB to the kernel. And for typical desktop/workstation use that is totally acceptable as we don't often have tons of memory intensive, kernel-level process running - like you might on a server.

At any rate, I've been running with this hack on my workstation at the office and at home for a few weeks now with no adverse effects. But of course, YMMV.
# ¿Problemas de memoria? Pues no me acuerdo....
¿ En alguna ocasión habéis tenido problemas con Visual Studio en cuanto al uso de memoria se refiere
# re: Hacking Visual Studio to Use More Than 2Gigabytes of Memory
Gravatar Travis Johnson
Jun 24, 2008
I couple of cautions on this one. If you run 3 1600x1200 screens you will most likely run into problems like I did. Even with 2 I was still getting strange video issues. Obviously there was not enough kernal address space for the vid cards. I would start with the Resharper wrapper first. Mine is a VS 2005 solution running on XP Pro which has 21 projects and 9 websites along with CodeRush and Refactor Pro. If I try to load this solution up without using the wrapper VS heads up to 800MB of RAM and starts to wonk out and eventually crash in no time. With the wrapper it has been rock solid sitting around 500MB.
Comments have been closed on this topic.