I could have kicked myself last week. I was running Visual Studio 2010 in a VMWare VM, and it kept locking up – it was driving me batty. The problem started out as one of those “once every four of five hours” kind of lock ups, but it eventually got to the point where I’d open the solution and click “X” on one file, and I’d be locked up.
I tried everything. I googled the problem till the cows came home — nothing. I tried updating VMWare tools. I tried rebuilding the VM. I tried 64-bit and 32-bit. I even uninstalled VMWare Server and installed VMWare Player, thinking that the lack of Direct-X support in Server might be causing the WPF-based VS2010 some issues. No dice. Nothing worked.
Just about the time I was ready to chuck the whole works out the window, a nagging memory surfaced. Somewhere in my distant past (ok, it was three or four years ago), I remember having lock-up problems with Visual Studio 2005. I never did figure out what was causing the lock-ups, but I had a sure-fire workaround: just delete the .SUO file for the solution and re-launch.
So, having already exhausted all of my “good” ideas, I gave it a try, and just like that, I was back in business.
Wouldn’t you think that at this point, there’d be some way for Visual Studio to detect that something was pretty badly hosed in the .SUO file? Me too.
Related articles by Zemanta
- Share the same Visual Studio Settings between Team Members (devcurry.com)
- Visual Studio Not Responding (beeping) when editing ASPX (huddledmasses.org)
- FYI: Visual Studio 2010 Technical Readiness Training (huddledmasses.org)
- Microsoft patches Visual Studio error message (infoworld.com)