WinDbg 記憶體與控制代碼診斷:用 !poolused、!handle、!vm 揪出洩漏元兇
電腦跑越久越慢、開機三天後什麼都開不起來,這不是玄學,是核心資源洩漏。多數教學只教你跑 `!analyze -v`,但洩漏型問題在當機那一刻看到的只是二次症狀。本文把 WinDbg 記憶體洩漏診斷拆成四步:`!vm` 先分池、`!poolused` 排出兇手、`!handle` 追控制代碼、Driver Verifier 抓現行犯。
WinDbg
ProcDump 教學:抓出應用程式沒回應與當機瞬間的記憶體傾印檔
程式卡死或閃退的當下,工作管理員只給你一句「沒有回應」,現場一重開就消失。這篇用微軟官方 ProcDump v12.01,教你分辨「當機」與「沒回應」該用 `-e` 還是 `-h`、四種傾印類型該怎麼選,再把 `.dmp` 丟進 WinDbg 分析,並補上事後除錯器註冊與解除、線上服務降低中斷的參數,以及把傾印檔交給第三方前必須知道的隱私紅線。
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 驗證把違規當場逮住。
WinDbg 進階指令教學:用 !process、!irp、!thread 追出卡死的驅動程式與 I/O 請求
電腦卡住不動、滑鼠會動卻點不了,這種 hang 不會留下 minidump,`!analyze -v` 也給不出答案。本文依微軟官方文件走三段路徑:先用鍵盤強制當機造一份核心傾印,再用 `!process 0 17` 列出全系統執行緒與等待狀態,接著用 `!thread` 鎖定可疑執行緒、`!irp` 追出停在 pending 的 I/O 請求與驅動名稱。
WinDbg Preview 安裝與符號路徑設定完整教學:為什麼你的當機分析報告一堆問號
裝 WinDbg 到底該選「WinDbg」還是「WinDbg Preview」?符號路徑設完為什麼函式名稱還是一堆 `nt+0x3f1234`?本文依微軟官方文件走完三種安裝管道的差異(含 winget 裝的不會自動更新)、`.symfix` 與 `_NT_SYMBOL_PATH` 兩種設法,並把「一堆問號」拆成四種病灶——沒有符號檔、版本對不上、還沒載、連不到伺服器,各給官方訊號字串與處置。
WinDbg !analyze -v 完整教學:逐欄位讀懂當機分析報告,搞懂 STACK_TEXT 與 FAILURE_BUCKET_ID
跑完 `!analyze -v`,兩百行英文只看得懂 MODULE_NAME?本文依官方文件把報告拆成四段逐欄解讀:STACK_TEXT 的五個欄位怎麼切、為什麼要由下往上讀,FAILURE_BUCKET_ID 在官方文件裡其實沒有欄位定義,以及 Followup 演算法為什麼會把責任指到呼叫者身上。附符號路徑設定與三個交叉檢查。
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 取證,最後附上開不了機的三段回退。