快訊
2026-08-26

WinDbg Preview 安裝與符號路徑設定完整教學:為什麼你的當機分析報告一堆問號

WinDbg Preview 符號路徑設定教學刊頭圖

裝 WinDbg 到底該選「WinDbg」還是「WinDbg Preview」?符號路徑設完為什麼函式名稱還是一堆 `nt+0x3f1234`?本文依微軟官方文件走完三種安裝管道的差異(含 winget 裝的不會自動更新)、`.symfix` 與 `_NT_SYMBOL_PATH` 兩種設法,並把「一堆問號」拆成四種病灶——沒有符號檔、版本對不上、還沒載、連不到伺服器,各給官方訊號字串與處置。

WinDbg !analyze -v 完整教學:逐欄位讀懂當機分析報告,搞懂 STACK_TEXT 與 FAILURE_BUCKET_ID

WinDbg !analyze -v 當機分析報告逐欄解讀刊頭圖

跑完 `!analyze -v`,兩百行英文只看得懂 MODULE_NAME?本文依官方文件把報告拆成四段逐欄解讀:STACK_TEXT 的五個欄位怎麼切、為什麼要由下往上讀,FAILURE_BUCKET_ID 在官方文件裡其實沒有欄位定義,以及 Followup 演算法為什麼會把責任指到呼叫者身上。附符號路徑設定與三個交叉檢查。

INTERRUPT_EXCEPTION_NOT_HANDLED(0x3D)藍屏排錯:參數 1、2 是紀錄指標,不是陷阱編號

INTERRUPT_EXCEPTION_NOT_HANDLED 0x3D 藍屏排錯刊頭圖

跳 0x3D 藍屏,網路上常說「參數 1 是陷阱編號」——那其實是 0x7F 的規格。依微軟官方文件,0x3D 的參數 1、2 是例外紀錄與內容紀錄的指標,參數 3、4 固定為 0。本文拆解中斷路徑機制、用 `.exr` 與 `.cxr` 還原案發現場的完整步驟,逐項對照 0x1E / 0x8E / 0x7F 的差異,並附 Driver Verifier 安全用法與四種情境的回退步驟。

DRIVER_CORRUPTED_EXPOOL 0xC5 藍屏怎麼修?用 Special Pool 揪出真兇驅動

Windows DRIVER_CORRUPTED_EXPOOL 0xC5 藍屏集區損毀除錯示意圖

0xC5 最難搞的地方,是錯誤訊息在結構上就不指向兇手——集區被寫壞是幾秒甚至幾小時前的事,當機當下堆疊上的驅動只是踩到地雷的倒楣鬼。這篇拆開官方四個 Parameter 的真正含義、講清楚 0xC5 與 0xD0 的分水嶺其實是配置大小而非分頁與否,並帶你用 Driver Verifier Special Pool 把延遲引爆變成即時引爆。

NO_MORE_IRP_STACK_LOCATIONS(0x35)藍屏怎麼修?揪出插隊裝置堆疊的過濾驅動

NO_MORE_IRP_STACK_LOCATIONS 0x35 藍屏排錯示意刊頭

藍屏跳 NO_MORE_IRP_STACK_LOCATIONS(0x35)先別急著測記憶體。官方定義寫得很清楚:這是上層驅動呼叫 IoCallDriver 時封包已無剩餘堆疊位置,而且發生當下另有記憶體被寫壞。本文從 IRP 堆疊位置怎麼配講起,教你用 !irp 讀出封包有幾層、卡在第幾層,再用 Driver Verifier 的 IRP Logging 取證,最後附上開不了機的三段回退。

DRIVER_IRQL_NOT_LESS_OR_EQUAL(0xD1)藍屏怎麼修?讀懂四個參數揪出兇手驅動

DRIVER_IRQL_NOT_LESS_OR_EQUAL 0xD1 藍屏排錯示意刊頭

藍屏跳 DRIVER_IRQL_NOT_LESS_OR_EQUAL(0xD1)先別重灌。官方明說多數情況問題不在 IRQL 數字,而在被存取的那塊記憶體。本文從 IRQL 階梯講起,拆解四個參數怎麼讀、跟近親 0x0A 差在哪三處,教你用 KiBugCheckDriver 直接讀出責任驅動,最後才動 Driver Verifier,並附開不了機的三段救援。

ACPI_BIOS_ERROR(0xA5)藍屏排錯:問題出在主機板 BIOS,不是驅動程式

ACPI_BIOS_ERROR 0xA5 藍屏與主機板 BIOS 韌體 ACPI 規範排錯示意

跳 ACPI_BIOS_ERROR(0xA5)藍屏,問題不在驅動程式,也不在 Windows——官方定義直接寫明是主機板的 ACPI BIOS 未完整符合 ACPI 規範。本文拆解官方四張參數表怎麼分群、參數 1 為 0x10 時為何只在睡眠喚醒才炸,並依官方順序整理成先歸類、再更新韌體的路線,附華碩與微星官方更新原則與三情境回退步驟。

MACHINE_CHECK_EXCEPTION(0x9C)藍屏排錯:讀懂 Bank 編號,先確認它該不該是 0x124

MACHINE_CHECK_EXCEPTION 0x9C 藍屏與 MCA 機器檢查架構排錯路線示意

跳 MACHINE_CHECK_EXCEPTION 0x9C 藍屏,先別急著換 CPU。官方明訂 Vista 後這個碼已由 0x124 取代,只剩兩種情況會出現,其中一種的定義就是「暫存器裡讀不到錯誤」,傾印可能給不出兇手。本文拆參數 1 的 Bank 編號與 MCA、WHEA 訊號鏈,參考 0x124 官方成因類推出散熱、超頻、記憶體三步分流,附 !errrec 判讀與完整回退步驟。

KERNEL_MODE_EXCEPTION_NOT_HANDLED(0x8E)藍屏排錯:參數 1 定路線、參數 2 鎖模組

KERNEL_MODE_EXCEPTION_NOT_HANDLED 0x8E 藍屏四個參數與官方除錯路線示意

跳 0x8E 藍屏別急著換記憶體。真正決定路線的是參數 1 的例外碼:0xC0000005 才走驅動線,0x80000003 代表機器上有帶除錯判定式的驅動。本文拆解四個參數語意、說明參數 3 的 trap frame 能做什麼與其推論邊界,並逐項對照 0x1E 的差異與官方獨有的三項處置,附 WinDbg 三步、Driver Verifier 安全用法與完整回退步驟。

ATTEMPTED_WRITE_TO_READONLY_MEMORY(0xBE)藍屏怎麼修?讀懂 PTE 唯讀位元揪出亂寫的驅動

Windows ATTEMPTED_WRITE_TO_READONLY_MEMORY 0xBE 藍屏除錯示意封面

藍屏跳 ATTEMPTED_WRITE_TO_READONLY_MEMORY(0xBE)先別急著換記憶體。微軟官方定義是驅動程式嘗試寫入唯讀記憶體節區,屬於權限違規而非資料損毀。本文帶你讀懂官方四個參數、用 WinDbg 的 !pte 看懂那個決定生死的唯讀位元,再用 Driver Verifier 的程式碼完整性規則類別把亂寫的驅動逼出來,並附安全模式與 WinRE 回退步驟。