0

I have been using CLRMD to load/analyze crash dumps using DbgEng (casting the IDebuggerInterface to the IDebugControl6). I am able to execute the same commands as in WinDBG. Most of the functionality works as expected, but i am noticing a difference in the output if i specify "!analyze -v".

In WinDBG it is able to fully resolve FAILURE_SYMBOL_NAME but when doing the same via CLRMD its showing myapp.exe!unknown_error_in_process (instead of System.Windows.Forms.dll!System.Windows.Forms.Control.get_Handle). I am using the exact same symbol settings.

I wanted to use CLRMD as it seemed to be a more modern/flexible approach (vs parsing the output of a WinDBG log file) but am concerned about the differences.

This seems like a pretty good clue, but not sure how to fix it:

"Unable to load image C:\Windows\assembly\NativeImages_v4.0.30319_64\System.Windows.Forms\1afec06f634f3b2469d3ff28cf573ba5\System.Windows.Forms.ni.dll, Win32 error 0n2 *** WARNING: Unable to verify checksum for System.Windows.Forms.ni.dll"

Any ideas?

rupertmulrenan
  • 355
  • 1
  • 3
  • 13
  • 1
    .ni.dll are native images. use [ngen to generate a pdb](https://pastebin.com/jxVLVNvM) – magicandre1981 Aug 22 '18 at 15:57
  • If i look on my system i dont have that folder (C:\Windows\assembly\NativeImages_v4.0.30319_64\System.Windows.Forms\1afec06f634f3b2469d3ff28cf573ba5\). Would i need to go back to the machine the crash dump was created on and generate one from there (am unable to do this)? The thing im finding strange is how WinDBG can read the crash dump correctly but not CLRMD. It seems im missing some extra steps... – rupertmulrenan Aug 23 '18 at 08:02
  • run the ngen command on the PC where you captured the dump – magicandre1981 Aug 23 '18 at 14:44

0 Answers0