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
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.