0

Exactly much from the original build do I need to save in order to properly debug a crash dump file sent to me by a customer? Obviously I need the PDBs Do I need something else?

(This would be for a crash dump file written by the MiniDumpWriteDump function from dbghelp.dll.)

Until now I've always saved off the entire build folder. Code, PDBs, .OBJ files, output binaries, everything. Just to be safe. I'd like to minimimize what I save. But I can't afford to find out the hard way that I missed something.

The actual source code will be in source control and tagged with the build label so I can pull by label and get exactly what I used to build. Would I even need to bother pulling source before debugging the crash dump or is it enough to have just the PDBs?

Joe
  • 5,394
  • 3
  • 23
  • 54
  • 2
    PDBs are everything you need to get symbol information when debugging minidumps. A PDB contains all the information that maps addresses to symbols and source files and lines. No other artifacts are required. If you also [index sources & publish symbols](https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/build/index-sources-publish-symbols), then the only manual step in debugging is opening the .dmp file in your debugger. Everything else is done for you, like loading up the correct PDB or downloading the right version of your source files. That's not strictly required, though. – IInspectable Aug 01 '20 at 17:20

1 Answers1

0

From your company, PDBs should be all you need. Source code is helpful, too, because PDBs provide line numbers and you can have a direct look into the source code.

Typically you would not copy the PDBs, but set up a symbol server instead. You would also not copy the source code, but let a source server manage that. Team Foundation Server (TFS) provides both. But there are alternatives that do not need TFS.

In case of a .NET program, you also need the SOS.dll and MSCORDACWKS.DLL from the machine of the client where the crash occurred. having the correct version number (note that there may be several .NET frameworks installed).

SOS is the debugging extension for WinDbg that enables .NET debugging. MSCORDACWKS is the Data Access Component (DAC) that knows how objects in memory look like. (MS = Microsoft, COR = .NET, WKS = Workstation). There's a dedicated WinDbg command for that, .cordll.

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
  • Why would I need sos.dll and mscordacwks.dll from the machine where the crash occurred? What will that do for me? That's a new one to me. – Joe Oct 12 '20 at 13:31