藍屏跳 DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS(0xCE)先別急著換記憶體。官方成因寫在軟體層:驅動卸載前沒取消 lookaside list、DPC 與工作執行緒,等系統回頭呼叫,那段程式碼已經不在了。本文教你從傾印的已卸載模組清單反推嫌疑驅動,再用 Driver Verifier 標準設定逮現行犯。
藍屏跳 MULTIPLE_IRP_COMPLETE_REQUESTS(0x44)先別急著換記憶體。官方講得很清楚:這是某支驅動要求完成一個已經完成的 IRP,而最常見的情況是兩支驅動都以為自己擁有這個封包。本文說明為什麼 !analyze -v 指的模組在這顆碼上特別容易抓錯人,教你用 !irp 攤開封包反推 device stack,再用 Driver Verifier 的 I/O 驗證把違規當場逮住。
電腦卡住不動、滑鼠會動卻點不了,這種 hang 不會留下 minidump,`!analyze -v` 也給不出答案。本文依微軟官方文件走三段路徑:先用鍵盤強制當機造一份核心傾印,再用 `!process 0 17` 列出全系統執行緒與等待狀態,接著用 `!thread` 鎖定可疑執行緒、`!irp` 追出停在 pending 的 I/O 請求與驅動名稱。
裝 WinDbg 到底該選「WinDbg」還是「WinDbg Preview」?符號路徑設完為什麼函式名稱還是一堆 `nt+0x3f1234`?本文依微軟官方文件走完三種安裝管道的差異(含 winget 裝的不會自動更新)、`.symfix` 與 `_NT_SYMBOL_PATH` 兩種設法,並把「一堆問號」拆成四種病灶——沒有符號檔、版本對不上、還沒載、連不到伺服器,各給官方訊號字串與處置。
跑完 `!analyze -v`,兩百行英文只看得懂 MODULE_NAME?本文依官方文件把報告拆成四段逐欄解讀:STACK_TEXT 的五個欄位怎麼切、為什麼要由下往上讀,FAILURE_BUCKET_ID 在官方文件裡其實沒有欄位定義,以及 Followup 演算法為什麼會把責任指到呼叫者身上。附符號路徑設定與三個交叉檢查。
跳 0x3D 藍屏,網路上常說「參數 1 是陷阱編號」——那其實是 0x7F 的規格。依微軟官方文件,0x3D 的參數 1、2 是例外紀錄與內容紀錄的指標,參數 3、4 固定為 0。本文拆解中斷路徑機制、用 `.exr` 與 `.cxr` 還原案發現場的完整步驟,逐項對照 0x1E / 0x8E / 0x7F 的差異,並附 Driver Verifier 安全用法與四種情境的回退步驟。
0xC5 最難搞的地方,是錯誤訊息在結構上就不指向兇手——集區被寫壞是幾秒甚至幾小時前的事,當機當下堆疊上的驅動只是踩到地雷的倒楣鬼。這篇拆開官方四個 Parameter 的真正含義、講清楚 0xC5 與 0xD0 的分水嶺其實是配置大小而非分頁與否,並帶你用 Driver Verifier Special Pool 把延遲引爆變成即時引爆。
藍屏跳 NO_MORE_IRP_STACK_LOCATIONS(0x35)先別急著測記憶體。官方定義寫得很清楚:這是上層驅動呼叫 IoCallDriver 時封包已無剩餘堆疊位置,而且發生當下另有記憶體被寫壞。本文從 IRP 堆疊位置怎麼配講起,教你用 !irp 讀出封包有幾層、卡在第幾層,再用 Driver Verifier 的 IRP Logging 取證,最後附上開不了機的三段回退。
藍屏跳 DRIVER_IRQL_NOT_LESS_OR_EQUAL(0xD1)先別重灌。官方明說多數情況問題不在 IRQL 數字,而在被存取的那塊記憶體。本文從 IRQL 階梯講起,拆解四個參數怎麼讀、跟近親 0x0A 差在哪三處,教你用 KiBugCheckDriver 直接讀出責任驅動,最後才動 Driver Verifier,並附開不了機的三段救援。
跳 ACPI_BIOS_ERROR(0xA5)藍屏,問題不在驅動程式,也不在 Windows——官方定義直接寫明是主機板的 ACPI BIOS 未完整符合 ACPI 規範。本文拆解官方四張參數表怎麼分群、參數 1 為 0x10 時為何只在睡眠喚醒才炸,並依官方順序整理成先歸類、再更新韌體的路線,附華碩與微星官方更新原則與三情境回退步驟。