WinDbg missing symbols for managed code
I have a problem with WinDbg to use PDB for my .NET DLL. The hang dump I'm looking at is from a production build, but I have PDB files from a debug build of the same code.
I have set the symbol path to include the local folder and 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
. However, managed stack lists do not contain method names.
Rebooting .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 WinDbg connects to a service in a test environment, the managed stacks appear with method names. Dumping memory and parsing the DMP file locally, I cannot see the names in the managed stacks. What could I be doing wrong?
source to share
There is not much you can do now. As John Robbins says :
Most importantly all developers need to know: PDB files are just as important as source code! ... I have been countless companies to help them debug those bugs that cost hundreds of thousands of dollars and no one can find PDB files to build working on production server. Without the appropriate PDB files, you simply made your debugging task nearly impossible.
You can try your luck with an evil tool called ChkMatch tricking VS into accepting any PDB you throw at it. Just know the odds are close to zero, you'll end up with any meaningful stacks - the PE layout is extremely sensitive to code changes, and technically, even two builds from the same source don't guarantee the same PE .
[edit:] Sorry, just noticed that you are using WinDBG. In this case, as Remus says, .reload / f / i can achieve the same trick (with the same risks).
source to share
Ok, I asked the wrong question. I don't even need symbols for .NET code (as Remus pointed out). So this is not an answer to my question, but this is the solution to my problem, which seems to be related to .NET build on a WinDbg machine.
I get meaningful stack information when .chain
it tells me the following:
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 server reset was done.)
I am not getting any information other than addresses from !clrstack
when I run on machines where it .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
source to share