Today I got a callstack via email (from the NTDEV list), but no dump file. I needed to determine if the bugcheck was due to a KMDF or a USB core bug. Since I had no dump file, I had to work purely on what the message contained. The callstack did have symbols and offsets though, so I had a decent place to start. All in all, it took me less then 10 minutes from start to finish to fully debug the problem (which is funny because it took me more time to write this entry up ;) ).

The callstack looked like this:

eax=00000107 ebx=82d60104 ecx=82e69f5c edx=82e69f5c esi=82e69ce8 edi=8293c3e8
eip=f7813371 esp=f7b36a94 ebp=f7b36aac iopl=0         nv up ei pl nz ac pe cy
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000 efl=00010213

usbhub!USBH_SetPowerD0+0xd3:
f7813371 8908             mov     [eax],ecx 

f7b36aac f78134b2 82962cc0 00000100 8293c3e8 usbhub!USBH_SetPowerD0+0xd3
f7b36ac8 f7813727 8293c3e8 82962cc0 82962cc0 usbhub!USBH_PdoSetPower+0x80
f7b36ae8 f780b97b 82962d78 82962cc0 00000002 usbhub!USBH_PdoPower+0x201
f7b36b08 f78091d8 8293c3e8 82962cc0 f7b36b3c usbhub!USBH_PdoDispatch+0x83
f7b36b18 804e37f7 8293c330 82962cc0 82962d78 usbhub!USBH_HubDispatch+0x48
[...]
f7b36b5c ed4da316 8293c330 8293c518 82962d9c nt!PoCallDriver+0x195
f7b36b7c ed4da3b9 f7b36bb8 8293ca00 ed4ec730 Wdf01000!FxPkgFdo::RaiseDevicePower+0x50
[...]

Not much to go on. What I really wanted to do was map usbhub!USBH_SetPowerD0+0xd3 to a line in the source file, but how could I do that? Then it occurred to me that I could load usbhub.sys as a dump file, unassemble at that offset and let the debugger do all the hard work for me. So, here is what I did:

1. Copied the XP SP2 (the email included the OS version, otherwise I would have had to iterate across multiple releases) usbhub.sys off the build server.
2. Loaded the image as a dump file.

   C:\debuggers\windbg.exe -z usbhub.sys

3. Ran !symfix to fix up the symbols
4. Unassembled usbhub!USBH_SetPowerD0+0xd3 and make sure that the instructions at that offset in my debugger matched the callstack.

   :000> u USBH_SetPowerD0+0xd3
   usbhub!USBH_SetPowerD0+0xd3 [[...] @ 596]:
   0001c371 8908             mov     [eax],ecx
   

   Note that not only did I confirm that the source was correct, the debugger also gave me a source file (name removed) and line number!
5. Loaded up the source file and goto line 596 which had this pseudo code

   InsertTailList(&fdoExt->ListHead, &PDO_EXT(pdo)->link);
   

   PDO_EXT() returns the device extension if the pdo is != NULL while -1 if pdo == NULL. From the email, I had the values of the registers and eax was 0x107, which looks suspiciously like -1 + 0x108. To verify this last step, I did the following:

   Registers from the email
   eax=00000107 ebx=82d60104 ecx=82e69f5c edx=82e69f5c esi=82e69ce8 edi=8293c3e8
   eip=f7813371 esp=f7b36a94 ebp=f7b36aac iopl=0         nv up ei pl nz ac pe cy
   cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000 efl=00010213
   
   0:000> dt [PDO DEVICE EXTENSION TYPE] link
      +0x108 link: _LIST_ENTRY
   

6. So I have confirmed that this is the line that was executed and that -1 was returned, but I really wanted to make sure. To verify that eax was what i thought it was, I disassembled right before 0xD3 to see how eax was initialized.

   0:000> u usbhub!USBH_SetPowerD0+0xc0 usbhub!USBH_SetPowerD0+0xd3+1
   usbhub!USBH_SetPowerD0+0xc0 [[...] @ 596]:
   0001c35e e8834dffff       call    usbhub!PDO_EXT (000110e6)
   0001c363 8d8e74020000     lea     ecx,[esi+0x274]
   0001c369 8b5104           mov     edx,[ecx+0x4]
   0001c36c 0508010000       add     eax,0x108
   0001c371 8908             mov     [eax],ecx
   

   eax is the value retuned from the call to usbhub!PDO_EXT whic we then add 0x108 to 2 instructions later. This confirms my theory. To put the final nail in the coffin, I wanted to see the offset of fdoExt->ListHead and see if the initialization of ecx right after the call was the FDO list head.

   0:000> dt [FDO DEVICE EXTENSION TYPE] ListHead
      +0x274 ListHead : _LIST_ENTRY
   

I am yet again surprised by the utility of windbg. It really helped me identify and quantify a bug with very little information to go by. Certainly not all debugging sessions are this easy, but it very gratifying when they are this easy and quick to diagnose.