0

So, I primarily use VS IDE for debugging. I got a dump file and tried to do a postmortem on it. All of the DLLs loaded their respective PDBs except one and I don't know exactly why. This information would be helpful in determining if the dump file got corrupted in some way or if the client has a corrupted DLL.

I have also tried to use WinDbg to debug this, which I have some but not a lot of experience with. I updated the symbol paths to the directory that has the PDBs of the proper build and some others that it also might match up with as well. I loaded up the dump file and that same DLL is not having a matching PDB file found.

So the question is, what prevents a particular PDB not match with a dump file and how can I find out what that information is?

Adrian
  • 10,246
  • 4
  • 44
  • 110

1 Answers1

0

Symbols have a hash and a timestamp. Both need to match in order to load the symbols. In WinDbg, there's an option to force loading symbols that don't match (.symopt+ 0x40). Visual Studio doesn't have such an option, so you need to use chkmatch to make symbols match. Note that this is a dangerous operation, because it modifies the PDB file. You should create a backup copy and delete the modified file after you're done.

If you can't figure out what executable exactly is in the dump file, try .writemem <FileName> <Range> with the starting address of the executable and its size. See also How to retrieve assembly from a raw memory dump?.

For checking a dump file for corruption, I only know about DumpChk, which comes with WinDbg. AFAIK, the file format does not allow detection of single byte corruptions or similar.

I updated the symbol paths to the directory that has the PDBs

You should set up a symbol server. With a symbol server, there's no need to look for symbols or configure directories.

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
  • Yeah, I already saw chkmatch and I can't use it. It doesn't work for dump files, only executables. My company has not setup a symbol server atm, and unless there is a great benefit, we are unlikely to do so. How would I know what failed to match? You've only answered half the question. – Adrian Apr 13 '20 at 22:47
  • `dumpchk.exe` didn't find anything wrong with the dump file. However, the PDB that I have should be the matching ones to the dump file. We version our SW and make sure that the historical DLLs and PDBs and other files are stored in a safe location. Not sure what's going on. :( – Adrian Apr 14 '20 at 06:02
  • Did you try `.writemem` for the DLL and compare the result to the DLL you have? – Thomas Weller Apr 14 '20 at 15:28