9
votes

The Visual Studio devenv.exe process is 32-bit (even when run on a 64-bit OS), so it can't use more than 4GB of virtual memory.

Unfortunately, when I am debugging my C++ application with Visual Studio I frequently run out of memory due to this 4GB limit. For example, using VMMap, below shows progression of my typical Visual Studio usage over a few hours leading to a crash.

How can I get Visual Studio to use less memory so I stop wasting time with it crashing?

Is it typical for Visual Studio to use more than 3.5 GB virtual address space?

I am using Visual Studio 2012, but I assume this problem spans different VS versions, since Visual Studio 2015 still doesn't have a 64-bit version.

(Note that VMMap reports “Free” as the remaining memory in the address space, up to 4GB for 32 bit processes, and 8TB for 64 bit processes on Windows.)

enter image description hereenter image description hereenter image description hereenter image description hereenter image description hereenter image description hereenter image description here


Things I've already tried:

  • starting in safe mode
  • removing all plugins and extensions so that nothing shows in Tools > Add-in Manager nor Tools > Extensions (https://github.com/tsasioglu/Total-Uninstaller is helpful for this)
  • deleting my .suo/.sdf files
  • deleting my AppData/*/Microsoft/VisualStudio folders
  • using Funnel and filtering out all but 3 projects
  • removed all my "Symbol file (.pdb) locations" selections and chose "Automatically load symbols for: " "Only specified modules"
  • selected "Enable Just My Code" for debugging
  • disabling Intellisense (Tools -> Options -> Text Editor -> C/C++ -> Advanced -> Disable IntelliSense)
1
What Add-Ons, Extensions or Plug Ins are you running. I used to have the same problem until I uninstalled all Plug Ins. Now it rarely causes trouble.Grantly
Do you really need all 167 projects to be loaded? If not, try the "Funnel" extension: visualstudiogallery.msdn.microsoft.com/…Blorgbeard
VS can certainly use a lot a VM, especially with your large number of projects. Try removing all extensions. Also, make sure your machine has 8GB of RAM, so VS is not fighting with the OS for RAM. And an SSD might help with restarting. Your screenshots show that you're using Win7, good that it's not XP. You should use perfmon and windows' performance counters instead.Chris O
@ChrisO I already removed all extensions, I have 32 GB of RAM and a SSD. What relevant information would perfmon and performance-counters provide that VMMap doesn't provide?JDiMatteo
@JDiMatteo, sorry just noticed your question. The Committed amount shown in VMMap is the most important counter for a 32-bit process. So my mistake, VMMap is already showing the relevant information (was thinking of Task Manager for some reason). As you've already determined, the app gets unstable the closer you get to 3.8GB total Committed. Another option is to attach an empty instance of VS to your running app to be debugged. That way the "large" solution won't be loaded, and you can still get the full debugging experience.Chris O

1 Answers

6
votes

It is possible to reliably get Visual Studio to stay within it's 4GB of virtual memory, but you might have to experiment with one or more of the following strategies while measuring devenv.exe memory usage with VMMap:

  1. remove plugins and extensions from Tools > Add-in Manager and Tools > Extensions (https://github.com/tsasioglu/Total-Uninstaller might be helpful) and/or run in Safe Mode
  2. periodically (e.g. monthly) delete your .sdf and .suo files (while Visual Studio is closed) so they can be recreated (instead of deleting, consider just renaming in case you decide you want them back, as you may loose some configuration settings)
  3. If you are loading a lot of symbols (you can count "Symbols loaded" in the VS Output window), you can disable this with Tools > Options > Debugging > Symbols: "Only specified modules", then click "Specify modules" and uncheck "Always load symbols located next to modules". You can load additional symbols while debugging with Debug > Windows > Modules.
  4. Unload projects from large solutions with Funnel or Solution Folders
  5. If all else fails, run two different Visual Studio instances: the first has the large solution loaded but is not used to debug (e.g. Debug > Start without Debugging), and the second has no solution loaded but is attached to the running process for debugging. (Thanks ChrisO for this suggestion.)
  6. If you really can't get Visual Studio to work, try WinDbg which is used by Microsoft developers and is 64-bit (unlike Visual Studio).

I have observed disabling most symbol loading reducing devenv memory usage by 1.7 GB and deleting my .suo and .sdf file reducing memory usage by an additional 600 MB. This reduction in memory usage made Visual Studio go from crashing multiple times a day to running stable with the same instance running for multiple days, sometimes weeks.

In addition to reducing memory usage, these strategies will likely significantly speed up Visual Studio.