Most of the time, bluescreens (if they are repeatable) are usually a driver and not something in the actual Windows. Some common suggestions to isolate the driver power state issue:
1. Very first thing to do is to get the latest driver first and see if it is still happening.
2. When the crashes are wake/sleep/resume/power related, often you should go to the device driver in the Device Manager and uncheck any ‘allow system to turn off the power of this device’ as a second step if the latest driver doesn't solve it. This prevents Windows from making calls into possibly faulty driver code. Power management issues are very common with drivers still.
3. If you get dumps and the crashes are different places every time or random in timing – then you might have bad memory or a bad motherboard that’s corrupting things.
Lets understand what is 0x9F DRIVER_POWER_STATE_FAILURE crash issue:
0x0000009F is a fairly common bug check that occurs when a device driver does not complete processing on an I/O Request Packet (IRP) in ~10 minutes. This can occur for a variety of reasons, but the main reasons are due to kernel-mode drivers not properly handling changes in power states
To transition between states, the system must return to state S0 (ex. Standby -> Hibernate is actually Standby - > Awake -> Hibernate). If devices and drivers do not correctly handle state transitions (or even queries about the current power state), it is possible for the system to crash with the DRIVER_POWER_STATE_FAILURE.
For most of these errors, the cause is fairly straightforward and the important information can be determined from a minidump.
Example:
Go to https://www.osronline.com/page.cfm?name=analyze and upload your minidump
To do a full analysis Download and install the Debugging Tools for Windows pack
run windbg.exe
0: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* DRIVER_POWER_STATE_FAILURE (9f) A driver is causing an inconsistent power state. Arguments: Arg1: 00000003, A device object has been blocking an Irp for too long a time Arg2: 88ce8d60, Physical Device Object of the stack Arg3: 82b2dae0, Functional Device Object of the stack Arg4: 88724df8, The blocked IRP Debugging Details: ------------------ *** WARNING: Unable to verify timestamp for ftdibus.sys *** ERROR: Module load completed but symbols could not be loaded for ftdibus.sys DRVPOWERSTATE_SUBCODE: 3 IMAGE_NAME: ftdibus.sys DEBUG_FLR_IMAGE_TIMESTAMP: 4ae0760c MODULE_NAME: ftdibus FAULTING_MODULE: 9275e000 ftdibus CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT BUGCHECK_STR: 0x9F PROCESS_NAME: System CURRENT_IRQL: 2 STACK_TEXT: 82b2da94 82a43054 0000009f 00000003 88ce8d60 nt!KeBugCheckEx+0x1e 82b2db00 82a428e8 82b2dba0 00000000 82b3a280 nt!PopCheckIrpWatchdog+0x1f5 82b2db38 82a7104d 82b48a20 00000000 61ef7a8f nt!PopCheckForIdleness+0x73 82b2db7c 82a70ff1 82b30d20 82b2dca8 00000001 nt!KiProcessTimerDpcTable+0x50 82b2dc68 82a70eae 82b30d20 82b2dca8 00000000 nt!KiProcessExpiredTimerList+0x101 82b2dcdc 82a6f20e 00063037 87b0bd48 82b3a280 nt!KiTimerExpiration+0x25c 82b2dd20 82a6f038 00000000 0000000e 00000000 nt!KiRetireDpcList+0xcb 82b2dd24 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x38 STACK_COMMAND: kb FOLLOWUP_NAME: MachineOwner FAILURE_BUCKET_ID: 0x9F_3_ftser2k_IMAGE_ftdibus.sys BUCKET_ID: 0x9F_3_ftser2k_IMAGE_ftdibus.sys Followup: MachineOwner ---------In this case, parameter 4 of the bugcheck is the IRP that is being blocked. We can look a little closer using the !irp extension command:
0: kd> !irp 88724df8
Irp is active with 4 stacks 2 is current (= 0x88724e8c)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace.
cmd flg cl Device File Completion-Context
[ 0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
>[ 16, 2] 0 0 88cf4038 00000000 00000000-00000000
Unable to load image \SystemRoot\system32\drivers\ftser2k.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ftser2k.sys
*** ERROR: Module load completed but symbols could not be loaded for ftser2k.sys
\Driver\FTSER2K
Args: 00012200 00000001 00000003 00000002
[ 16, 2] 0 e1 88cec3e8 00000000 82a90871-896502d8 Success Error Cancel pending
\Driver\Serenum nt!IopUnloadSafeCompletion
Args: 00012200 00000001 00000003 00000002
[ 0, 0] 0 0 00000000 00000000 00000000-87bbcf18
Args: 00000000 00000000 00000000 00000000
When we look at the failure bucket ID BUCKET_ID: 0x9F_3_ftser2k_IMAGE_ftdibus.sys
its shows that ftser2k is causing the issue.In this case, 2 pending IRPs are shown, the one with the > is the current IRP. In this case the problem was actually due to the ftser2k.sys driver (not the ftdibus.sys driver that was shown in the main !analyze -v output. This demonstrates an important point... Always check the IRP to determine the driver that is responsible for the hang.
There are many other debugging commands you can also use, and those are all outlined here. Hopefully this will help YOU out the next time some crazy bluescreen you can’t figure out; and you won’t be re-installing the OS to get rid of it.
---
Other resources:
-The official Microsoft list of bluescreen failure codes with documentation on each one:
http://msdn.microsoft.com/en-us/library/ff542347%28v=VS.85%29.aspx
-Another list of the various bluescreen failure codes and their plaintext sub-code descriptions with some notes from external folks:
http://www.faultwire.com/solutions_index/fatal_error-1.html#IssueList
-Microsoft Answers forum that has really responsive and informative threads on just about every blue-screen investigation ever done. These guys chew up minidumps all day and can help you track down just about anything that’s going on (if just searching the forum doesn’t do it for you automatically):
http://social.answers.microsoft.com/Forums/en-US/w7repair/threads
-Another Microsoft forum that seems to do a fair amount of this kind of debug work:
http://social.technet.microsoft.com/Forums/en/w7itproperf/threads
No comments:
Post a Comment