0

Is there any way to debug DLL using dmp file w/o having host application's source code?

Suppose that I write plugins for some external system for which I don't have any source code. When my plugin crashes, I can generate dump for the faulting module. But is there any way to get any useful information in such situation?

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
FrozenHeart
  • 19,844
  • 33
  • 126
  • 242
  • *"But is there any way to get any useful information in such situation?"* - That largely depends on your definition of *"useful information"*. You can get thread information, call stacks, loaded modules, and so on. You won't get symbolic information for modules you don't have PDBs for. You should have PDBs for your DLLs. Anyway, this question is pretty open-ended, and shouldn't be asked like that on stackoverflow. – IInspectable Sep 01 '16 at 12:18
  • Open you project with VS first, then open the dmp file, then press "debug with native only". But you have to make sure the source code is the right version for the exe. – neohope Sep 02 '16 at 08:52

1 Answers1

0

Yes, it can be useful. I've done it the other way round: I had the source code of the host system but not the one of the plugins. For ~5 years I was able to analyze crashes in our application (.NET) but also identified problems in the plugins (mostly C++).

What you can e.g. find out:

  • the version of the host system (use lmv in WinDbg)
  • the version of your plugin used (again lmv in WinDbg)
  • if other plugins are active/installed (again lmv in WinDbg)
  • the OS and its bitness to reproduce (verify against the OS reported by customer)
  • which API method was called (since these are public) (k in WinDbg) and which parameters were passed, so you can verify those

It's even more useful if parts of the application are in .NET, because you get a lot of extra information. Things to care about: ideally you have a dump file with full memory information. I always asked for those.

Look at Microsoft: they get blue screen information and only little data is transmitted (a few kb). It's unlikely that Blue Screens occur due to Microsoft code. It's more likely that people use their API in an incorrect way. However, Microsoft is still able to analyze what made it a Blue Screen and apply counter measures, even if they don't have everyone's code.

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