現象
WindowsノートPCのふたを閉じてスリープさせたまま、AC電源に接続していない状態にしておくと、ランダムに1〜3時間ほど経過した後に、この問題が発生する。
ふたを開けて電源ボタンを押してもノートPCが正常に起動せず、1〜3分ほど経つとブルースクリーンになり、DRIVER_POWER_STATE_FAILURE (0x9F) というエラーコードが表示される。その後、2〜5分の自己診断を経て完全に再起動する。
これが起きるとワークフローが大幅に中断される。再起動後はすべてのワークスペースとソフトを開き直さなければならない。特に中国のクソみたいなWeChat系のアプリは、毎回スマホを取り出して手動でQRコードを読み取らなければならない。しかもそのあとしばらく情報の同期に時間がかかり、時には情報が失われることもある。
こういうことが一度あると、ようやく作業環境を整えて再開できるまでにほぼ30分かかる。
調査
これまで、Windowsの何らかのアップデートで入った変なバグか、ハードウェアの相性問題だと思っていた。今日さすがに我慢できなくなって、具体的に何が問題なのか調べてみることにした。
幸い今はAIがいる。自分で検索して妥当な調査手順を組み立てられれば、ほとんどの情報はAIに聞けばいいので、ゼロから勉強しなくて済む。
主な参考記事はこちら。
ブルースクリーン発生時に保存されるWindowsのクラッシュ記録ファイル（Dump）の分析手順が紹介されている。このDumpファイル群は C:\Windows\Minidump にある。権限の問題を避けるため、コピーを外の場所に作ってから分析する。
WinDbg
WindowsにはWinDbgというツールがある。参考記事で紹介されているバージョンは少し古いので、WinDbgの基本的な使い方を一通り調べる必要があった。
Microsoft公式のインストールガイド WinDbg のインストール - Windows drivers | Microsoft Learn がある。一番手っ取り早いのはターミナルのコマンドでインストールする方法で、ターミナルで以下を実行する。
winget install Microsoft.WinDbg
ターミナル環境が使えない場合は、ガイドにある他の方法を選んでもいい。インストールが完了したら、スタートメニューのアプリ一覧からWinDbgを検索すれば起動できる。
参考記事とは異なり、新しいバージョンのWinDbgは操作方法や設定項目名が少し違うので、以下で順に説明する。
Dumpファイルを取り込んで分析する前に、事前設定が必要になる。
まず左上のFileをクリックする。
次にSettingsをクリックし、表示されたページのDebugging settingsを開く。その中のSymbol pathを次のように設定する。
srv*C:\Symbols*http://msdl.microsoft.com/download/symbols
ここで、私の操作方法はすでに参考記事と違っている。Microsoft系のこういう小さなソフトは、今後のアップデートで操作の流れがまた変わるかもしれない。
要は、Symbolというキーワードに関連する設定項目を前もって設定しておけばいい。
次にStart debuggingへ移動し、その中のOpen dump fileをクリックする。このスクリーンショットではグレーアウトしているが、それはdump分析を実行中で、ファイルを保存も閉じもしていないからだ。
この手順の操作も必ずしも同じではない。要はOpen dumpというキーワードを見つければいい。
うまく開けると、ヘッダー情報がいくつか出力され、正式に分析するためのコマンドを実行するよう促される。
あとはコマンドを打って分析を始めるだけ。
!analyze -v
注意：この分析はそれなりの時間がかかり、進捗は一切表示されない。「Debugging Details:」の後の情報がすべて出力されるまで気長に待つこと。分析が完了すると、「Debugging Details:」の情報は途切れず一気に出力される。
あとは、出力された分析情報をまとめてそのままAIに投げて分析してもらえばいい。正直、私自身もまったく理解していない。
今回の問題の分析結果
AIによる分析結果は次のとおり。
∴ 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