Resolving Very Slow Symbol Loading with VS 2008 during debugging

Recently, I was encountering insanely slow project loading times during debugging in Visual Studio 2008. Interestingly, this only happened while loading the project only in debug mode. Also, during the slow symbol loading time, the status bar at Visual Studio 2008 always showed Loading Symbols For ____.Dll.

To track it down, I enabled logging for the VS 2008 IDE. This can be done by adding the following entries to its configuration file.

1) Navigate to: C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE in Windows Explorer

2) Load devenv.exe.config in text editor.

3) Add the following entries into it

        <trace autoflush="true" indentsize="4">
               <add name="myListener" 
type="System.Diagnostics.TextWriterTraceListener, System version=1.0.3300.0, 
Culture=neutral, PublicKeyToken=b77a5c561934e089" 
initializeData="c:\myListener.log" />
               <remove name="Default" />
 As per this configuration, the trace log would be saved to C:\myListener.Log. Now I fired up VS 2008 and loaded to project in debug mode to reproduce the issues.
 I also ran couple of unit test cases in debug mode which were also not able to load. I opened the trace log and found these exceptions:

[V, 5820, 7, 2008/07/04 14:00:33.412] devenv.exe: DIA thew in retrieving symbols: System.Runtime.InteropServices.COMException (0x806D0005): Exception from HRESULT: 0x806D0005

at Microsoft.VisualStudio.TestTools.Common.Dia2Lib.IDiaDataSource.loadDataForExe(String executable, String searchPath, Object pCallback)

at Microsoft.VisualStudio.TestTools.Common.DiaHelper.GetSymbolsFileName(String imagePath)

Confirmed with the issue was related to loading of Symbols. I realized that I had once set up a dedicated symbol directory on machine at C:\symbols to enable debugging with WinDbg.

I checked the Debugging Options in VS 2008 to see if its trying to load symbols from somewhere else.



Then suddenly, I was reminded that I had once set up a environment variable _NT_SYMBOL_PATH to an Internet location while debugging in WinDbg to enable automatic downloading of symbols.

I originally thought that this setting was only applicable to WinDbg. But I was mistaken. In fact, this setting will be used across by all debuggers (atleast Microsoft debuggers). This is documented here. I was pretty sure that VS 2008 was trying to load symbols from the Internet location and since many of the assemblies in my application didn't had symbols were them, it must have been failing.

To confirm, I fired My Computer -> Properties -> Advanced -> Environment Variables and cleared out the line


I reloaded the my project in VS 2008 in debug mode and Bingo, the problem was solved :)

While investigating this problem, I came across many other sources which could cause this issue , so I thought I can post it here for the benefit of community. The credit for these tips goes to Azeem Khan who is working with VSTS team at Microsoft.

  • Make sure that you don't have a symbol path specified in VS under Tools | Options | Debugging | Symbols and also, that you don't have the NT_SYMBOL_PATH environment variable set on your machine.

  • Verify that you haven't specified any network shares under the same setting to server that do not exist anymore. This will require timeouts.

  • Specify a local cache for symbols under the same setting. After you have downloaded symbols once from network shares you can disable those locations. Symbol loading will go a lot faster after the first attempt.

  • Do not specify any symbol lookup paths at all either in environment variable and specify paths in the options page but specify that they be used for manual loading. You can then manually load symbols for modules you care about either via the context menu in call stack or the modules window.

  • VS 2008 SP1 has made a few improvements in this area. It allows for canceling loading of symbols as it is happening. This will allow you to get to your debug session much faster. Note that this is currently in Beta.

  • Clearing the breakpoints also serve to solve this problem for some people.