Find device in Windows based on Physical Device Object (PDO) identifiers

Question

I recently acquired a new motherboard, processor, and RAM. I re-installed Windows (x64 7 Ultimate) and all my apps for the new components, but it's the same (retail) OS license, video card, and optical drive from the old system.

About two weeks in, I've now seen a blue screen STOP error for the second time. The first time I had left a game running, so I blamed the game, but this time I checked the event log and found a bugcheck report with the following data:

The bugcheck was: 0x0000009f (0x0000000000000003, 0xfffffa800a21f060, 0xfffff80000b9c3d8, 0xfffffa8007a12540).

I then went first to this page and then to this page to map out what that means.

Based on the description of the error, it might be that my old power supply is not be up to the task for the new hardware. However, my new cpu is rated 15 watts lighter than the old, so I don't think that's it.

I also see that the 0xfffffa800a21f060 value from the bug check is a "physical device object". An outdated device driver seems a much more likely candidate. I want to trace this number back to a device name, and then look for an updated driver for that device. Unfortunately, I'm not sure of the next step.

Any ideas how to do that? It sounds like it might be referring to a location on the call stack in memory; I still have the memory dump, if that is needed.

---

Update:
I found the bugcheck from the first blue screen. It looks like this:

The bugcheck was: 0x00000101 (0x0000000000000031, 0x0000000000000000, 0xfffff880009f1180, 0x0000000000000001).

And the associated reference page:
http://msdn.microsoft.com/en-us/library/ff557211(v=vs.85).aspx

This one doesn't provide much to go on. It could be a faulty cpu, but I'd still like to track down the device from the latter bugcheck.

---

Update 2:
Based on instructions in an answer, I was able to get this:

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_POWER_STATE_FAILURE (9f)
A driver is causing an inconsistent power state.
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
Arg2: fffffa800a21f060, Physical Device Object of the stack
Arg3: fffff80000b9c3d8, Functional Device Object of the stack
Arg4: fffffa8007a12540, The blocked IRP

Debugging Details:
------------------


DRVPOWERSTATE_SUBCODE:  3

IMAGE_NAME:  usbhub.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4ce7a68e

MODULE_NAME: usbhub

FAULTING_MODULE: fffff88005600000 usbhub

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x9F

PROCESS_NAME:  System

CURRENT_IRQL:  2

STACK_TEXT:  
fffff800`00b9c388 fffff800`02d4b9c2 : 00000000`0000009f 00000000`00000003 fffffa80`0a21f060 fffff800`00b9c3d8 : nt!KeBugCheckEx
fffff800`00b9c390 fffff800`02cea652 : fffff800`00b9c4c0 fffff800`00b9c4c0 00000000`00000002 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x34a90
fffff800`00b9c430 fffff800`02cea4f6 : fffffa80`08f0e0d0 fffffa80`08f0e0d0 00000000`00000000 00000000`00000000 : nt!KiProcessTimerDpcTable+0x66
fffff800`00b9c4a0 fffff800`02cea3de : 000001e1`889ca6f3 fffff800`00b9cb18 00000000`00ca4ace fffff800`02e55c48 : nt!KiProcessExpiredTimerList+0xc6
fffff800`00b9caf0 fffff800`02cea1c7 : 00000092`40cd33c3 00000092`00ca4ace 00000092`40cd33b2 00000000`000000ce : nt!KiTimerExpiration+0x1be
fffff800`00b9cb90 fffff800`02cd6a2a : fffff800`02e51e80 fffff800`02e5fcc0 00000000`00000002 fffff880`00000000 : nt!KiRetireDpcList+0x277
fffff800`00b9cc40 00000000`00000000 : fffff800`00b9d000 fffff800`00b97000 fffff800`00b9cc00 00000000`00000000 : nt!KiIdleLoop+0x5a


STACK_COMMAND:  kb

FOLLOWUP_NAME:  MachineOwner

FAILURE_BUCKET_ID:  X64_0x9F_3_AiCharger_IMAGE_usbhub.sys

BUCKET_ID:  X64_0x9F_3_AiCharger_IMAGE_usbhub.sys

Followup: MachineOwner
---------

Sounds like the culprit could be a via pci usb card in the system. I don't really need it any more on the new motherboard (8 usb ports instead of just 4). I kept it in the new system because I didn't see a reason not to, and because I'm missing the slot cover for the case without it. If the blue screens continue I will likely remove it.

It seems a little less likely, but it could also be an immature driver for the controller of my usb 3.0 ports. I will go look for an updated driver for those ports, just in case.

Answer 1

Yes. You can trace this bugcheck.

1. What you need is to first download Windows debugging tools from here: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=8279

2. Next you need the appropriate Windows 7 Debugging Symbols (You want the 'retail' version. Not the 'checked' version: http://msdn.microsoft.com/en-us/windows/hardware/gg463028

3. Install the Debugging tools normally. Install the Debugging symbols to a new folder named c:\Symbols. When done with both, open up Debugging Tools for Windows, go to the File Menu and select "Symbol File Path". Replace whatever is in the box with this string (replacing drive letter and symbols path, if you choose to install the symbols to somewhere else):

srv*c:\symbols*http://msdl.microsoft.com/download/symbols

4. Next, with Windows Explorer go to c:\Windows\Minidump (assuming C: is where you installed windows). Inside you'll find the so called minidump files. These contain the information on your BSODS. One file per BSOD named after the date of the BSOD.

5. Drag the last one to your Debugging Tools for Windows empty grey area (or open it through the file menu). The Debugger will start analyzing it, after which you can see a !analyze -v link you can click.

6. Click it and you'll get the bugcheck report. Update your question with the results from this analize -v and many of us in here will be able to hint you into what might be the problem.

---

An example of what you may want to paste into your question above is given below (from one of my own minidump files from early this year when I found out I had faulty RAM:

BugCheck 1000008E, {c0000005, 940c23de, abb34b0c, 0}

Probably caused by : Npfs.SYS ( Npfs!NpRemoveAllAttributesFromList+14 )

Followup: MachineOwner

[..]

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
[...]
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 940c23de, The address that the exception occurred at
Arg3: abb34b0c, Trap Frame
Arg4: 00000000

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP: 
Npfs!NpRemoveAllAttributesFromList+14
940c23de 897004          mov     dword ptr [eax+4],esi

Answer 2

When you loaded the dmp in Windbg and loaded the symbols, run !podev 0xfffffa800a21f060 (address from argument 2: Arg2: fffffa800a21f060, Physical Device Object of the stack).

This dumps the Physical Device Object (PDO).

This

X64_0x9F_3_AiCharger_IMAGE_usbhub.sys

tells me that the ASUS Ai Charger driver caused it.