WinDbg takes extremely long time to loading symbols; is searching every directory in large network UNC symbol store

Question

I\'ve spent several days trying to speed up loading of symbols when debugging crash dumps using WinDbg, and I\'m unable to get past a particular problem.

The issue is t

Answer 1

Shouldn't that be:

.sympath cache*C:\SymbolCache1;SRV*\\our.corp\SymbolStore;SRV*C:\SymbolCache2*http://msdl.microsoft.com/download/symbols  

That is, by listing \\our.corp\SymbolStore without SRV* you are telling dbghelp to look in this unstructured directory for symbols. If you use the SRV* syntax then you are telling dbghelp to get symsrv to look in that directory in a very specific and structured way.

symsrv.dll can search Microsoft's symbol server efficiently, and it can search yours efficiently, if you tell it to do so with SRV*.

Answer 2

I finally found an unsatisfying but perfectly good solution: set up a SymProxy.

This let me remove the UNC share from my symbol path and replace it with a reference to the SymProxy as my http symbol server.

.sympath SRV*C:\SymbolCache*http://somemachine.our.corp/Symbols

The proxy itself still searches in the UNC share, but WinDbg can no longer search the network directory -- instead, it has to pass the information about the symbol it wants to SymProxy, and SymProxy looks in exactly one location on the UNC share instead of doing an exhaustive search.

This doesn't explain why WinDbg does an search of the entire UNC share, but it does fix the problem of WinDbg hanging while it searchs for symbols. Finally symbol loading is fast again!

Another advantage of installing a SymProxy is that you can set it up to pull from multiple symbol locations. For example, you can have it connect to both your local organization's symbol store as well as the Microsoft symbol server. Then your developers can set their symbol path to reference only the SymProxy rather than multiple symbol locations.