A Blog by Scott Isaacs

How I Got VS 2005 To Leak Up To 1GB+ Of My RAM

I’ve been working on this same project at work for several months now, and today I started having some issues.  I went to “save all” and got a message that there was insufficient storage.  Since I have nearly 20GB free on my disk I knew that wasn’t exactly right.  I looked in Task Manager and, lo and behold, devenv.exe was using over 1GB or my RAM.  I have 2GB RAM on this machine so I didn’t notice any issues with other programs while this was happening.  It was just VS.

I’m hoping someone will have some thoughts on what I might try to fix this problem.  It’s very frustrating because I have to close VS regularly and re-launch it to release this memory.

So anyway, first, a little background. 

My System Setup

I have a Dell XPS laptop, 2.?? GHz Intel, 2GB RAM, 100GB HDD.  I have Windows XP Pro, SP2.  I am running VS 2005 with SP1 that came out a few months ago.  I recently (within the last week or so), removed all of the .NET 3.0 stuff I had (framework, VS extensions, etc.), as well as ASP.NET AJAX, and reinstalled them to make sure I had the latest bits of everything.

My System Snapshot

After starting the morning with a fresh semi-weekly reboot, I started working as normal.  Currently running on my system, besides VS 2005:

  • Outlook 2003
  • SQL Server 2000, 2005 Express, and SQL Server Mgmt Studio
  • iTunes
  • Windows Live Messenger
  • Cropper
  • My RSS reader
  • Various other tiny apps and things that just run with Windows XP

The Solution

The entire solution takes roughly 150MB on disk, including resources such as images and documents, and has 9 projects (all VB.NET):

  • A client EXE
  • A Windows service
  • Two other EXEs
  • Five shared libraries (DLLs)

I have a custom build configuration that is exactly the same as the standard “Debug” build configuration, except that it does not build the service (since it is usually running).  When I want to build the service, I stop the service, switch to Debug, build, switch back to custom build configuration.

This project is not under source control through VS, so I am doing manual backups on a regular basis.  I know this is wrong on so many levels, but when I started, there was no source control server.  I have since set one up, but haven’t added the project yet.  In the meantime, I am backing up to a time-stamped folder on the network.

The Problem

So far, except for the .NET 3.0 and AJAX un/re-install, this is no different than my environment has been for the last several months.  Yet today, I was having troubles.  After I noticed the trouble for a while, I decided to close down VS and start it up again, this time keeping track of what I did and the effects on memory usage.  I did some simple documenting of my step, and took some screenshots of Task Manager.  I recorded memory usage after each step, although I failed to take screen shots at each step, so I’ve just included a few of those for kicks.  So, here goes:


Step Taken Memory Usage of devenv.exe

VS loaded, no open solutions or files

Solution loaded, no open files
Solution open and 3 source files open 212MB
Build solution 231MB
Make a small change, build again
Change build configuration to debug (so I can build my service so that it refers to the correct version of my shared libraries) 299MB
Build solution 326MB
Change back to custom build configuration
Make another small change and build again 396MB
Do something that causes several errors.  I commented out a base class, causing all inherited classes to have errors.  This ended up with ~150 various errors.  This was just so I could see what would happen if there were errors.  I didn’t really perform this step in “real life”. 420MB
Try building again with these errors present
Immediately try building again, with no changes of any kind
Fix one error.  I uncommented the Class / End Class lines that I had commented a moment before, but left the class members commented. 647MB
Try building again 672MB
Fix half the remaining errors, by uncommenting half the commented members 702MB
Try building again 723MB
Fix remaining errors 756MB
Build again
Change build configuration back to Debug so I could build my service 786MB
Build again 826MB
Change back to custom build coninguration 850MB
Build again 891MB
Add “Dim a As String” to a class file and save
Build again 939MB
Remove “Dim a As String” from the previously mentioned class file 968MB
Build again
Close open files and solution, leaving VS still open

So, what’s the deal?  Is it related to the .NET 3.0 / AJAX stuff I mentioned above?  I know some of the steps I’ve mentioned are contrived, but they’re not at all unrealistic.  The process of adding a variable declaration, building, removing it, building again shouldn’t really take up 85MB of RAM that never gets released, right?

I did a quick Google search for Visual Studio 2005 memory leaks, but didn’t find anything helpful in the first page or so, so I stopped looking hoping that someone might have a suggestion.  If anyone has any ideas, please comment on this post or e-mail me directly.  If you don’t have my e-mail address, you can use the contact form on this site.  This isn’t stopping me from working, but it’s stopping me from working effectively.


Community Server Theming Contests


So Tired

1 Comment

  1. Hello,

    Beta development software from Microsoft can be expected to be buggy. But VS 2005 is also buggy, with known problems that can slow down devenv.exe, that were not fixed in SP1.

    One is a problem with toolbox item serialization.

    Try this:

    Shut down VS, kill all devenv.exe processes.

    Delete the .suo files for the solutions (if they are very large, this is a source of delay at start up and shut down, caused by the toolbox bug). You don’t lose any important data by deleting these.

    Open your solution.

    Right click on the toolbox and select Reset. This will purge all the invisible bad toolbox items.

    Select your .exe project. Right click and open Properties. Select the Debugging tab. Uncheck the “use the visual studio hosting process” option. This is to fix some other unresolved bugs in VS 2005.

    Close your solution. Open again, clean and rebuild.

    Hope that helps.


Powered by WordPress & Theme by Anders Norén