Hex / Binary / Decimal / Octal number conversion in WinDbg

Normally if I need to do any conversions between different number formats I’ll just do it in my head (yeah, right!) or load calc.exe.   A while back one of my posts showed how easy it was to convert numbers in PowerShell e.g.

[Convert]::ToString(734, 2)

will convert 734 to binary, and

[Convert]::ToString(179, 16)

will convert 179 to hexadecimal.

It’s just as easy to do it in WinDbg if you need to do any conversions while debugging using .formats.  The benefit of .formats is that it will give you all the available conversions it can, so if you were to enter .formats 0y1100011 you would see:

To make sure that WinDbg is aware of the number format you are entering as a parameter you give it the relevant prefix: 0y (binary), 0x(hexadecimal), 0t (octal) & 0n (decimal).  You can also set the default number base using the n command which means all numbers entered will be interpreted as such. Just entering n will show the current number base e.g.

And to change it to octal…

Lazy debugging

Like all lazy good sysadmins if I have to do something more than twice I’ll start to think about either:

• Delegating to one of my team(!)
  or
• Scripting it.

A while back I read a blog post by Dmitry Vostokov about scripting the analysis of mini crash dumps but never got round to trying it until today.  The only difference from Dmitry’s post is that I took the script and then saved it as minidump_analysis.txt on my notebook.  I then fired up WinDbg and opened a minidump for analysis.  Using the following you can then call your script to be run against the loaded dumpfile

This will then run all of the commands in the script against the minidump and output it to a text file which will be the name of the dumpfile with .log appended to it.

Okay, so its not going to actually do the analysis for me but at least I don’t have to remember to run all the different commands.

Don’t stick that USB in there (aka PNP_DETECTED_FATAL_ERROR)…

A couple of days ago one of my team reported that one of our Windows servers had just BSOD’d just as they were sliding the monitor out of the rack.  This particular Server 2003 box runs as our main licence server here at the University for the numerous and varied specialist applications that have their own licence managers (such as FlexNet / FLEXlm) and therefore we have a fair number of dongles from various suppliers that work as part of the licensing mechanism.  The server was set to auto-restart after a crash so once it was back up the investigation started and after tasking the same team member with checking that the server seemed in reasonably good health and that the licence managers were working (might be the Summer vacation but we still have some students and academics around the place) I started the work to try and establish what had triggered BSOD.

The event logs showed the crash but there were no entries immediately prior that would indicate something bad was about to happen.  Next I grabbed the crash dump file from the machine.  The server was configured to create a kernel dump so c:\windows\memory.dmp was a manageable 114MB.  After loading it up into WinDbg the initial output confirmed the bugcheck code that I’d seen in the event log but running…

!analyze –v

…gave me something much more useful.  At the top of the output some more info on the bugcheck was displayed:

This was the first time that I’d seen a PNP_DETECTED_FATAL_ERROR bugcheck but the output gave me some idea about what had gone on.  Given that the output pointed to duplicate PDOs I wondered if maybe one of the USB licence dongles, or the hardware it had attached to had fallen over and then come back causing the PnP manager to enumerate the new device before the old entry had been tidied up (maybe the PnP’s surprise-remove remove command hadn’t been actioned properly?  surprise-remove is what kicks in if you remove a USB memory stick for example without doing the ‘Safely Remove Hardware’ routine).  Didn’t seem likely but the next thing to do was to identify what device was showing as being duplicated.  After making a note of the two offending PDOs (the newly reported PDO 88790170, and the one that it was a duplicate of 8991ac40) I ran…

 !devnode 0 1

…and searched the output to track them down.  Pretty quickly I found the following:

Running !devnode 0 1 shows the devnode structure in a hierarchical format which makes it much easier to read the results.  So despite my first thoughts that maybe the crash was linked to one of the many licence manager we’ve got running on the server (along with their USB dongles) I think that I might actually be looking for a team member who has been sticking a SanDisk Cruzer USB stick somewhere they shouldn’t…