电脑出现蓝屏DRIVER_POWER_STATE_FAILURE怎么修复

蓝屏代码0x0000009F代表"DRIVER_POWER_STATE_FAILURE"，这意味着在电脑休眠、睡眠或关机过程中，发生了一个设备驱动程序的错误或冲突，导致系统崩溃并显示蓝屏错误。

要解决这个问题，可以尝试以下方法：

方法一：关闭电源管理选项

【资料图】

在控制面板中找到“电源选项”，将计算机的电源计划设置为“高性能”，禁用任何关于待机或休眠的选项。

方法二：检查受影响的设备

确定在出现蓝屏错误之前是否连接了任何新的外部设备或硬件,如果是，请尝试断开连接并查看是否仍然出现错误。

方法三：检查电源供应问题

检查电源适配器及其连接是否正常工作。

方法四：使用一键修复工具助手（强烈推荐）

1、首先你的电脑必须下载与完成安装完成快快蓝屏修复助手。如果你还没有安装点击下方链接下载。

下载地址：>>>快快蓝屏修复助手<<<

提示：安装路径不要选择C盘，避免产生问题造成损失。

2、找到你电脑中的快快蓝屏修复助手，点击进入。看到首页后，点击首页一键扫描按钮开始扫描。等待几分钟，就能获取你急切想要的结果。

3、扫描完成后会显示电脑的所有蓝屏记录以及蓝屏的详细信息。

4、解决方案页面显示了导致该次蓝屏的具体原因和解决方案，点击右上角的一键修复进行修复。

5、切记，当修复完成之后我们还是需要重新启动计算机的。毕竟一切修复的结果，需要重新后，才能被系统认可。

当你完成重启后，你电脑的蓝屏问题已经基本解决了。相信小编，不要急需卸载快快蓝屏修复助手。毕竟它强大的功能是你未来的一个保障，可以随时随地为你服务，让你再次遇到蓝屏问题不在抓狂。

其他相关信息：

DRIVER_POWER_STATE_FAILURE bug 检查 的值为 0x0000009F。 此 bug 检查指示驱动程序处于不一致或无效的电源状态。

DRIVER_POWER_STATE_FAILURE参数

参数 1 指示冲突的类型。

参数 1	参数 2	参数 3	参数 4	原因
0x1	设备对象	预留	预留	正在释放的设备对象仍具有尚未完成的未完成的电源请求。
0x2	目标设备的设备对象（如果可用）	设备对象	驱动程序对象（如果可用）	设备对象完成了系统电源状态请求的 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 对象	指示这是定向关闭电源 (1) 还是 (0) 完成。	已保留 - 0	设备未成功完成其定向电源转换回调。
0x500	保留	目标设备的设备对象（如果可用）	设备对象	设备对象已完成系统电源状态请求的 IRP，但它未调用 PoStartNextPowerIrp。

原因

有关可能原因的说明，请参阅参数部分中每个代码的说明。 常见原因包括：

设备对象释放，但未完成的电源请求未完成电源状态转换超时阻止 IRP 的设备对象已完成 IRP，但未调用 PoStartNextPowerIrp

解决方法

若要确定特定原因并创建代码修补程序，需要具有编程经验和对故障模块源代码的访问权限。

当参数 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！使用 Arg3 中的地址TRIAGE_9F_POWER结构。

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 (显示类型) 命令显示结构。 可以使用各种调试器命令来跟踪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.wdflog 转储<驱动程序名称>，查看 KMDF 是否正在等待你确认任何挂起的请求。

使用 ！wdfkd.wdfdevicequeues<你的 WDFDEVICE> 检查所有未完成的请求及其处于什么状态。

使用 ！stacks扩展检查每个线程的状态，并查找可能阻碍电源状态转换的线程。

为了帮助你确定错误的原因，请考虑以下问题：

(PDO) 驱动程序 (Arg2) 的物理设备对象有哪些特征？你能找到被阻止的线程吗？ 使用 ！threaddebugger 命令检查线程时，线程由什么组成？是否存在与阻止它的线程关联的 IO？ 堆栈上有哪些符号？检查受阻电源 IRP 时，你注意到了什么？电源 IRP 的 PnP 次要函数代码是什么？

当参数 1 等于 0x4 时调试 bug 检查 0x9F

在内核调试器中，使用 ！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 (显示类型) 命令显示结构。 可以使用调试器命令按照LIST_ENTRY字段来检查未完成的 PnP IRP 的列表。

为了帮助你确定错误的原因，请考虑以下问题：

是否有与线程关联的 IRP？

CompletionQueue 中是否有 IO？

堆栈上有哪些符号？

请参阅上述参数0x3下所述的其他技术。

备注

如果你没有能力使用上述技术来调试此问题，则可以使用一些基本的故障排除技术。

如果最近添加了新的设备驱动程序或系统服务，请尝试删除或更新它们。 尝试确定系统中导致新 Bug 检查代码出现的原因。

查看设备管理器，查看是否有任何设备标有感叹号 (！) 。 查看驱动程序属性中显示的事件日志，了解是否有任何故障驱动程序。 请尝试更新相关驱动程序。

检查事件查看器中的系统日志，以获取可能有助于查明导致错误的设备或驱动程序的其他错误消息。 有关详细信息，请参阅打开事件查看器。 在系统日志中查找与蓝屏同时出现的严重错误。

若要尝试找出原因，请使用控制面板、电源选项暂时禁用节电。 某些驱动程序问题与系统休眠的各种状态以及电源的挂起和恢复有关。

如果最近向系统添加了硬件，请尝试删除或替换它。 或与制造商联系，查看是否有可用的修补程序。

你可尝试运行系统制造商提供的硬件诊断。

请与制造商核实是否有更新的系统 ACPI/BIOS 或其他固件可用。

另请参阅

使用 Windows 调试器 (WinDbg) 进行故障转储分析

使用 WinDbg 分析内核模式转储文件

Bug 检查代码参考

关键词：