'Start Debugging' takes forever in VisualStudio 2005

Question

I have a large project that has > 1000 files. When I press the green 'Play' button to start debugging, once everything is built, it can take up to 5 minutes for the app to start running.

It looks like Visual Studio is loading and unloading various DLLs, but it also just sits there occasionally doing nothing.

Running from the command line takes only a few seconds.

What's going on? How can I speed it up?

[EDIT] It turned out to be our Symbol Server. The administrator had killed it without informing anyone. Doh.

Thanks for your help guys.

Answer 1

It sounds like it could be loading symbols for various DLL's which you probably don't care about. You can disable these in Options.

If not, what do you see in the Output window?

Answer 2

Some thoughts and suggestions:

• It could be caused by complex dependency checking that VS2005 does to ensure that no components have changes and have to be re-built prior to debugging. Sometimes tweaking the inter-project dependencies in the solution can help.

• Are you using source control integration in Visual Studio? If so, sometimes accessing the source control repository elsewhere on the network can cause Visual Studio to slow down like this. If using a source control system like ClearCase where you can reduce unnecessary LAN communication (e.g. using a snapshot view), consider doing this.

• I also find that running the executable separately (from outside Visual Studio) and then using VS2005 to attach to the process can be much faster. This is predominantly the way I work, and I find it much less frustrating.

• Another thing to consider is whether you are using a symbol server to access debug symbols for the Windows DLLs. If so, VS2005 can sometimes try to access the symbol server every time you debug. The way around this is to load the symbols once, and then uncheck the symbol server URL under Tools->Options->Debugging->Symbols. As long as the OS libraries haven't changed since you last downloaded the symbols, there's no reason to access the remote server every time.