Visual Studio 2005 SP1: Better News

The short story is that my installation of Visual Studio 2005 now starts up normally. The longer and more interesting story is how we fixed it, and how you could fix your own installation at need.

You’ll recall from January 5th that after installing Service Pack 1 for Visual Studio 2005 that I suddenly experienced excruciatingly long Visual Studio startup times. I said over a minute: the log said it was actually about 3 minutes.

Note to self: to get a Visual Studio startup log, enter “devenv /Log ” into your Windows Start/Run dialog. If you don’t specify the logfile location, it will be created in %USERPROFILE%Application DataMicrosoftVisual Studio8.0ActivityLog.xml.

Two members of the Visual Studio core team helped me out: Neil Enns, a Lead Program Manager, and Craig Skibo, a Software Design Engineer. I expected to have to gather a bunch of registry hives and file directories for their diagnosis, but Craig felt that he could find out what was going on more quickly if he were able to debug the problem himself. So the next step was to figure out how to give him access to my computer. Neil and I worked on that together, as Craig was working to deadline on a new feature.

The computer is on my office private network, behind a D-Link router/wireless router/firewall, which is connected to the Internet through a cable modem. Windows Remote Assistance didn’t initially work, because the computer’s 192.168.x.x IP address was unreachable. That was expected, but it was worth a try.

My next thought was to use Remote Assistance over a VPN, initiated from Microsoft Office Communicator 2005. It took the better part of an hour to set that up, but it didn’t work, either.

Then we tried to establish a Remote Desktop Connection with the VPN in place. Neil could get to the log-in screen, but he couldn’t complete the log-in successfully.

I was able to establish a Remote Desktop Connection successfully from another computer on my network, so I suspected that there might be a port being blocked by the D-Link firewall. Once I thought about that awhile, I realized that I could set up a virtual server on the firewall, and avoid the need for the VPN altogether.

Note to self: the WAN address of a D-Link router is found on its Status/Device Info screen. The IP address of a Windows computer can be found by running the “ipconfig” command from a console window. You can set up a virtual server on a D-Link router from its Advanced/Virtual Server screen. The port you need to map for Remote Desktop (i.e. to establish a virtual Terminal Server) is TCP/3389.

Once I did that, Neil was able to log in to the computer remotely. Once Craig freed up long enough to work on this, he was able to log in. He was able to speed up Visual Studio’s loading dramatically by disabling Add-ins.

Note to self: to disable Visual Studio Add-ins, go to Tools|Options, Environment, Add-in/Macro Security, and unselect the checkboxes.

Then Craig poked around in the registry under HKEY_LOCAL_MACHINESOFTWAREMicrosoftVisualStudio8.0Packages, and discovered that the Add-in we’d suspected all along was still in there, even though I had previously uninstalled it. He went back to the Add-in/Macro Security dialog in Visual Studio, and checked the paths listed there: he found the badly behaved Add-in’s files, renamed the Add-in’s extension, re-enabled Add-ins, and restarted Visual Studio. It worked fine.

At that point, my problem was solved, and Craig knew who to talk to at the vendor responsible for the misbehaving Add-in. I went back and deleted the Add-in’s remaining files and registry entries, and had my Visual Studio installation back to normal.

Now on to more productive efforts…