Xap packaging failed. Exception of type 'System.OutOfMemoryException' was thrown
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.
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.inifile and then put the /3GB switch in yourboot.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
Note:
the boot.ini is a hidden file at the root of c:. You have to go into explorer/tools/options and set view to include system and hidden files. Now you will be able to see it.
You can also go to Run and type "edit c:\boot.ini".
Then we have make Visual Studio large address aware.
- Be sure to backup
devenv.exe - Using the Visual Studio command prompt, navigate to
C:\Program Files\Microsoft Visual Studio 9\Common7\IDE\ - 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!
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.
Notes: We also need to avoid binding errors in runtime.