问题
I am using WinDbg to load a crash dump from managed code (C#, a console application built for Any CPU), and a crash dump is created on a x64 platform. I am debugging on a x64 platform. I have put the related PDB file into the symbol path.
But WinDbg always find the symbol from a strange folder. Here is an example (when I got from using !sym noisy):
SYMSRV: c:\MySymbols\FooService.pdb\4311207E2E2D442CB7473828D2488F941\FooService.pdb not found
My application is called FooService.exe and the related PDB file is named FooService.pdb. I have set C:\MySymbols as the symbol path and copied FooService.pdb to the directory C:\MySymbols. But why does WinDbg not find FooService.pdb in C:\MySymbols, but from a strange sub-folder, "FooService.pdb\4311207E2E2D442CB7473828D2488F941"?
In my scenario, in order to load the PDB symbol file, what is the best solution (do I have to create the sub-folder FooService.pdb\4311207E2E2D442CB7473828D2488F941 by myself manually)?
回答1:
I believe the strange part of the path is used for versioning the PDBs in the symbol cache. As the cache can be used for many applications including different versions of the same application the symbol downloader needs to do something to keep them apart.
You can force the symbol loader to disregard any cached copy by using the .reload /fo command. Combined with the .sympath option you should be able to set up loading. An easy way to add your local path to the symbol path is .sympath+ <PATH>. After that do a .reload /fo to disregard any previously cached PDBs.
EDIT: I changed my answer quiet a bit as I believe I initially misread your question. I hope this update is more useful.
来源：https://stackoverflow.com/questions/1552927/symbol-issue-when-debugging-c-sharp-code