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 |
44MB |
Solution loaded, no open files |
208MB |
| Solution open and 3 source files open | 212MB |
| Build solution | 231MB |
Make a small change, build again |
270MB |
| 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 |
356MB |
| 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 |
519MB |
Immediately try building again, with no changes of any kind |
590MB |
| 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 |
757MB |
| 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 |
924MB |
| Build again | 939MB |
| Remove “Dim a As String” from the previously mentioned class file | 968MB |
Build again |
976MB |
Close open files and solution, leaving VS still open |
895MB |
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.
Frank Hileman
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.
Regards,
Frank