DRIVER_POWER_STATE_FAILURE bug 檢查的值為 0x0000009F。 此bug檢查指示驅動程序處於不一致或無效的電源狀態。
這很重要
本文適用於程式設計人員。 如果您是在使用計算機時收到藍色螢幕錯誤碼的客戶,請參閱 針對藍螢幕錯誤進行疑難解答。
DRIVER_POWER_STATE_FAILURE參數
參數 1 表示衝突的類型。
參數 1 | 參數 2 | 參數 3 | 參數 4 | 原因 |
---|---|---|---|---|
0x1 | 設備物件 | 已保留 | 已保留 | 正在釋放的設備物件仍具有尚未完成的電源請求。 |
0x2 | 目標裝置的 device 物件(如果可用) | 設備物件 | driver 物件(如果可用) | 設備物件完成了系統電源狀態請求的 I/O 請求數據包 (IRP) ,但它未調用 PoStartNextPowerIrp。 |
0x3 | 堆疊的實體裝置物件 (PDO) |
nt!_TRIAGE_9F_POWER 。 |
被阻止的 IRP | 設備物件阻止 IRP 的時間過長。 |
0x4 | 超時值(以秒為單位)。 | 當前持有隨插即用 (PnP) 鎖的線程。 |
nt!_TRIAGE_9F_PNP 。 |
電源狀態轉換超時,等待與 PnP 子系統同步。 |
0x5 | 堆疊的物理設備物件 | POP_FX_DEVICE物件 | 保留 - 0 | 設備未能在所需時間內完成定向電源轉換。 |
0x6 | POP_FX_DEVICE物件 | 指示這是 Directed Power Down(1) 還是 Power Up(0) 完成。 | 保留 - 0 | 設備未成功完成其 Directed Power Transition 回調。 |
0x500 | 已保留 | 目標裝置的 device 物件(如果可用) | 裝置物件 | 設備物件完成了系統電源狀態請求的 IRP,但它未調用 PoStartNextPowerIrp。 |
原因
有關可能原因的描述,請參閱Parameters部分中每個代碼的描述。 常見的原因包括:
- 釋放了設備物件,併發出未完成的電源請求
- 電源狀態轉換超時
- 阻止 IRP 的設備物件
- 已完成 IRP,但未調用 PoStartNextPowerIrp
解決辦法
要確定具體原因並創建代碼修復,需要具備程式設計經驗並訪問故障模組的原始程式碼。
當 Parameter 1 等於 0x3 時調試 bug 檢查0x9F
- 在內核調試器中,使用 !analyze -v 命令執行初始 bug 檢查分析。 詳細分析顯示 nt!TRIAGE_9F_POWER 結構,位於Arg3中。
kd>!analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time.
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
Arg2: fffffa8007b13440, Physical Device Object of the stack
Arg3: fffff8000386c3d8, nt!_TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack
Arg4: fffffa800ab61bd0, The blocked IRP
如果可以識別導致錯誤的驅動程式,則其名稱將列印在藍屏上,並存儲在記憶體中的位置 (PUNICODE_STRING) KiBugCheckDriver。 您可以使用 dx (顯示除錯器物件模型表示式) (一個除錯器命令)來顯示以下內容: dx KiBugCheckDriver
.
nt!TRIAGE_9F_POWER結構提供了其他bug檢查資訊,這些資訊可能有助於確定此bug檢查的原因。 該結構可以提供所有未完成的電源 IRP 的清單、所有電源 IRP 工作線程的清單以及指向延遲系統工作線程佇列的指標。
- 使用 dt(顯示類型) 命令並指定 nt!TRIAGE_9F_POWER 結構中使用Arg3中的位址。
0: kd> dt nt!_TRIAGE_9F_POWER fffff8000386c3d8
+0x000 Signature : 0x8000
+0x002 Revision : 1
+0x008 IrpList : 0xfffff800`01c78bd0 _LIST_ENTRY [ 0xfffffa80`09f43620 - 0xfffffa80`0ad00170 ]
+0x010 ThreadList : 0xfffff800`01c78520 _LIST_ENTRY [ 0xfffff880`009cdb98 - 0xfffff880`181f2b98 ]
+0x018 DelayedWorkQueue : 0xfffff800`01c6d2d8 _TRIAGE_EX_WORK_QUEUE
dt (Display Type) 命令顯示結構。 可以使用各種調試器命令來遵循 LIST_ENTRY 欄位來檢查未完成的 IRP 清單和電源 IRP 工作線程。
- 使用 !irp 命令檢查被阻止的 IRP。 此 IRP 的地址位於 Arg4 中。
0: kd> !irp fffffa800ab61bd0
Irp is active with 7 stacks 6 is current (= 0xfffffa800ab61e08)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace.
cmd flg cl Device File Completion-Context
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
>[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
0 e1 fffffa800783f060 00000000 00000000-00000000 pending
\Driver\HidUsb
Args: 00016600 00000001 00000004 00000006
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-fffffa800ad00170
Args: 00000000 00000000 00000000 00000000
- 將 !devstack 命令與 Arg2 中的 PDO 位址一起使用,以顯示與故障驅動程式相關的資訊。
0: kd> !devstack fffffa8007b13440
!DevObj !DrvObj !DevExt ObjectName
fffffa800783f060 \Driver\HidUsb fffffa800783f1b0 InfoMask field not found for _OBJECT_HEADER at fffffa800783f030
> fffffa8007b13440 \Driver\usbhub fffffa8007b13590 Cannot read info offset from nt!ObpInfoMaskToOffset
!DevNode fffffa8007ac8a00 :
DeviceInst is "USB\VID_04D8&PID_0033\5&46fa7b7&0&1"
ServiceName is "HidUsb"
- 使用 !poaction 命令顯示處理電源作的線程和任何分配的電源 IRP。
3: kd> !poaction
PopAction: fffff801332f3fe0
State..........: 0 - Idle
Updates........: 0
Action.........: None
Lightest State.: Unspecified
Flags..........: 10000003 QueryApps|UIAllowed
Irp minor......: ??
System State...: Unspecified
Hiber Context..: 0000000000000000
Allocated power irps (PopIrpList - fffff801332f44f0)
IRP: ffffe0001d53d8f0 (wait-wake/S0), PDO: ffffe00013cae060
IRP: ffffe0001049a5d0 (wait-wake/S0), PDO: ffffe00012d42050
IRP: ffffe00013d07420 (set/D3,), PDO: ffffe00012daf840, CURRENT: ffffe00012dd5040
IRP: ffffe0001e5ac5d0 (wait-wake/S0), PDO: ffffe00013d33060
IRP: ffffe0001ed3e420 (wait-wake/S0), PDO: ffffe00013c96060
IRP: ffffe000195fe010 (wait-wake/S0), PDO: ffffe00012d32050
Irp worker threads (PopIrpThreadList - fffff801332f3100)
THREAD: ffffe0000ef5d040 (static)
THREAD: ffffe0000ef5e040 (static), IRP: ffffe00013d07420, DEVICE: ffffe00012dd5040
PopAction: fffff801332f3fe0
State..........: 0 - Idle
Updates........: 0
Action.........: None
Lightest State.: Unspecified
Flags..........: 10000003 QueryApps|UIAllowed
Irp minor......: ??
System State...: Unspecified
Hiber Context..: 0000000000000000
Allocated power irps (PopIrpList - fffff801332f44f0)
IRP: ffffe0001d53d8f0 (wait-wake/S0), PDO: ffffe00013cae060
IRP: ffffe0001049a5d0 (wait-wake/S0), PDO: ffffe00012d42050
IRP: ffffe00013d07420 (set/D3,), PDO: ffffe00012daf840, CURRENT: ffffe00012dd5040
IRP: ffffe0001e5ac5d0 (wait-wake/S0), PDO: ffffe00013d33060
IRP: ffffe0001ed3e420 (wait-wake/S0), PDO: ffffe00013c96060
IRP: ffffe000195fe010 (wait-wake/S0), PDO: ffffe00012d32050
Irp worker threads (PopIrpThreadList - fffff801332f3100)
THREAD: ffffe0000ef5d040 (static)
THREAD: ffffe0000ef5e040 (static), IRP: ffffe00013d07420, DEVICE: ffffe00012dd5040
如果使用的是 KMDF 驅動程式,請使用 Windows 驅動程式框架擴展 (!wdfkd) 收集其他資訊。
使用 !wdfkd.wdflogdump<您的驅動程式名稱>,查看 KMDF 是否正在等待您確認任何掛起的請求。
使用 !wdfkd.wdfdevicequeues<您的 WDFDEVICE> 檢查所有未完成的請求以及它們所處的狀態。
使用 !stacks 擴展檢查每個線程的狀態,並查找可能阻礙電源狀態轉換的線程。
為了幫助您確定錯誤的原因,請考慮以下問題:
- 物理設備物件 (PDO) 驅動程式 (Arg2) 的特徵是什麼?
- 你能找到被阻止的線程嗎? 當您使用 !thread debugger 命令檢查線程時,該線程由什麼組成?
- 是否有與阻止它的線程關聯的IO? 堆疊上有哪些符號?
- 當您檢查被阻止的電源 IRP 時,您會注意到什麼?
- Power IRP 的 PnP 次要功能代碼是什麼?
調試 bug 檢查0x9F當 Parameter 1 等於 0x4 時
- 在內核調試器中,使用 !analyze -v 命令執行初始 bug 檢查分析。 詳細分析顯示 nt!TRIAGE_9F_PNP 結構,位於參數 4 (arg4) 中。
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time (usually 10 minutes).
Arguments:
Arg1: 00000004, The power transition timed out waiting to synchronize with the Pnp
subsystem.
Arg2: 00000258, Timeout in seconds.
Arg3: 84e01a70, The thread currently holding on to the Pnp lock.
Arg4: 82931b24, nt!TRIAGE_9F_PNP on Win7
nt!TRIAGE_9F_PNP結構提供了其他bug檢查資訊,這些資訊可能有助於確定錯誤的原因。 nt!TRIAGE_9F_PNP結構提供指向結構的指標,該結構包含已調度 (但未完成的) PnP IRP 清單,並提供指向延遲系統輔助角色佇列的指標。
- 使用 dt(顯示類型) 命令並指定
nt!_TRIAGE_9F_PNP
您在 Arg4 中找到的結構和位址。
kd> dt nt!_TRIAGE_9F_PNP 82931b24
+0x000 Signature : 0x8001
+0x002 Revision : 1
+0x004 CompletionQueue : 0x82970e20 _TRIAGE_PNP_DEVICE_COMPLETION_QUEUE
+0x008 DelayedWorkQueue : 0x829455bc _TRIAGE_EX_WORK_QUEUE
dt (Display Type) 命令顯示結構。 可以使用調試器命令按照 LIST_ENTRY 字段檢查未完成的 PnP IRP 清單。
為了幫助您確定錯誤的原因,請考慮以下問題:
是否有與線程關聯的 IRP?
CompletionQueue 中是否有任何 IO?
堆疊上有哪些符號?
請參閱上面參數 0x3 中描述的其他技術。
備註
如果您無法使用上述技術來調試此問題,則可以使用一些基本的故障排除技術。
如果最近新增了新的設備驅動器或系統服務,請嘗試移除或更新它們。 嘗試判斷系統中導致出現新錯誤檢查程式代碼的變更。
查看 設備管理員 ,查看是否有任何設備標有感嘆號 (!)。 查看驅動程式屬性中顯示的事件日誌,瞭解任何出現故障的驅動程式。 請嘗試更新相關的驅動程式。
檢查事件查看器中的系統日誌是否有其他錯誤消息,這些消息可能有助於查明導致錯誤的設備或驅動程式。 在與藍色畫面相同的時間範圍中,尋找系統記錄檔中發生的嚴重錯誤。
要嘗試找出原因,請使用控制面板的power options 暫時禁用Power Save。 一些驅動程式問題與系統休眠狀態和暫停和恢復電源有關。
如果您最近將硬體新增至系統,請嘗試移除或取代它。 或者,請洽詢製造商以查看是否有任何修補程式可供使用。
您可以嘗試執行系統製造商所提供的硬體診斷。
請與製造商聯繫,查看是否有更新的系統 ACPI/BIOS 或其他固件可用。
另請參閱
使用 Windows 調試程式(WinDbg)進行記憶體傾印分析
使用 WinDbg 分析 Kernel-Mode 傾印檔案