WinDbg 記憶體與控制代碼診斷:用 !poolused、!handle、!vm 揪出洩漏元兇
電腦跑越久越慢、開機三天後什麼都開不起來,這不是玄學,是核心資源洩漏。多數教學只教你跑 `!analyze -v`,但洩漏型問題在當機那一刻看到的只是二次症狀。本文把 WinDbg 記憶體洩漏診斷拆成四步:`!vm` 先分池、`!poolused` 排出兇手、`!handle` 追控制代碼、Driver Verifier 抓現行犯。
Driver Verifier
DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS(0xCE)藍屏怎麼修?揪出卸載前沒收乾淨的驅動
藍屏跳 DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS(0xCE)先別急著換記憶體。官方成因寫在軟體層:驅動卸載前沒取消 lookaside list、DPC 與工作執行緒,等系統回頭呼叫,那段程式碼已經不在了。本文教你從傾印的已卸載模組清單反推嫌疑驅動,再用 Driver Verifier 標準設定逮現行犯。
MULTIPLE_IRP_COMPLETE_REQUESTS(0x44)藍屏怎麼修?揪出重複完成 IRP 的兇手驅動
藍屏跳 MULTIPLE_IRP_COMPLETE_REQUESTS(0x44)先別急著換記憶體。官方講得很清楚:這是某支驅動要求完成一個已經完成的 IRP,而最常見的情況是兩支驅動都以為自己擁有這個封包。本文說明為什麼 !analyze -v 指的模組在這顆碼上特別容易抓錯人,教你用 !irp 攤開封包反推 device stack,再用 Driver Verifier 的 I/O 驗證把違規當場逮住。
INTERRUPT_EXCEPTION_NOT_HANDLED(0x3D)藍屏排錯:參數 1、2 是紀錄指標,不是陷阱編號
跳 0x3D 藍屏,網路上常說「參數 1 是陷阱編號」——那其實是 0x7F 的規格。依微軟官方文件,0x3D 的參數 1、2 是例外紀錄與內容紀錄的指標,參數 3、4 固定為 0。本文拆解中斷路徑機制、用 `.exr` 與 `.cxr` 還原案發現場的完整步驟,逐項對照 0x1E / 0x8E / 0x7F 的差異,並附 Driver Verifier 安全用法與四種情境的回退步驟。
DRIVER_CORRUPTED_EXPOOL 0xC5 藍屏怎麼修?用 Special Pool 揪出真兇驅動
0xC5 最難搞的地方,是錯誤訊息在結構上就不指向兇手——集區被寫壞是幾秒甚至幾小時前的事,當機當下堆疊上的驅動只是踩到地雷的倒楣鬼。這篇拆開官方四個 Parameter 的真正含義、講清楚 0xC5 與 0xD0 的分水嶺其實是配置大小而非分頁與否,並帶你用 Driver Verifier Special Pool 把延遲引爆變成即時引爆。
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)先別重灌。官方明說多數情況問題不在 IRQL 數字,而在被存取的那塊記憶體。本文從 IRQL 階梯講起,拆解四個參數怎麼讀、跟近親 0x0A 差在哪三處,教你用 KiBugCheckDriver 直接讀出責任驅動,最後才動 Driver Verifier,並附開不了機的三段救援。
KERNEL_MODE_EXCEPTION_NOT_HANDLED(0x8E)藍屏排錯:參數 1 定路線、參數 2 鎖模組
跳 0x8E 藍屏別急著換記憶體。真正決定路線的是參數 1 的例外碼:0xC0000005 才走驅動線,0x80000003 代表機器上有帶除錯判定式的驅動。本文拆解四個參數語意、說明參數 3 的 trap frame 能做什麼與其推論邊界,並逐項對照 0x1E 的差異與官方獨有的三項處置,附 WinDbg 三步、Driver Verifier 安全用法與完整回退步驟。
UNEXPECTED_KERNEL_MODE_TRAP(0x7F)藍屏排錯:讀懂第一參數的陷阱編號揪出真兇
跳 0x7F 藍屏,別急著拆記憶體。這個停止碼的第一個參數就是 CPU 的陷阱編號:0x8(Double Fault)要先查核心堆疊溢位,0x6 才是官方明講「最常見原因是硬體記憶體損毀」的編號。本文拆解常見陷阱編號與 Double Fault 兩條成因,並依官方順序整理成還原硬體、還原超頻、再用 Driver Verifier 抓驅動的三段流程。
ATTEMPTED_WRITE_TO_READONLY_MEMORY(0xBE)藍屏怎麼修?讀懂 PTE 唯讀位元揪出亂寫的驅動
藍屏跳 ATTEMPTED_WRITE_TO_READONLY_MEMORY(0xBE)先別急著換記憶體。微軟官方定義是驅動程式嘗試寫入唯讀記憶體節區,屬於權限違規而非資料損毀。本文帶你讀懂官方四個參數、用 WinDbg 的 !pte 看懂那個決定生死的唯讀位元,再用 Driver Verifier 的程式碼完整性規則類別把亂寫的驅動逼出來,並附安全模式與 WinRE 回退步驟。