4

I'm doing some crash dump debugging, where I am looking a dump taken from a production server. The machine I'm running WinDbg on must have a slightly different version of the .NET runtime installed -- I'm getting errors loading the native images of .NET system assemblies (so can't load for example System.Data.Linq).

What is the best way to ensure that my debug machine has access to all the right symbols?

Edit Added output of lmv for Thomas Weller

000007fb`68660000 000007fb`68993000   System_Data_Linq_ni C (pdb symbols)          C:\Program Files\Debugging Tools for Windows (x64)\sym\System.Data.Linq.pdb\703A918D116A4558BB44245924371ACD1\System.Data.Linq.pdb
    Loaded symbol image file: System.Data.Linq.ni.dll
    Image path: C:\Windows\assembly\NativeImages_v4.0.30319_64\System.Data.Linq\acbd568cd3c2499fbb7b2639c4a46a81\System.Data.Linq.ni.dll
    Image name: System.Data.Linq.ni.dll
    Has CLR image header, track-debug-data flag not set
    Timestamp:        Fri Apr 11 20:41:26 2014 (534899C6)
    CheckSum:         00000000
    ImageSize:        00333000
    File version:     4.0.30319.34209
    Product version:  4.0.30319.34209
    File flags:       0 (Mask 3F)
    File OS:          4 Unknown Win32
    File type:        2.0 Dll
    File date:        00000000.00000000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
Community
  • 1
  • 1
JMarsch
  • 21,484
  • 15
  • 77
  • 125
  • I assume you are asking this question because using the official symbols server (at msdl.microsoft.com/download/symbols) is not working, correct? – John Koerner Sep 04 '15 at 19:36
  • I'm pulling from the official symbol site -- no joy – JMarsch Sep 04 '15 at 21:11
  • What version of System.Data.Linq is affected? Can you post the output of `lmv` for that module? – Thomas Weller Sep 04 '15 at 21:22
  • I added it above. A couple of weird issues: 1. lmv m System.Data.Linq didn't return anything, I had to do an lmv (no params) and search 2. Here's the error message I get during .reload: Unable to load image C:\Windows\assembly\NativeImages_v4.0.30319_64\System.Data.Linq\acbd568cd3c2499fbb7b2639c4a46a81\System.Data.Linq.ni.dll, Win32 error 0n2 *** WARNING: Unable to verify checksum for System.Data.Linq.ni.dll – JMarsch Sep 04 '15 at 21:32
  • `lm` replaces special characters like `.` by `_`. You can use wildcards like `*Linq*` to reduce the output. Other than that it seems you have the symbols but not the DLL... What is the command you want to execute for which you need the symbols of Linq? – Thomas Weller Sep 05 '15 at 08:01
  • I was really just trying to get a good stack track. We have a stack overflow, and we are doing some rather exotic work with LINQ. The overflow occurs because of some things we are leading linq to do (so the overflow is purely in linq). I want to look at some values in the stack frames. – JMarsch Sep 08 '15 at 23:33

3 Answers3

10

the ni in the name shows that this is a native version (ngen optimized) which differs from machine to machine. You have to create the PDB on the machine where you got the dmp with ngen:

ngen createpdb C:\Windows\assembly\NativeImages_v4.0.30319_32\System.Data.Linq\
f989891b3a507d4aaec44ab1df12e9d5\System.Data.Linq.ni.dll c:\symbols /debug

Now add the PDBs from C:\symbols to Windbgs symbol path.

magicandre1981
  • 27,895
  • 5
  • 86
  • 127
  • It seems he already has PDBs. Also, does creating PDBs afterwards add more information than available in the DLL itself? – Thomas Weller Sep 05 '15 at 08:07
  • I'd also like to know if that's common. If this is needed often, I'd add such a feature to my tool mscordacwks collector. – Thomas Weller Sep 05 '15 at 08:15
  • @ThomasWeller for ETW traces we also need the NI PDB (WPRUI.exe generates them at time where it writes the ETL file to disk) to show the stack. So maybe Windbg also needs this PDB. **ngen /?** shows that we have to add /debug to commandline to generate a PDB that should be used for debugging. – magicandre1981 Sep 05 '15 at 18:07
  • @ThomasWeller when I look at the load stacks with ETW/xperf/WPA I see that the normal DLL is loaded first and next the NI version. So it looks like you also need both PDBs. – magicandre1981 Sep 07 '15 at 15:55
3

You can have WINDBG download the official symbols from Microsoft Servers by running the following command:

.sympath srv*c:\symbols*http://msdl.microsoft.com/download/symbols
.reload /f

This will store the symbols downloaded from the server in a local cache at C:\Symbols and then force a reload of the symbols for all currently loaded modules.

John Koerner
  • 37,428
  • 8
  • 84
  • 134
2

There are some things to consider for .NET:

  1. Make sure you have a good dump for .NET, i.e. 64 bit dump of 64 bit process or 32 bit dump of 32 bit process. If lm m wow64 shows a module, it's not a "good" dump.
  2. Set up the symbols, at least .symfix c:\symbols and .reload

  3. Get the .NET debugging files (SOS.dll and mscordacwks.dll) from the original PC and rename them accordingly. See the details in another answer.

    My freeware tool Mscordacwks Collector will do that for you, including the renaming.

    If that PC is no longer available, you might want to search those files in my mscordacwks and SOS archive

    Disclaimer: I'm the author of those, if that wasn't clear enough.

Community
  • 1
  • 1
Thomas Weller
  • 55,411
  • 20
  • 125
  • 222