共用方式為


錯誤檢查0x9F:DRIVER_POWER_STATE_FAILURE

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 傾印檔案

錯誤檢查代碼參考