Alright, so over on answers, a user posted their DMP files for analysis. They were 9F bugchecks, however, rather than being due to an inconsistent power state, it says as follows:
No blocked IRP so cannot run an !irp, instead we have:
Both 9F's here in case anyone wants - https://skydrive.live.com/redir?resid=DED77542B4FC4992!131&authkey=!AE1GKB2_klB57L0
So, since I am personally not sure what to do here (and I hope someone can explain what you would do) I instructed the user to enable verifier. After enabling verifier, they did not crash until shutting the system down, and it took exactly 10 minutes to do so before a crash happened and the DMP was generated.
The verifier dump is a violation bugcheck (c4), however, it's ntkrnlmp.exe and here are the arguments:
here is the dump - https://skydrive.live.com/redir?resid=DED77542B4FC4992!133&authkey=!AOOFdkuLlPxa-6k
I am assuming arg1 corresponds with what was said earlier in the 9F -
However, arg2, I am not sure what that means. That's new terminology for me, and I don't think I am that far into Windows Internals yet :tongue10:
So, just experimenting, I tried running a !locks and got the following:
???? Do we need a kernel dump for things like locks?
I then ran a !poaction to try and get some info on what drivers have power IRPs pending:
Not too sure what this means~
I tried running a !deadlock:
I assume this is one of the verifier settings we can tell the user to check before initializing verifier?
Overall, any guidance or teaching in regards to what I am looking at or trying to deal with here would be more than appreciated.
Finally, here's the thread just in case any want to pop in and read what the OP has stated for info - DRIVER_POWER_STATE_FAILURE (9f) - Microsoft Community
A driver has failed to complete a power IRP within a specific time (usually 10 minutes).
No blocked IRP so cannot run an !irp, instead we have:
Code:
Arg1: 0000000000000004, The power transition timed out waiting to synchronize with the Pnp
subsystem.
Arg2: 000000000000012c, Timeout in seconds.
Arg3: fffffa800e2f5040, The thread currently holding on to the Pnp lock.
Arg4: fffff80384245810, nt!TRIAGE_9F_PNP on Win7
Both 9F's here in case anyone wants - https://skydrive.live.com/redir?resid=DED77542B4FC4992!131&authkey=!AE1GKB2_klB57L0
So, since I am personally not sure what to do here (and I hope someone can explain what you would do) I instructed the user to enable verifier. After enabling verifier, they did not crash until shutting the system down, and it took exactly 10 minutes to do so before a crash happened and the DMP was generated.
The verifier dump is a violation bugcheck (c4), however, it's ntkrnlmp.exe and here are the arguments:
here is the dump - https://skydrive.live.com/redir?resid=DED77542B4FC4992!133&authkey=!AOOFdkuLlPxa-6k
Code:
Arg1: 0000000000000115, System didn't finish shutting down in a long time.
Arg2: fffffa80113cd880, The address of the thread responsible for the shutdown, that might be deadlocked.
Arg3: 0000000000000000
Arg4: 0000000000000000
I am assuming arg1 corresponds with what was said earlier in the 9F -
A driver has failed to complete a power IRP within a specific time (usually 10 minutes).
However, arg2, I am not sure what that means. That's new terminology for me, and I don't think I am that far into Windows Internals yet :tongue10:
So, just experimenting, I tried running a !locks and got the following:
Code:
0: kd> !locks
**** DUMP OF ALL RESOURCE OBJECTS ****
fffff8039d50ba30: Unable to get value of ExpSystemResourcesList
???? Do we need a kernel dump for things like locks?
I then ran a !poaction to try and get some info on what drivers have power IRPs pending:
Code:
0: kd> !poaction
Error reading PopAction
Allocated power irps (PopIrpList - fffff8039d513900)
Error resolving nt!_LIST_ENTRY...
Irp worker threads (PopIrpThreadList - fffff8039d512f60)
Error resolving nt!_LIST_ENTRY...
Error resolving nt!_POP_CURRENT_BROADCAST...
Not too sure what this means~
I tried running a !deadlock:
Code:
0: kd> !deadlock
Deadlock detection not initialized
I assume this is one of the verifier settings we can tell the user to check before initializing verifier?
Overall, any guidance or teaching in regards to what I am looking at or trying to deal with here would be more than appreciated.
Finally, here's the thread just in case any want to pop in and read what the OP has stated for info - DRIVER_POWER_STATE_FAILURE (9f) - Microsoft Community
Last edited: