Preventing symbol loading in Visual Studio

Question

Many questions have been asked about this, and many answers have been proposed, but nothing's worked for me.

At one point, I turned on .NET symbol loading for WPF projects, using these instructions: http://blogs.msdn.com/sburke/archive/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code.aspx

Worked great, all cool and that.

Except in Silverlight projects, it would also try to load symbols from that server, but they didn't exist, so startup time to debug a project was huge.

So, I turned off symbol loading, and it did stop trying to load all the symbols, except for one namespace: System.Windows.Browser. VS still tries to load those with each F5, taking several seconds and driving me crazy.

I tried to add the symbol server mentioned here as well: http://blogs.msdn.com/seema/archive/2008/10/08/xperf-a-cpu-sampler-for-silverlight.aspx

Thinking that maybe the symbols were there, they'd get loaded and cached, and all would be well. But no, not only do they not get loaded, but VS tries to load symbols for every other DLL in my project, including those for which symbols have never been available, making it take even longer to start up.

Frankly, I don't even need to debug into the sources of these DLLs, I just thought it would be cool. Now I can't turn it off and it's driving me batty. What's the fix?

Answer 1

Tools -> Options -> Debugging -> Symbols -> Check "Search the above locations only when symbols are loaded manually", or remove everything from the list.

If you check the box, then you can rclick -> Load Symbols on DLLs in the Modules list / Stack window.

Answer 2

I think you may have

_NT_SYMBOL_PATH 

defined in your environment. That seems to override whatever you do in Tools->Options->Debugging->Symbols. I had the same problem, and it almost drove me bananas, but in a moment of creativity I directed procmon (from sysinternals) at devenv.exe and searched the log for "symbol", and the first thing that appears was that environment variable mentioned above. There could be other similar sinister sidechannels too, but I wouldn't be surprised if you could out those too with a little aid by procmon.

I suspect that this behaviour comes from the fact that symsrv.dll, which is loading symbols, is used with other tools and there are different ways to signal that symbols should be loaded and... well, I guess this goes to the "shit-happens" account.

On a side-note -- this behaviour can be really bad for you if you have code using wininet-functions such as HttpSendRequest(). It will quickly deadlock visual studio and all instances of internet exploder. Add to that symbol loading that doesn't let itself be turned off. You can imagine what a day I've had so far...

But I feel better now :)

//P