Symptoms
Scenario: a Windows laptop is left sleeping with its lid closed and no power connected. After a random 1–3 hours...
When you open the lid and press the power button, the laptop won't start normally. After 1–3 minutes, it blue-screens with the error code DRIVER_POWER_STATE_FAILURE (0x9F), then goes through a 2–5 minute self-check and fully reboots.
This is really disruptive to my workflow. After the reboot, every workspace and app has to be reopened—especially that shitty Chinese software, the WeChat family. I have to pull out my phone again, scan a QR code, wait for it to sync messages for a while, and sometimes it even loses messages.
An incident like this costs nearly half an hour before I can get everything back into working order and start over.
Troubleshooting
I had always thought it was some weird bug introduced by a Windows update, or some kind of hardware incompatibility. Today I got fed up and decided to find out what was actually going on.
Thankfully, there's AI to help now. As long as I do my own searching and plan a reasonable troubleshooting path, I can ask an AI about most of the information instead of learning it all from scratch.
The main reference article is
It explains how to analyze the Windows crash Dump files saved during a blue screen. These files are located in C:\Windows\Minidump. To avoid permission issues, I copied one out and analyzed it elsewhere.
WinDbg
Windows has the WinDbg tool. The version in the reference article is relatively old, so I needed to do some basic exploring of how to use WinDbg.
Microsoft provides an official installation guide: Install WinDbg - Windows drivers | Microsoft Learn. The quickest and easiest way is to install it with a terminal command. Run this in the terminal:
winget install Microsoft.WinDbg
If your terminal environment isn't available, you can also use the other methods in the guide. Once installed, search for WinDbg in the app list in the Start menu and open it.
Unlike the reference article, the newer WinDbg has some differences in how you operate it and in the names of its settings. I'll walk through it step by step below.
Before formally loading a Dump file for analysis, you need to do some pre-configuration.
First, click File in the upper-left corner.
Then click Settings, open Debugging settings on the popup page, and set its Symbol path to
srv*C:\Symbols*http://msdl.microsoft.com/download/symbols
At this point, my approach already differs from the reference article. These little Microsoft utilities may have their operation logic changed again in future updates.
The principle is just to pre-configure the setting associated with the keyword Symbol.
Then go to Start debugging and click Open dump file. It's grayed out in my case because I'm in the middle of a dump analysis and haven't saved or closed the file yet.
The operation flow may not be the same either; the principle is to find the keyword Open dump.
If it opens successfully, you'll see some header information output and a prompt to run the corresponding command for the formal analysis.
Just type the command and start:
!analyze -v
Note that this analysis takes a while and doesn't give you any progress prompts. Be patient and wait until the information after Debugging Details: has been fully printed. Once the analysis finishes, the Debugging Details: information is output in one uninterrupted go.
Then you can copy the whole output and hand it to an AI as one batch for analysis. Honestly, I can't understand any of it either.
Analysis Conclusion for My Problem
Here is the analysis conclusion the AI gave.
∴ The user has provided the complete !analyze -v output along with the !devobj and !irp commands I requested. Now I can
give a comprehensive analysis.
Let me parse the key findings:
1. Bug Check: 0x9F (DRIVER_POWER_STATE_FAILURE) with Arg1=3 (device object blocking IRP too long)
2. IMAGE_NAME: pci.sys
3. FAILURE_BUCKET: 0x9F_3_POWER_DOWN_nipcibrd_IMAGE_pci.sys
4. DRVPOWERSTATE_SUBCODE: 3 — power down transition
5. STACK_TEXT: Shows nt!PopIrpWatchdogBugcheck → nt!PopIrpWatchdog — the power watchdog timer fired, meaning an IRP
was stuck too long
From !irp output:
- Current stack (stack 7): IRP_MJ_POWER(16), IRP_MN_SET_POWER(2) — this is a SET_POWER IRP
- The driver handling it is nipcibrd.sys — this is the National Instruments PCI/PXI bridge driver
- The status shows "Success Error Cancel pending" — the IRP is still pending
- The completion routine is nt!PopRequestCompletion
- The device stack shows: \Driver\nipcibrd → \Driver\pci → \Driver\ACPI
From !devobj:
- The PDO belongs to \Driver\pci
- Upper attached device is \Driver\ACPI
So the power IRP is going through: pci → ACPI → nipcibrd
The nipcibrd.sys driver has the pending IRP — it's not completing the power down request.
Let me give a thorough analysis.
● 完整分析结论
崩溃根因
肇事驱动：nipcibrd.sys — National Instruments PCI/PXI Bridge Driver
这是一个 National Instruments (NI) 的驱动，用于 NI 的 PCI/PXI 数据采集或仪器控制硬件。
---
证据链
┌──────────────────────┬──────────────────────────────────────────────────────────────────┐
│ 证据 │ 指向 │
├──────────────────────┼──────────────────────────────────────────────────────────────────┤
│ FAILURE_BUCKET │ 0x9F_3_POWER_DOWN_nipcibrd_IMAGE_pci.sys │
├──────────────────────┼──────────────────────────────────────────────────────────────────┤
│ IRP 当前栈 (stack 7) │ IRP_MJ_POWER(16), IRP_MN_SET_POWER(2) — 由 \Driver\nipcibrd 持有 │
├──────────────────────┼──────────────────────────────────────────────────────────────────┤
│ IRP 状态 │ Success Error Cancel pending — 仍在 pending，未完成 │
├──────────────────────┼──────────────────────────────────────────────────────────────────┤
│ 子代码 │ DRVPOWERSTATE_SUBCODE: 3 — 电源下降转换 (S0→S3/S4/关机) │
├──────────────────────┼──────────────────────────────────────────────────────────────────┤
│ 设备栈 │ nipcibrd → pci → ACPI │
└──────────────────────┴──────────────────────────────────────────────────────────────────┘
---
故障机制
1. 系统发起电源状态转换（睡眠/休眠/关机），向设备栈发送 IRP_MN_SET_POWER IRP
2. IRP 沿设备栈传递：ACPI → pci → nipcibrd
3. nipcibrd.sys 收到了这个电源 IRP，但没有在时限内完成它（一直保持 pending 状态）
4. 电源管理看门狗 (PopIrpWatchdog) 超时（默认约 10 分钟），触发 0x9F 蓝屏
调用栈也完全印证：
nt!PopIrpWatchdogBugcheck ← 电源看门狗触发蓝屏
nt!PopIrpWatchdog ← 检测到 IRP 超时
nt!KiProcessExpiredTimerList ← 定时器到期
nt!KiTimerExpiration
nt!KiRetireDpcList
nt!KiIdleLoop
---
解决建议
┌────────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ 优先级 │ 操作 │
├────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 1 立即 │ 更新 NI 驱动 — 去 ni.com/drivers 下载最新版 NI 设备驱动（NI-DAQmx、NI-VISA、或 NI-488.2，视你的 NI │
│ │ 硬件而定） │
├────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────┤
2. IRP 沿设备栈传递：ACPI → pci → nipcibrd
3. nipcibrd.sys 收到了这个电源 IRP，但没有在时限内完成它（一直保持 pending 状态）
4. 电源管理看门狗 (PopIrpWatchdog) 超时（默认约 10 分钟），触发 0x9F 蓝屏
调用栈也完全印证：
nt!PopIrpWatchdogBugcheck ← 电源看门狗触发蓝屏
nt!PopIrpWatchdog ← 检测到 IRP 超时
nt!KiProcessExpiredTimerList ← 定时器到期
nt!KiTimerExpiration
nt!KiRetireDpcList
nt!KiIdleLoop
---
解决建议
┌────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ 优先级 │ 操作 │
├────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 1 立即 │ 更新 NI 驱动 — 去 ni.com/drivers 下载最新版 NI 设备驱动（NI-DAQmx、NI-VISA、或 NI-488.2，视你的 NI 硬件而定） │
├────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 2 立即 │ 检查是否有 NI 硬件连接到这台电脑（PCI 卡、PXI 机箱、USB DAQ 等），确认固件也是最新的 │
├────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 3 检查 │ 运行 driverquery /v 查看 nipcibrd.sys 的版本号，当前崩溃版本 10.0.26100.8737 可能不兼容 Windows 11 24H2 │
├────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 4 临时 │ 如果暂时不需要 NI 硬件，可以在设备管理器中禁用 NI 相关设备，或卸载 NI 软件 │
├────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 5 长期 │ 在 NI 更新驱动之前，避免让系统进入睡眠状态（电源选项里关闭睡眠），可以减少触发概率 │
└────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
---
关键信息速查
肇事文件: nipcibrd.sys
发布者: National Instruments
崩溃类型: DRIVER_POWER_STATE_FAILURE (0x9F)
触发场景: 系统电源下降 (睡眠/休眠/关机)
系统: Windows 11 24H2 (Build 26100)
运行时长: 5 天 2 小时
这个崩溃发生在系统试图进入低功耗状态或关机时，NI PCI 桥驱动没有正确响应。如果你在使用 NI 的 DAQ、GPIB
或其他测量设备，这就是根本原因。
✻ Sautéed for 32s