⚡ 站長快讀:核心重點
- 文章屬性:教學實戰(核心除錯)
- 適用系統:Windows 10 / 11 / Server(核心模式除錯)
- 難易度 / 耗時:⭐⭐⭐ / 約 40–60 分鐘
- 核心結論:
!vm先分池、!poolused依 pool tag 排出兇手、!handle查控制代碼未釋放。 - 適用對象:遇到「沒藍屏卻越跑越慢」的進階使用者與 IT 維運人員。
📌 快速答案
一句話答案:WinDbg 記憶體洩漏診斷的正確順序是先用
!vm看非分頁集區總量是否異常,再用!poolused 2依 pool tag 排序抓出增長最兇的標籤,最後用!handle與 Driver Verifier 集區追蹤鎖定沒釋放資源的驅動。
🧰 開始前的準備
- 系統需求:Windows 10 / 11 或 Windows Server;分析端安裝 Debugging Tools for Windows(WinDbg)。
- 權限需求:系統管理員(取得傾印檔、啟用 Driver Verifier 都需要)。
- 傾印檔類型(這一項最容易踩雷):必須是 Kernel Memory Dump、Complete Memory Dump 或 Active Memory Dump。微軟官方明載 Small Memory Dump 只有 64 KB,裡面沒有完整的核心集區資料,
!poolused在這種檔案上跑不出有意義的結果。 - 需要工具:WinDbg(Debugging Tools for Windows)、選用 PoolMon(WDK 的
\Tools\Other子目錄)、選用 Driver Verifier(系統內建verifier.exe)。 - 符號路徑:一定要先設好 Microsoft 公用符號伺服器,否則 pool tag 對得出來、驅動名稱卻是一堆問號。設定方法見站內這篇:WinDbg Preview 安裝與符號路徑設定完整教學。
- 預計耗時:約 40–60 分鐘;若要啟用 Driver Verifier 集區追蹤再重現一次問題,請另外預留數小時到數天的觀察期。
- 難度門檻:需要看得懂十六進位位址與核心模組名稱;不需要會寫驅動程式。
🔍 為什麼你需要這個?
有一類故障最讓人抓不到把柄:剛開機一切正常,跑了兩三天之後系統開始變慢、應用程式開不起來、最後可能直接藍屏或當場凍住。重開機「就好了」,於是問題被歸類成「Windows 就是這樣」,兩天後再來一次。
這不是玄學,而是資源持續增長型問題——某個核心元件不斷向系統要記憶體或控制代碼,卻在用完後沒有還回去。它跟「當下卡死」是完全不同的病理:卡死型問題有明確的當機瞬間,!analyze -v 抓得到肇事堆疊(站內另有一篇專講怎麼追執行緒與 I/O 請求:WinDbg 進階指令教學:用 !process、!irp、!thread 追出卡死的驅動程式與 I/O 請求);洩漏型問題在「發作那一刻」看到的往往只是二次症狀,真正的兇手在幾天前就開始偷渡了。
這篇要給的是三個角度,都是一般 Windows 教學文不會處理的:
- 先分池,再抓標籤:多數文章直接教你跑
!poolused,但沒有先用!vm判斷洩漏發生在非分頁集區、分頁集區還是使用者層,結果對著一堆 tag 瞎猜。 - pool tag ≠ 兇手名字:
!poolused給的是四個字元的標籤,而且經常印出UNKNOWN pooltag。本文會說明標籤怎麼對回二進位檔、對不到時該用哪個指令反查。 - 控制代碼洩漏是另一套機制:控制代碼耗盡跟集區耗盡走的是不同的核心資料結構,
!handle有它自己的模式限制與旗標組合,不是「記憶體那套的延伸」。
🛠️ 實戰步驟
⚠️ 執行前警語(⭐⭐⭐ 高風險段):本文步驟五會啟用 Driver Verifier,它會刻意讓有問題的驅動程式提早觸發檢查停止(bug check),很可能造成目標機器反覆藍屏、甚至無法正常進入桌面。請務必:①先完成重要資料備份 ②先建立系統還原點 ③確認電源穩定(筆電請接電) ④在測試機或可承受停機的機器上做。步驟一到四只是讀取傾印檔,不會改動系統設定,可以安心進行。
停止條件清單(符合任一,請不要繼續):不確定目標機器的 Windows 版本與版次;尚未完成備份;已啟用 BitLocker 但手上沒有修復金鑰;公司或學校控管的設備且未取得 IT 授權;沒有可開機的 Windows 修復 USB;指令輸出與本文描述明顯不符。
下面這張圖是核心集區(記憶體)洩漏的診斷路徑;控制代碼洩漏走的是另一套機制,單獨放在步驟四。
步驟一:用 !vm 判斷洩漏發生在哪一層
先確認「到底是誰在漏」。在核心模式除錯階段執行:
!vm 1!vm 顯示的是整台機器的虛擬記憶體使用摘要,Flags 帶 1 表示略過個別行程統計,先看系統整體。官方文件指出這份輸出裡最有用的欄位是實體記憶體總量、可用頁數,以及 nonpaged pool usage——並且明講:「如果這個數字太大,通常代表系統某處有記憶體洩漏。」
輸出裡請重點看這幾行:
| 欄位 | 代表什麼 | 異常訊號 |
|---|---|---|
NonPagedPool Usage / NonPagedPool Max | 非分頁集區目前用量與上限 | 用量逼近上限 = 核心層洩漏的頭號嫌疑 |
PagedPool Usage / PagedPool Maximum | 分頁集區用量與上限 | 分頁集區吃滿,常見於物件或登錄檔相關配置 |
Available Pages | 系統可用頁數 | 持續下降而 committed 不斷上升 |
Committed pages / Commit limit | 認可量與認可上限 | 兩者接近 = 系統即將無記憶體可配 |
三點摘要:
- 非分頁集區異常 → 幾乎一定是核心模式元件(驅動程式)的問題,往步驟二。
- 分頁集區異常 → 同樣往步驟二,但要留意物件與控制代碼相關標籤,並在步驟四追控制代碼。
- 兩個池都正常、只有某個行程的工作集不斷長大 → 這是使用者層洩漏,核心除錯器幫不上忙,改用行程層工具(
!process 0 0的QuotaPoolUsage與工作集大小可作為第一層線索;官方文件也建議在洩漏系統上比對所有行程的非分頁集區用量,找出哪個行程在漏)。
💡 為什麼要這樣做? 非分頁集區的定義就是「不能被換出到分頁檔、必須一直佔著實體記憶體」。它有硬性上限,而且一旦耗盡,連正常的核心配置都會失敗——這就是為什麼洩漏到後期常出現「什麼都開不起來」而不是單純變慢。先分池等於先把嫌疑範圍從整台機器縮到一個池。
步驟二:用 !poolused 依 pool tag 排出兇手排行榜
確認是核心集區在漏之後,執行:
!poolused 2!poolused 的完整語法是 !poolused [Flags [TagString]]。Flags 是位元組合,實務上這三個最常用:
| Flags | 效果 | 什麼時候用 |
|---|---|---|
0x0(預設) | 依 pool tag 排序的摘要 | 想照字母順序通盤瀏覽 |
0x2 | 依非分頁記憶體用量排序 | 步驟一判定非分頁集區異常時的首選 |
0x4 | 依分頁記憶體用量排序 | 步驟一判定分頁集區異常時用 |
0x1 | 加印詳細(verbose)資訊 | 想看更細的內容時加總上去 |
0x8 | 顯示工作階段集區而非標準集區 | 遠端桌面/多工作階段環境 |
注意:官方明訂 bit 1(0x2)與 bit 2(0x4)不能一起用——想同時看兩個排序就跑兩次。另外若要指定標籤,TagString 是區分大小寫的 ASCII 字串,除非用星號 *,否則長度必須剛好四個字元(? 可代表恰好一個字元)。
輸出的每一列包含 pool tag、非分頁與分頁各自的「配置筆數(Allocs)」與「已用位元組(Used)」。看的重點是:
- Allocs 異常大而 Used 也同步暴增:典型洩漏樣態——一直配置、幾乎沒釋放。
- 單一 tag 佔掉整個池的顯著比例:直接鎖定這個標籤。
- 對照兩份傾印檔:如果手上有「剛開機」與「跑三天後」兩個傾印檔,同一個 tag 的 Allocs 差額就是最硬的證據。這是本文最推薦的做法——單一時間點的快照很難分辨「本來就用很多」和「一直在漏」。
!poolused 的資料來自 Windows 的集區標記(pool tagging)機制。官方文件明載:集區標記在 Windows Server 2003 及後續版本永久啟用,所以現行 Windows 10/11 上不需要額外用 GFlags 去開它。另外提醒一句:如果你在指令跑完前就中斷它,除錯器只會顯示部分結果——別把不完整的清單當成結論。
步驟三:把 pool tag 對回真正的驅動程式
!poolused 常見的輸出長這樣(節錄官方範例格式):標籤後面可能跟著人類看得懂的說明與 Binary: acpi.sys,也可能直接印 UNKNOWN pooltag 'xxxx', please update pooltag.txt。
對得回來的情況好辦,Binary: 後面就是嫌疑二進位檔。對不回來時,依序這樣做:
- 查 pooltag.txt:這份對照表隨 PoolMon 與 Debugging Tools for Windows 套件一起安裝,PoolMon 就是靠它把標籤翻成 Windows 元件與常見驅動的名稱。第三方驅動的自訂標籤通常不在裡面,這很正常。
- 用 !poolfind 反查配置位址:語法為
!poolfind TagString [PoolType],PoolType為0=非分頁(預設)、1=分頁、2=特殊集區、4=工作階段集區。官方提醒這個指令可能跑很久,取決於要搜尋的集區大小,必要時可用.cache把快取加大(官方建議約 10 MB)。 - 拿位址回推模組:找到配置位址之後,用一般的記憶體與模組指令去看那塊記憶體屬於誰、附近有哪些已知結構。
- 還是對不到 → 直上步驟五:Driver Verifier 的集區追蹤會直接給你「配置者的位址」,這是把標籤對回驅動最可靠的一條路。
💡 為什麼要這樣做? pool tag 是驅動程式呼叫
ExAllocate*系列常式時自己傳進去的四字元標籤——誰都可以取名字。所以標籤只是線索,不是身分證;把它當成兇手名字直接下結論,是這類分析最常見的誤判來源。
步驟四:用 !handle 排查控制代碼洩漏
如果症狀是「開檔案失敗」「無法建立新執行緒」「服務啟不起來」,而集區用量看起來還算正常,那要懷疑的是控制代碼(handle)沒有關。
!handle 在使用者模式與核心模式的語法不同:
!handle [Handle [UMFlags [TypeName]]]!handle [Handle [KMFlags [Process [TypeName]]]]核心模式下有幾個實用組合:
| 指令 | 作用 |
|---|---|
!handle 0 3 0 | 列出所有行程的控制代碼與物件資訊(Handle=0 表示全部;Process=0 表示所有行程) |
!handle 0 3 0 File | 只看 File 類型的控制代碼——追檔案控制代碼洩漏用 |
!handle 0 3 0 Event | 只看 Event 類型——同步物件沒關最常見 |
!handle 0 4 | 加印空閒(free)控制代碼項目 |
!handle <索引> 13 | 從核心控制代碼表取該控制代碼的詳細資訊(旗標含 0x10) |
TypeName 區分大小寫,官方列出的有效型別包含 Event、Section、File、Port、Directory、SymbolicLink、Mutant、WindowStation、Semaphore、Key、Token、Process、Thread、Desktop、IoCompletion、Timer、Job 與 WaitablePort。
兩個最容易卡住的限制(官方明載,務必先確認):
!handle可用於使用者模式與核心模式的即時除錯,也可用於核心模式傾印檔。- 但不能用於一般的使用者模式傾印檔,除非該檔案是特意帶控制代碼資訊建立的(用
.dump /mh產生)。
實務判讀順序:先用 !process 0 0 掃過所有行程,看哪一個的 TableSize(控制代碼表大小)明顯偏大;鎖定行程後,再用 !handle 0 3 <行程> 加型別過濾,看是哪一種物件在累積。找到型別,通常就能推回是哪一類程式行為沒收尾。
想知道「是哪一行程式碼開了這個控制代碼」還有 !htrace:它會顯示控制代碼的堆疊追蹤,但必須先啟用控制代碼追蹤(使用者模式可用 !htrace -enable,或對目標行程開啟 Application Verifier 並勾選 Handles 選項)。啟用後,每次行程開啟、關閉或參照無效控制代碼時都會存下堆疊資訊;-snapshot 與 -diff 這組搭配可以比對兩個時間點之間「還開著」的控制代碼,對洩漏診斷特別有用。官方同時提醒:!htrace 報出的部分追蹤可能來自不同的行程內容,回傳位址在當前行程內容下可能解不出正確符號。
步驟五:用 Driver Verifier 集區追蹤抓現行犯
⚠️ 本步驟會改動系統設定並需要重新開機,請先讀完上方警語與停止條件。
當你已經有嫌疑驅動、但需要鐵證時,啟用 Driver Verifier 的集區追蹤(Pool Tracking)。它的行為很直接:監看該驅動的所有記憶體配置,並在驅動卸載時檢查是否全部釋放。
命令列上,集區追蹤對應 Bit 3(0x8):
verifier /flags 0x8 /driver MyDriver.sys這個設定下次開機後生效。Windows Vista 及後續版本可以加 /volatile 免重開機立即生效,但設定會在關機或重開機後失效:
verifier /volatile /flags 0x8 /adddriver MyDriver.sys集區追蹤也包含在標準設定裡:
verifier /standard /driver MyDriver.sys啟用後的判讀重點:
- 驅動卸載時仍有未釋放的配置 → Driver Verifier 會發出檢查停止 0xC4(DRIVER_VERIFIER_DETECTED_VIOLATION),Parameter 1 等於
0x62。這就是「這支驅動漏記憶體」的官方認定。 - 若 0xC4 的 Parameter 1 是
0x51、0x52、0x53、0x54或0x59,代表驅動寫到自己配置範圍外的記憶體;官方建議這時改開特殊集區(Special Pool)去定位錯誤來源。 - 自 Windows Vista 起,啟用集區追蹤會同時啟用鎖定頁面追蹤:驅動在 I/O 完成後沒釋放鎖定頁面,會觸發檢查停止 0xCB(DRIVER_LEFT_LOCKED_PAGES_IN_PROCESS)。
- 在 Windows 7 及後續版本,集區追蹤還涵蓋以
IoAllocateMdl、IoAllocateIrp(以及其他配置 IRP 結構的常式)、RtlAnsiStringToUnicodeString等 RTL 字串常式、IoSetCompletionRoutineEx所配置的記憶體。
回到 WinDbg 這一側,核心除錯器擴充指令 !verifier 0x3 可以在驅動卸載後找出未釋放的配置,也可以在驅動執行中追蹤目前的配置狀況——而且它會一併顯示 pool tag、集區大小,以及每一筆配置的配置者位址。這正是步驟三對不回標籤時的最終解。
步驟六:驗證結果
確認你真的抓到兇手,而不是抓到症狀:
- 雙點取樣一致:比對「乾淨狀態」與「已惡化狀態」兩份傾印檔的
!poolused輸出,同一個 tag 的 Allocs 與 Used 差額,和!vm顯示的池成長量在同一個量級。 - 配置者位址落在同一個模組:
!verifier 0x3列出的未釋放配置,其配置者位址集中指向同一支驅動。 - 移除或更新該驅動後,成長曲線消失:把嫌疑驅動停用或更新到新版,再持續觀察數天,
!vm的池用量不再單向上升。長時間監看可以搭配站內這篇的做法:Windows 效能監視器 PerfMon 教學:長時間記錄 CPU、磁碟與記憶體異常。 - 關閉 Driver Verifier 後系統穩定:見下方回退步驟。
🔬 底層機制:這個問題到底在系統哪一層?
要理解為什麼需要三個不同的指令,得先知道 Windows 核心把「資源」放在兩套完全不同的帳本上。
第一套帳本:核心集區(kernel pool)。 驅動程式需要記憶體時,呼叫 ExAllocate* 系列常式,從非分頁集區或分頁集區取得。兩者差別在能不能被換出到分頁檔:非分頁集區必須一直佔著實體記憶體,因為它可能在高中斷請求層級(IRQL)被存取,那個時機不允許發生分頁錯誤。代價是它有硬性上限,而且吃掉的是真實 RAM。呼叫時傳入的四字元 pool tag 會被記錄下來,這就是 !poolused 能按標籤統計的原因——它不是 WinDbg 猜出來的,是核心本來就在記帳。
第二套帳本:物件管理員與控制代碼表。 當程式開啟檔案、事件、登錄檔機碼時,核心會建立或參照一個物件,並在該行程的控制代碼表裡放一個項目,回傳一個索引給呼叫者——這就是控制代碼。!handle 讀的是這張表,!process 輸出的 ObjectTable 與 TableSize 指的也是它。控制代碼洩漏的後果是物件參照計數永遠降不到零:物件不會被釋放,連帶它背後的核心結構也留著。所以控制代碼洩漏最後也會表現成集區成長,但你在 !poolused 上看到的是「物件相關的標籤在長」,而根因在「沒有人呼叫 Close」。
這兩套帳本解釋了三個指令的分工:
!vm看的是總帳——池層級的用量與上限,回答「有沒有在漏、漏在哪個池」。!poolused看的是分類帳——按 pool tag 匯總,回答「哪個標籤在長」。!handle看的是另一本帳——物件與控制代碼,回答「是不是有人開了不關」。
也因此,!analyze -v 對洩漏型問題經常無能為力:它的工作是從當機那一刻的上下文推斷肇事模組(該指令的逐欄位判讀見文末延伸閱讀)。但洩漏的當機瞬間,倒在地上的往往是「最後一個要不到記憶體的無辜元件」,不是三天前開始偷渡的那一個。要抓真兇,必須看趨勢與帳本,不是看現場。
最後補一個實務上很關鍵的層次差異:傾印檔本身就決定了你能看到多少。微軟官方把核心模式傾印檔分成五種設定——Complete、Kernel、Small、Automatic、Active Memory Dump,差別是大小與內容量;Small Memory Dump 只有 64 KB,Kernel Memory Dump 通常不含使用者模式記憶體,Complete 最大且包含部分使用者模式記憶體。官方也直言:沒有任何核心模式傾印檔能提供跟即時核心除錯一樣多的資訊,因為傾印檔只是某個時間點的快照。對洩漏診斷來說,這句話的實務翻譯就是:能做即時除錯或能拿到兩個時間點的完整傾印檔,診斷難度會差一個等級。
🔙 萬一翻車:回退步驟
Driver Verifier 是本文唯一會改動系統的操作,以下依情況處理。
情境一:設定生效但沒抓到東西
不需要救援,只要把 Driver Verifier 關掉即可。以系統管理員身分開啟命令提示字元:
verifier /reset重新開機後恢復原狀。若當初是用 /volatile 加入的,關機或重開機本來就會失效。
情境二:啟用後系統開始反覆藍屏,但還能進桌面
先確認你剛才改了什麼、要回到哪個狀態,再執行上面的 verifier /reset 並重新開機。請不要在這個階段順手改別的系統設定——一次只動一個變因,才知道是誰造成的。
情境三:啟用後無法進入桌面(最壞情況)
Driver Verifier 造成開機階段就藍屏時:
- 連續兩次開機失敗後,Windows 通常會自動進入修復環境(WinRE);也可以用事先做好的 Windows 修復 USB 開機。
- 進入安全模式(WinRE →「疑難排解」→「進階選項」→「啟動設定」→ 重新啟動後選安全模式)。
- 在安全模式下執行
verifier /reset,然後正常重開機。 - 若安全模式也進不去,改用系統還原回到操作前建立的還原點(這就是前面要你先建還原點的原因)。
- 官方修復工具與 WinRE 說明:Windows 修復環境(Windows RE)。
⚠️ 如果目標機器啟用了 BitLocker,任何進入 WinRE 或變更開機設定的動作都可能要求輸入修復金鑰。手上沒有金鑰,就不要開始這一段。
💡 總結:進階玩法與底層邏輯
站長我把這套流程整理出來,是因為在核心除錯裡最浪費時間的一件事,就是拿「當機分析」的工具去打「趨勢分析」的問題。!analyze -v 很好用,但它回答的是「誰倒在現場」;洩漏問題要問的是「誰一直在拿東西不還」,這兩個問題的證據形態完全不同。
幾個可以驗證的具體數字,值得記在腦子裡:集區追蹤在命令列上的旗標是 0x8;Driver Verifier 判定驅動卸載時仍有未釋放配置,會丟出檢查停止 0xC4 且 Parameter 1 = 0x62;鎖定頁面沒釋放是 0xCB;Small Memory Dump 是 64 KB;!poolfind 的 PoolType 是 0/1/2/4 四個值。這些都是官方文件寫死的常數,記住它們可以省下每次翻文件的時間。(以上為官方文件查核結果,非站長第一手實測數據。)
三個進階玩法:
- 建立基線:在系統健康時就先存一份
!poolused輸出。等到出問題,你會慶幸自己有比較的基準——沒有基線,單一快照幾乎無法分辨「本來就多」與「一直在漏」。 - 用 PoolMon 做即時觀察:不想每次都抓傾印檔,可以在活的系統上跑 PoolMon(在 WDK 的
\Tools\Other子目錄)。微軟文件明說驅動開發者與測試者常用它來偵測記憶體洩漏,也能用來觀察配置與釋放的模式。 - 把 !htrace 的 snapshot / diff 當成標準流程:控制代碼洩漏最難的是「證明它真的沒關」。
-snapshot取基準、跑一段時間後-diff,直接列出還開著的控制代碼,比人工比對可靠得多。
還有一個容易被忽略的坑:Driver Verifier 在 Windows 7 及後續版本會偵測驅動從 DPC 常式呼叫 ExAllocatePoolWithQuotaTag。原因是 DPC 常式可能跑在任何行程的內容中,把配額記到隨機行程頭上本來就不對;如果剛好跑在 Idle 行程內容,官方明載這種情況可能導致記憶體損毀或系統當機。看到這類報告,不要當成誤報。
❓ 常見問題
Q:我只有 C:\Windows\Minidump 裡的小型傾印檔,可以用 !poolused 嗎?
實務上不行。微軟官方文件明載 Small Memory Dump 只有 64 KB,不足以承載完整的核心集區資料。請到「系統」→「進階系統設定」→「啟動及修復」把傾印類型改成 Kernel Memory Dump 或 Complete Memory Dump,重現問題後再取一次。若只是要看藍屏肇事模組,小型傾印檔仍然夠用(做法見文末延伸閱讀的 minidump 分析教學)。
Q:!poolused 印出一堆 UNKNOWN pooltag,是不是我的環境有問題?
不是。pooltag.txt 收錄的是 Windows 元件與常見驅動的標籤對照,第三方驅動自訂的標籤本來就不在裡面。做法是改用 !poolfind 反查該標籤的配置位址,或直接啟用 Driver Verifier 集區追蹤,用 !verifier 0x3 取得配置者位址。
Q:我需要先用 GFlags 開啟集區標記嗎?
不需要。官方文件明載集區標記在 Windows Server 2003 及後續版本是永久啟用的,所以現行 Windows 10/11 上 !poolused 直接就有資料。
Q:!handle 為什麼在我的使用者模式傾印檔上跑不出東西?
這是官方限制,不是設定問題:!handle 不能用於一般使用者模式傾印檔,除非該檔案是用 .dump /mh 特意帶控制代碼資訊建立的。核心模式傾印檔則可以正常使用。
Q:控制代碼洩漏和記憶體洩漏,哪一個比較急?
兩者都會讓系統走向資源耗盡,但表現不同:控制代碼洩漏通常先出現「開不了新檔案 / 建不了新執行緒」這類功能性失敗;非分頁集區耗盡則更容易直接導致核心層配置失敗與當機。實務上先看 !vm:非分頁集區逼近上限就優先處理集區,否則優先查控制代碼。
Q:這些指令在舊版 Windows 也適用嗎?
!poolused、!handle、!vm、!poolfind 都由 Kdexts.dll 提供,是長期存在的核心除錯器擴充指令,官方文件亦標註了各版本差異(例如 !vm 的 Bit 5 0x20 顯示核心虛擬位址用量為 Windows Vista 及後續版本)。集區追蹤對 MDL、IRP、RTL 字串常式的涵蓋範圍是 Windows 7 之後才擴大的,分析舊系統時請以該版本的官方文件為準。
📎 參考資料來源
📖 第一級|廠商官方:
- !poolused(WinDbg)— Microsoft Learn — 2026-08-24 查證
- !handle(WinDbg)— Microsoft Learn — 2026-08-24 查證
- !vm(WinDbg)— Microsoft Learn — 2026-08-24 查證
- !poolfind(WinDbg)— Microsoft Learn — 2026-08-24 查證
- !htrace(WinDbg)— Microsoft Learn — 2026-08-24 查證
- !process(WinDbg)— Microsoft Learn — 2026-08-24 查證
- Pool Tracking — Microsoft Learn — 2026-08-24 查證
- PoolMon 總覽 — Microsoft Learn — 2026-08-24 查證
- 核心模式傾印檔的種類 — Microsoft Learn — 2026-08-24 查證
⚠️ 本文核心事實以第一級為準;本文為官方文件交叉查核之深度整理,非站長第一手實機實測。
🔗 延伸閱讀
- WinDbg !analyze -v 完整教學:逐欄位讀懂當機分析報告
- DRIVER_CORRUPTED_EXPOOL 0xC5 藍屏怎麼修?用 Special Pool 揪出真兇驅動
- ProcDump 教學:抓出應用程式沒回應與當機瞬間的記憶體傾印檔
- WinDbg 藍畫面 minidump 分析教學 2026|三行輸出找出真凶
📅 本文查證戳記:2026-08-24 依 Microsoft Learn 官方除錯器指令文件與 Driver Verifier 文件撰寫。
若你在後續版本遇到指令輸出格式變動,歡迎在留言區回報,站長會更新文章。