windbg missing symbols for managed code

Question

I am having a problem getting windbg to use the pdb files for my .Net dlls. the hang dump I am looking at is from a production build. but I have pdbs from a debug build of the same code.

I set the symbol path to include a local folder and the msft symbol server.

C:\websymbols\foo;srv*c:\websymbols*http://msdl.microsoft.com/download/symbols

I put all my pdb files in c:\websymbols\foo yet the managed stack listings contain no method names.

doing a reload tells me

.reload /f

   DBGHELP: No debug info for FOO.dll.  Searching for dbg file
SYMSRV:  c:\websymbols\foo\FOO.dbg\49B7F17C10000\FOO.dbg not found
SYMSRV:  c:\websymbols\FOO.dbg\49B7F17C10000\FOO.dbg not found
SYMSRV:  http://msdl.microsoft.com/download/symbols/FOO.dbg/49B7F17C10000/FOO.dbg not found
DBGHELP: .\FOO.dbg - file not found
DBGHELP: .\dll\FOO.dbg - path not found
DBGHELP: .\symbols\dll\FOO.dbg - path not found
DBGHELP: FOO.dll missing debug info.  Searching for pdb anyway
DBGHELP: Can't use symbol server for FOO.pdb - no header information available
DBGHELP: FOO.pdb - file not found
*** WARNING: Unable to verify checksum for FOO.dll
*** ERROR: Module load completed but symbols could not be loaded for FOO.dll
DBGHELP: FOO - no symbols loaded

when attaching windbg to the service in a test environment, managed stacks show up fine with method names. dumping the memory, and analyzing the dmp file locally I don't see the names in the managed stacks. What might I be doing wrong?

Thanks

Answer 1

You need the exact same PDBs. Debug symbols will not work with a retail dump. And you need the pdb from exactly the same build. Whenever you release bits into the wild, your build team should store the private pdbs for referenc ein case you have to stare at a dump 6 months later...

Answer 2

There's not much you can do about it now. As John Robbins says:

The most important thing all developers need to know: PDB files are as important as source code! ... I've been to countless companies to help them debug those bugs costing hundreds of thousands of dollars and nobody can find the PDB files for the build running on a production server. Without the matching PDB files you just made your debugging challenge nearly impossible.

You can try your luck with an evil tool called ChkMatch, fooling VS to accept whatever PDB you throw at it. Just know that chances are near-zero you'd get any meaningful stacks - the PE layout is extremely sensitive to code changes, and technically even two builds of identical source are not guaranteed to give the same PE.

[edit:] Sorry, just noticed you use WinDBG. In that case, as Remus says, .reload /f /i can achieve the same trick (with the same risks).

Answer 3

ok, I asked the wrong question. I don't even need symbols for the .net code. (as Remus pointed out). So this is not the answer to my question, but it is the solution to my problem. Which seems to be related to the .Net build on the machine windbg is run on.

I get meaningful stack info when .chain tells me this C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos: image 2.0.50727.1433, API 1.0.0, built Tue Oct 23 20:41:30 2007 (same as on the server the dump was taken)

I don't get any info other than addresses from !clrstack when run on machines where .chain tells me C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos: image 2.0.50727.3053, API 1.0.0, built Fri Jul 25 07:08:38 2008