2

I am having a problem getting WinDbg to use the PDB files for my .NET DLL files. The hang dump I am looking at is from a production build, but I have PDB files from a debug build of the same code.

I set the symbol path to include a local folder and the Microsoft 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 do not contain any method names.

Doing a reload, .reload /f, tells me:

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?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
turnhose
  • 468
  • 5
  • 7
  • btw, you did you load sos and dump the clr stack from sos? Even w/o symbols, the assemblies hace such rich metadata that the stack w/o parameters can usually be dumped just from the module info. – Remus Rusanu Sep 10 '09 at 19:28
  • yes, 2.0 sos, and I thought too that for .net code I don't even need pdb's at all. which pretty much tells me I was asking the wrong question, this is not a symbol issue. Turns out I get meaningful stack info when running windbg on the server. I'll post update once I found the issue I am having locally. – turnhose Sep 10 '09 at 21:16

3 Answers3

7

You need the exact same PDB files. Debug symbols will not work with a retail dump. And you need the PDB file from exactly the same build.

Whenever you release bits into the wild, your build team should store the private PDB files for reference in case you have to stare at a dump six months later...

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Remus Rusanu
  • 288,378
  • 40
  • 442
  • 569
  • btw if you don't have the release bits pdb then you should make an enlistment and get the source tree as it was at the moment of the release then build with identical settings as the release build. Ideally your source tree should tag each relese and be easy to get the tree at a specific tag. If the build you get is identical bit-to-bit with the relese, the pdbs will load. Ultimately you can force the symbols in with /reload /f by specifying the size and timestamp explicitly, ovewrridding dbg's decision: http://msdn.microsoft.com/en-us/library/cc266830.aspx. Mileage will vary. – Remus Rusanu Sep 10 '09 at 18:23
  • Remus, the build process includes embedding a build-GUID in the resulting binaries, which is used for matching. Synchronizing the sources would not be enough. – Ofek Shilon Sep 10 '09 at 18:37
  • @Ofek: I did forced overload of symbols from unmatched build several times back in my glory days, with .reload /f and explicit address/size/timestamp. Windbg will barf, but accept the mismatched symbols. It seldom pays though and having the right symbols is *sooo* much better. – Remus Rusanu Sep 10 '09 at 18:54
  • With the same source code, but different builds, .reload /f /i forced windbg to accept the mismatched symbols. – John Naegle Nov 09 '09 at 15:49
3

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

Community
  • 1
  • 1
Ofek Shilon
  • 14,734
  • 5
  • 67
  • 101
1

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

I get meaningful stack information 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

(The same as on the server the dump was taken on.)

I don't get any information 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
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
turnhose
  • 468
  • 5
  • 7