DRIVER_POWER_STATE_FAILURE 0x9F 藍屏解決教學

文章屬性:疑難排除(Windows 底層除錯)
適用系統:Windows 10 / Windows 11(24H2、25H2 介面相同)
難易度 / 耗時:⭐⭐(進階手段 ⭐⭐⭐)/ 約 20 分鐘
核心結論:DRIVER_POWER_STATE_FAILURE(0x9F)是某支驅動程式在睡眠、喚醒或關機的電源切換時,沒有在時限內完成電源 IRP 被系統中止,不是記憶體壞、也不是要重灌;先更新或回復顯示卡、網路卡、USB 這幾類驅動程式即可。
適用對象:睡眠、休眠、喚醒或關機時跳這個藍色當機畫面的人

📌 快速答案

一句話答案:DRIVER_POWER_STATE_FAILURE(0x9F)代表某支驅動程式在系統睡眠、喚醒或關機時,沒能在時限內完成電源 IRP 而被核心中止;先更新或回復顯示卡、網路卡與 USB 驅動程式,再用事件檢視器縮小範圍,通常就能解決,不必換記憶體或重灌。

🧰 開始前的準備

適用系統:Windows 10 / 11(本文操作在 24H2、25H2 介面相同)
權限需求:更新驅動程式與看事件檢視器只要一般使用者;powercfg、Driver Verifier 段落需要系統管理員
需要工具:裝置管理員、事件檢視器(Event Viewer)、各廠牌官方驅動程式;進階段落用到 Windows 內建的 verifier 與(選用)WinDbg
預計耗時:基本排查約 20 分鐘,Driver Verifier 壓力測試視情況數小時

⚠️ 高風險提醒:本文「方法三 Driver Verifier」屬 ⭐⭐⭐ 操作,設定錯誤可能讓系統開機就反覆藍屏。動手前務必先看文末「🔙 萬一翻車」與停止條件,並確認你能進得去安全模式。

🔍 症狀描述與錯誤訊息

先講你會看到什麼: 電腦在進入睡眠、從睡眠喚醒、或按下關機的那一瞬間,螢幕突然變成藍底,底下白字寫著停止代碼,重開機後在事件檢視器留下一筆 BugCheck 記錄。典型畫面文字是:

🙁 你的裝置發生問題,需要重新啟動。
停止代碼(Stop code):DRIVER_POWER_STATE_FAILURE

這個當機最典型的觸發時機,就是電源狀態切換:蓋上筆電上蓋要睡眠時、闔蓋放進包包一陣子後、早上打開喚醒時、或選了「關機」畫面卻卡住然後藍屏。對應的十六進位代碼是 0x0000009F,四個參數裡的第一個(Parameter 1)是判斷方向的關鍵,等一下會拆給你看。根據微軟官方除錯文件與 Tom’s Hardware 等權威媒體的整理,這也是 Windows 10 / 11 上最常見的藍屏之一,而且幾乎都指向過舊或不相容的驅動程式。

🔎 問題根因

一句話根因:某支驅動程式在系統要切換電源狀態時,沒有在規定時間內把「電源 IRP」處理完,被核心判定卡死而強制當機。 微軟官方對 0x9F 的定義很直白——「驅動程式處於不一致或無效的電源狀態(the driver is in an inconsistent or invalid power state)」,而 !analyze -v 的說明更具體:「某個驅動程式未能在特定時間內(通常是 10 分鐘)完成一個電源 IRP」。

翻成白話:當你要睡眠或關機,Windows 的電源管理員會對每一個裝置發出一張「請切換到低耗電狀態」的公文(這張公文就是電源 IRP),每支驅動程式都要簽收、處理完、再往下傳。只要其中一支拖著不辦、或辦到一半卡住,整條隊伍就卡在那裡;系統等不到,只好觸發 0x9F 把自己停下來,避免半睡半醒狀態把資料寫壞。

換句話說,藍屏是結果,真正的病灶是那支拖延的驅動程式——通常是顯示卡、網路卡、USB 或晶片組(PCI)的驅動程式版本太舊、跟新版 Windows 的電源模型不合。所以解法方向永遠是「找出並更新/回復那支驅動程式」,而不是砍系統檔或重灌。想從當機當下的 minidump 直接把那支驅動程式的名字挖出來,可以搭配站長的〈WinDbg 藍畫面 minidump 分析教學〉一起看。

🔬 底層機制:這個錯誤訊號到底從哪裡來?

這段是重點,搞懂它你就不會被網路上「跑個 SFC 就好」的萬用答案帶偏。 0x9F 走的是 Windows 的電源管理(Power Management)這條路,和一般執行期當機不同。

當系統要進入睡眠(S3)、休眠(S4)或關機時,電源管理員會沿著每一個「裝置堆疊(device stack)」由上往下送出 電源 IRP(IRP_MJ_POWER)。每支驅動程式收到後,要把自己的硬體安全帶到指定的低耗電狀態,然後完成(complete)這張 IRP 讓流程往下走。若有一支驅動程式遲遲不完成,系統會等到逾時,再由核心呼叫 KeBugCheckEx 帶著代碼 0x9F 把整台機器停住。

微軟官方文件把 0x9F 依 Parameter 1 分成幾種子類型,實務上最常見的是這兩種:

Parameter 1 = 0x3:某個裝置物件「把一張 IRP 卡住太久」。此時 Parameter 2 是那條堆疊的實體裝置物件(PDO)、Parameter 4 是被卡住的那張 IRP。這種最有機會對應到「某一支」具體驅動程式。
Parameter 1 = 0x4:電源狀態切換在「跟隨插即用(PnP)子系統同步」時逾時。Parameter 2 是逾時秒數(官方範例是 0x258,也就是 600 秒 = 10 分鐘),Parameter 3 是當時握著 PnP 鎖的執行緒。

如果你打得開 WinDbg,官方建議的追法是:先 !analyze -v,再用 !irp 看被卡住的那張 IRP(位址在 Arg4)、用 !devstack 看出事的裝置堆疊(位址在 Arg2)、用 !poaction 列出所有還沒完成的電源 IRP 與處理它們的執行緒;新版核心還能用 dx KiBugCheckDriver 直接印出被點名的驅動程式名稱。知道這個有什麼用? 你就明白為什麼「換記憶體」「重灌」大多沒用——問題不在資料層,而在某支驅動程式的電源處理流程卡住了。方向對了,才不會白花錢跟時間。

🛠️ 解決方案

⚠️ 以下方法由簡到難。先做完方法一、二再考慮方法三;方法三 Driver Verifier 是 ⭐⭐⭐ 高風險工具,非必要不建議新手直接上。

方法一:更新或回復最常出事的四類驅動程式(成功率最高)

先處理這四類就對了:顯示卡、網路卡(含 Wi-Fi)、USB 控制器、晶片組/PCI 驅動程式。 微軟官方的除錯範例裡,卡住電源 IRP 的正是一顆 USB HID 裝置(\Driver\HidUsb 掛在 \Driver\usbhub 底下);而 Tom’s Hardware 與微軟社群大量案例則點名顯示卡驅動程式、網路卡驅動程式與 pci.sys 相關驅動程式是最常見元兇。

關鍵判斷:如果藍屏是最近某次更新之後才開始的(不管是 Windows Update 還是你自己裝的驅動程式),優先懷疑那支,回復到上一版往往比更新更快見效。
更新:到顯示卡官網(NVIDIA / AMD / Intel)、網路卡或主機板廠商官網,抓最新版驅動程式乾淨安裝,不要用來路不明的「一鍵驅動更新」工具。
回復:開始按右鍵 → 裝置管理員 → 找到可疑裝置 → 右鍵內容 → 「驅動程式」分頁 → 「回復驅動程式」。

💡 為什麼要這樣做? 0x9F 的本質是「驅動程式跟不上系統的電源模型」,而不是系統檔壞掉。把那支驅動程式換成與現行 Windows 相容的版本,才是打在點上。

方法二:事件檢視器抓兇手 + 停用電源節能選項縮小範圍

如果方法一沒有立刻解決,就靠系統日誌與排除法。 打開事件檢視器(開始 → 搜尋「事件檢視器」),看「Windows 記錄 → 系統」,把時間對到當機那一刻前後,找 BugCheck、Error 等級的紀錄,常會點名某個裝置或驅動程式檔名——這是官方也建議的第一步。

微軟官方另外建議:暫時停用電源節能相關設定來隔離問題,因為 0x9F 常跟睡眠、休眠與喚醒的狀態切換有關。實務上最值得先關的兩個:

USB 選擇性暫停:控制台 → 電源選項 → 變更計劃設定 → 變更進階電源設定 → USB 設定 → USB 選擇性暫停設定 → 停用。
快速啟動 / 休眠:很多睡眠、關機相關的驅動程式卡死,和「快速啟動(其實是把核心休眠起來)」有關。要不要整個關掉、以及睡眠與休眠的差別,可以參考站長這篇〈徹底關閉 Windows 睡眠、改用休眠的設定〉。以系統管理員開啟終端機,關閉休眠與快速啟動的指令是:

# 關閉休眠(連帶關掉「快速啟動」);要還原改成 powercfg /h on
powercfg /h off

同時可以用「排除法」:最近插了什麼新硬體(外接硬碟、擴充卡、USB 音效卡、Hub、擴充基座)就先拔掉觀察。每次只動一項,才知道到底是誰。

方法三:Driver Verifier 強制揪出兇手驅動程式(⭐⭐⭐ 進階)

⚠️ 這是高風險工具。 Driver Verifier 會故意對驅動程式施壓,若真有問題驅動程式,系統可能開機就藍屏。務必先確認:你能進安全模式、資料已備份、不是公司/學校管控機。看不懂或沒把握,請停在方法二。

當「一直藍屏但事件檢視器指不出明確驅動程式」時,才動用 Driver Verifier(內建 verifier)。以系統管理員開啟命令提示字元,先查目前設定:

# 唯讀:先查目前有沒有已啟用的 Verifier 設定
verifier /querysettings

要啟動圖形介面設定:執行 verifier → 選「建立自訂設定」→ 勾選標準測試項 → 選「自動選取這台電腦上安裝的所有未簽署/協力廠商驅動程式」(建議只驗協力廠商驅動程式,不要全驗)→ 重開機開始壓力測試。若觸發藍屏,產生的 minidump 用 WinDbg 跑 !analyze -v 就能看到被點名的模組,詳細讀法見前面提到的 minidump 教學。

測完一定要關掉,否則會持續拖慢並可能當機:

# 關閉所有 Driver Verifier 設定(測完務必執行)
verifier /reset

✅ 驗證修復結果

怎麼算真的修好?看兩件事。 第一,穩定度:回到你原本最容易觸發的情境——反覆做幾次「睡眠→喚醒」、闔蓋再開、正常關機再開機——連續幾天不再藍屏,才算數;0x9F 有時是偶發,當下不當不代表解決。第二,日誌乾淨:事件檢視器「系統」記錄不再新增 BugCheck 或同一支驅動程式的錯誤,C:\Windows\Minidump\ 也沒有新的 .dmp 檔產生。兩者都過,才把它當結案。

🔙 萬一翻車:回退步驟

(針對方法三 Driver Verifier,或更新驅動程式後開不了機)

情境一:啟用 Verifier 後開機就藍屏

進「安全模式」(開機三次失敗會自動進 WinRE →「疑難排解 → 進階選項 → 啟動設定 → 重新開機 → 按 4 / F4 進安全模式」),開系統管理員命令提示字元執行 verifier /reset,重開即可回到正常。

情境二:更新或回復驅動程式後裝置異常

裝置管理員找到該裝置 → 右鍵內容 → 「驅動程式」分頁 → 「回復驅動程式」,退回上一版;若是自己更新造成的,也可用「解除安裝裝置」後重開機讓 Windows 重新裝回。

情境三:完全進不了系統

用另一台電腦做 Windows 安裝隨身碟,開機進 WinRE →「疑難排解 → 進階選項 → 系統還原」,還原到出事前的還原點。

💡 總結:預防再次發生

站長我的原則:0x9F 是「驅動程式電源健康」的體檢紅燈,不是絕症。 遇到它先冷靜,九成不是硬體壞掉,而是某支驅動程式跟不上系統的電源切換。長期預防就三招:一是顯示卡、網路卡、晶片組驅動程式維持在官方新版,尤其大版本更新 Windows(例如升上 24H2、25H2)後主動更新一輪;二是別亂裝「一鍵驅動更新」工具,那類工具塞的舊版/魔改驅動程式,正是電源 IRP 卡死的溫床;三是新硬體與擴充基座逐一測試,不要一次插一堆再來猜。若更新驅動程式後仍反覆發作,官方也建議檢查主機板廠商有沒有更新的 ACPI / BIOS 韌體。

⚠️ 待補實測:本文為工具型除錯指南,技術事實以微軟官方除錯文件為據,常見元兇分佈引用 Tom’s Hardware 與微軟社群案例並已標明來源;站長尚未附上特定硬體平台的實機 dump 與 !analyze -v 輸出,後續取得真實案例會補上 Testbed 與截圖。文中不含虛構的實測數據。

最後老話一句:涉及 Driver Verifier、BIOS 韌體、驅動程式回復這類操作,沒有把握就停手,先備份、先確認能進安全模式,再動手。

❓ 常見問題

Q:DRIVER_POWER_STATE_FAILURE 是不是記憶體或硬碟壞了?

多數不是。它是「驅動程式在電源狀態切換時沒完成電源 IRP」被系統中止,方向在驅動程式與韌體,不是記憶體條或硬碟實體損壞。除非你另有記憶體檢測或 SMART 異常的證據,否則先別急著換料。

Q:每次都是「睡眠就藍屏」,那我乾脆把睡眠關掉就好?

關睡眠、關快速啟動可以當臨時止血,讓你先不當機,但那是繞過症狀、不是根治。真正該做的還是照方法一、二找出那支拖延的驅動程式並更新它,否則哪天喚醒或關機一樣可能再犯。

Q:一定要用 Driver Verifier 嗎?

不一定。多數人靠「方法一更新四類驅動程式 + 方法二事件檢視器」就解決了。Driver Verifier 是最後手段,而且有風險,能不用就不用。

Q:我的停止代碼不是 0x9F,是 DPC_WATCHDOG_VIOLATION 或別的?

那是不同的 bugcheck,方向也不同。如果你看到的是 0x133,請改看〈電腦一直跳 DPC_WATCHDOG_VIOLATION?揪出兇手驅動程式〉;不論哪一種,把當機當下的 minidump 撈出來用 WinDbg 分析,都是最快鎖定真兇的方法。

🔗 延伸閱讀

📎 參考資料來源

📖 第一級|Microsoft 官方:

Microsoft Learn:Bug Check 0x9F DRIVER_POWER_STATE_FAILURE — 2026-07-03 查證
Microsoft Learn:Bug Check Code Reference — 2026-07-03 查證
Microsoft:Troubleshoot blue screen errors(windows.com/stopcode) — 2026-07-03 查證

📖 第二級|權威技術媒體:

Tom’s Hardware:How to Fix a DRIVER_POWER_STATE_FAILURE Error in Windows — 2026-07-03 查證

⚠️ 本文核心事實(0x9F 定義、Parameter 1 子類型、電源 IRP 逾時機制、除錯指令)以第一級官方為準;顯示卡/網路卡/USB/PCI 為最常見元兇屬社群普遍案例與第二級媒體整理,已於文中標示。

📅 本文查證戳記:2026-07-03 依 Microsoft 官方除錯文件整理。若後續版本 Windows 的處理方式調整,站長會回來更新。