快訊
ChatGPT 免費版預設換成 GPT-5.6 Luna:無限對話與 Think 按鈕怎麼用WinDbg !analyze -v 完整教學:逐欄位讀懂當機分析報告,搞懂 STACK_TEXT 與 FAILURE_BUCKET_IDNVIDIA RTX Spark 是什麼?跟 DGX Spark 差在哪一次看懂科技要聞彙整 2026-08-08:研究者稱 RAM 價格約回 2007 年水準AI 要聞彙整 2026-08-08:OpenAI 因網攻能力暫緩 Astra 開發為什麼沒有 Windows 9?微軟從 Windows 8.1 直接跳到 10 的真相
2026-08-09
WinDbg !analyze -v 當機分析報告逐欄解讀刊頭圖
電腦疑難雜症

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

約 20 分鐘閱讀
作者:
廣告
內容目錄 隱藏
1 ⚡ 站長快讀:核心重點
2 📌 快速答案
3 🧰 開始前的準備
4 🔍 為什麼你需要這個?
5 🛠️ 實戰步驟
5.1 步驟一:開檔,並且先把符號路徑弄對
5.2 步驟二:讀標頭——bugcheck 名稱與四個 Arguments
5.3 步驟三:讀歸因四欄——它認為兇手是誰
5.4 步驟四:讀 STACK_TEXT——證據在這裡
5.5 步驟五:讀分類指紋——BUCKET_ID 與 FAILURE_BUCKET_ID
5.6 步驟六:驗證——三個交叉檢查
6 🔬 底層機制:!analyze -v 的結論是怎麼被推出來的?
7 🔙 萬一翻車:報告指錯人的時候怎麼辦
7.1 情境一:MODULE_NAME 顯示 nt(Windows 核心)
7.2 情境二:每份 dump 的 FAILURE_BUCKET_ID 都不一樣
7.3 情境三:報告看起來很合理,但換掉那個驅動還是照樣藍屏
8 💡 總結:進階玩法與底層邏輯
9 ❓ 常見問題
10 📎 參考資料來源
11 🔗 延伸閱讀

⚡ 站長快讀:核心重點

  • 文章屬性:教學實戰(工具判讀)
  • 適用系統:Windows 10 / Windows 11(x64 與 ARM64 皆適用)
  • 難易度 / 耗時:⭐⭐ / 首次約 20 分鐘,熟了之後每份 dump 約 3 分鐘
  • 核心結論:!analyze -v 的報告不是一坨亂碼,而是「事故現場描述 → 歸因結論 → 證據堆疊 → 分類指紋」四段式結構;照這個順序讀,你會知道它「說了什麼」,更會知道「它憑什麼這樣說」。
  • 適用對象:已經會用 WinDbg 開 dump 檔,但看到滿螢幕欄位不知道該從哪一行看起的人。

📌 快速答案

一句話答案:WinDbg !analyze -v 的報告請照四段讀——先看最上方的 bugcheck 名稱與 Arguments 確認事故性質,再看 MODULE_NAME 與 IMAGE_NAME 拿到嫌疑模組,接著用 STACK_TEXT 由下往上驗證這條路徑合不合理,最後把 FAILURE_BUCKET_ID 當成這次當機的分類指紋拿去比對。

🧰 開始前的準備

  • 系統需求:Windows 10(1607 以上)或 Windows 11 皆可;WinDbg 官方支援 x64 與 ARM64 兩種處理器架構。
  • 權限需求:一般使用者即可讀取 dump 檔;若要從 %SystemRoot%\Minidump 複製檔案,通常需要系統管理員權限。
  • 需要工具:WinDbg(即原本 Microsoft Store 上的 WinDbg Preview,微軟官方註明它與 WinDbg classic 使用同一套引擎,支援相同指令與擴充功能)。用 Windows 套件管理員安裝的話,執行下面這行:
winget install Microsoft.WinDbg
  • 需要檔案:一份 .dmp 檔。小型記憶體傾印(minidump)的清單放在 %SystemRoot%\Minidump,檔名帶當機日期,例如 mini022900-01.dmp 表示該日產生的第一份;完整版通常是 C:\Windows\MEMORY.DMP。
  • 預計耗時:約 20 分鐘(第一次要等符號檔下載)。
  • 難度門檻:只要會複製貼上一行指令、看得懂英文欄位名稱就能做。不需要會寫程式,也不需要懂組合語言。

⚠️ 先說清楚:本文全程只做唯讀分析——開啟 dump 檔、下判讀指令,不會修改系統設定、不會動登錄檔、不會碰驅動程式。真正的修復動作(停用驅動、跑 Driver Verifier)請看文末延伸閱讀的對應專文。

🔍 為什麼你需要這個?

你大概是這樣走過來的:電腦藍屏了,上網查到「用 WinDbg 跑 !analyze -v」,照做了,然後畫面吐出兩百行英文,你只看得懂最上面那個 bugcheck 名稱,以及某個好心網友教你去找的 MODULE_NAME。找到之後呢?如果 MODULE_NAME 寫的是 nt(也就是 Windows 核心本身),你就卡住了——總不能說是微軟自己壞掉。

這篇文章要補的就是這一段:報告的每一欄各自在回答什麼問題,以及當「三行速讀法」給不出答案時,你還有哪些欄位可以繼續往下追。

站內已經有一篇 WinDbg 藍畫面 minidump 分析教學,那篇教的是「從零安裝到開檔、看三行輸出快速結案」的完整動線,適合第一次接觸的人。本文是它的下一層:同一份報告,逐欄位拆開來看。兩篇的定位刻意分工,不重複。

本文比一般教學多給你三件事,先講在前面免得你讀到一半才發現不是你要的:

  1. FAILURE_BUCKET_ID 在微軟官方文件裡其實沒有欄位定義。 官方〈Using the !analyze Extension〉逐欄說明的是 BUCKET_ID 與 DEFAULT_BUCKET_ID;FAILURE_BUCKET_ID 是現行版本輸出裡確實會出現、但官方參考文件未逐欄定義的欄位。中文圈很多教學把它講得像官方規格,本文會標清楚哪些是官方定義、哪些是從實際輸出樣態歸納出來的。
  2. STACK_TEXT 的五欄怎麼切、要從哪一端開始讀。 大多數教學只叫你「看有沒有第三方 .sys」,但沒告訴你這串數字哪幾欄是位址、哪幾欄是參數。
  3. !analyze -v 會指錯人的三種結構性原因。 這不是玄學,而是可以從官方文件描述的 Followup 演算法與 minidump 內容清單直接推出來的。知道它為什麼會錯,你才知道什麼時候該相信它。

🛠️ 實戰步驟

步驟一:開檔,並且先把符號路徑弄對

這一步沒做好,後面所有欄位都會是垃圾。 符號檔(symbol files)是把記憶體位址翻譯成函式名稱的對照表;沒有符號,STACK_TEXT 會只剩一堆十六進位數字,MODULE_NAME 也可能整個抓錯。

最快的做法是用官方建議的 .symfix。微軟文件的原話是把它當成「快速上手」用法:設定一條指向微軟公開符號伺服器的預設路徑,大多數除錯情境都夠用。要指定本機快取目錄的話,在後面加上路徑:

廣告
.symfix C:\Symbols

如果你想自己把整串寫出來,官方的 srv*localcache*symbolstore 寫法是這樣:

.sympath srv*C:\Symbols*https://msdl.microsoft.com/download/symbols

設定完之後重新載入模組符號:

.reload

開 dump 檔有兩種方式。從命令列直接開:

windbg -y <SymbolPath> -i <ImagePath> -z <DumpFileName>

或是 WinDbg 已經開著的時候,用檔案選單開啟。這裡有個版本差異要注意:官方文件的敘述 File | Open Crash Dump 是 WinDbg classic 的選單名稱;現行 WinDbg(前身為 WinDbg Preview)在 File → Start debugging → Open dump file。兩版的快速鍵都是 Ctrl + D,記快速鍵最保險。

💡 為什麼要這樣做? 微軟文件明講,符號檔帶有日期與時間戳記,除錯器一定會去找與二進位檔時間戳記相符的那一份,所以你不必擔心它抓到錯的版本。真正該擔心的是「一份都沒抓到」。符號載入失敗時 WinDbg 會印出 * ERROR: Symbols could not be loaded for … 或 * WARNING: symbols checksum is wrong … 這類訊息,但它們夾在開檔時的大量輸出裡很容易被滑過去;而下方的欄位區本身不會標示符號品質,照樣給你一個看起來很像答案的模組名稱。所以請往上捲,先確認沒有這些訊息再讀結論。

步驟二:讀標頭——bugcheck 名稱與四個 Arguments

跑起來:

!analyze -v

在核心模式下,!analyze 顯示的是最近一次 bugcheck 的資訊;而且官方文件註明,發生 bugcheck 時分析畫面會自動產生,加 -v 只是要它多說一點。

廣告

報告最上方長這樣(以官方文件的核心模式範例為準):

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pagable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.

Arguments:
Arg1: 00000004, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: f832035c, address which referenced memory

這一段要讀兩層意思:

第一層是停止碼本身。官方特別提醒,這段制式說明文字「有些內容可能不適用於你這一次的當機」——它是該 bugcheck 類型的通用敘述,不是針對你這台機器的診斷。

第二層是 Arguments(也就是 Parameter 1~4),而且它們每一個後面都會跟一句說明。以上面的例子來說,Arg3 是 1,後面直接告訴你「1 代表寫入操作」。這四個參數的語意每個停止碼都不一樣,這也是為什麼站內每個常見停止碼都各自有一篇專文——參數表是逐碼查的,不能套用。

離線小技巧:手上沒有 dump 檔,只有藍屏畫面拍下來的代碼,也可以直接查:

!analyze -show 0xD1

官方文件說明 -show BugCheckCode [BugParameters] 會顯示指定 bugcheck 的資訊,後面最多可再接四個參數(以空白分隔)來縮小範圍。前提是 WinDbg 要處於核心模式工作階段——-show 只列在官方的核心模式語法區塊裡,所以請先開一份核心模式的當機傾印檔(minidump 或 MEMORY.DMP)、或建立核心模式連線,再下這道指令。開了 WinDbg 空視窗不能查,開使用者模式的 dump 也不算。

廣告

步驟三:讀歸因四欄——它認為兇手是誰

接下來這幾欄是 !analyze -v 的結論區——四個歸因欄位加一個時間戳記欄位,官方文件把它們放在一起說明:

FOLLOWUP_IP:
USBPORT!USBPORT_BadRequestFlush+7c
f832035c 894204           mov     [edx+0x4],eax

SYMBOL_NAME:  USBPORT!USBPORT_BadRequestFlush+7c
MODULE_NAME:  USBPORT
IMAGE_NAME:  USBPORT.SYS
欄位官方定義白話講
FOLLOWUP_IP顯示可能造成錯誤的那道指令的反組譯內容「我覺得是這一行程式碼出事」
SYMBOL_NAME對應該指令的符號出事的函式叫什麼名字
MODULE_NAME對應該指令的模組出事的模組(不含副檔名)
IMAGE_NAME對應該指令的映像檔名你要去更新或停用的那個檔案
DEBUG_FLR_IMAGE_TIMESTAMP該映像檔的時間戳記用來確認版本

這裡有一個絕大多數教學不會講、但官方白紙黑字寫了的重點: 上述欄位不一定指向出事的那道指令。官方原文說明,如果控制權被轉移到一個無效位址,FAULTING_IP 會顯示那個無效位址;此時不會出現 FOLLOWUP_IP,取而代之的是 FAILED_INSTRUCTION_ADDRESS,顯示從該位址反組譯出來的內容(而且官方直說這段反組譯「大概沒有意義」)。同一情境下,SYMBOL_NAME、MODULE_NAME、IMAGE_NAME、DEBUG_FLR_IMAGE_TIMESTAMP 這幾欄會改成指向呼叫這道指令的人。

所以「看到 FAILED_INSTRUCTION_ADDRESS 而不是 FOLLOWUP_IP」本身就是一個訊號:控制權跳到了無效位址,歸因欄現在指的是呼叫者。

換句話說,MODULE_NAME 有時候是「兇手」,有時候是「最後一個看到兇手的人」。這個差別在追第三方驅動時非常關鍵。

另外還有幾個條件性欄位,官方也一併列出:

  • 處理器誤動作時,可能出現 SINGLE_BIT_ERROR、TWO_BIT_ERROR 或 POSSIBLE_INVALID_CONTROL_TRANSFER。
  • 疑似記憶體損毀時,CHKIMG_EXTENSION 欄位會直接告訴你該用哪一道 !chkimg 指令去查。
  • 若 bugcheck 發生在某個裝置驅動程式的程式碼內,其名稱可能出現在 BUGCHECKING_DRIVER 欄位。

看到 CHKIMG_EXTENSION 就照著跑,這是報告直接把下一步指令餵到你嘴邊,別浪費。

步驟四:讀 STACK_TEXT——證據在這裡

STACK_TEXT 是呼叫堆疊,官方定義一句話:顯示出錯元件的堆疊追蹤。它長這樣:

STACK_TEXT:  
f8950e90 f83206e0 024c7262 00000000 f8950edc USBPORT!USBPORT_BadRequestFlush+0x7c
f8950eb0 804f5561 81cc8644 81cc8028 6d9a2f30 USBPORT!USBPORT_DM_TimerDpc+0x10c
f8950fb4 804f5644 6e4be98e 00000000 ffdff000 nt!KiTimerListExpire+0xf3
f8950fe0 8052c47c 8053cf20 00000000 00002e42 nt!KiTimerExpiration+0xb0
f8950ff4 8052c16a efdefd44 00000000 00000000 nt!KiRetireDpcList+0x31

欄位怎麼切(這是最多人卡住的地方):

以 32 位元的輸出為例,一列由左到右是——第一欄是該堆疊框的位址,第二欄是返回位址(執行完這層之後要跳回去的地方),中間三欄是傳入的前三個參數,最後一欄才是重點:模組!函式+位移。

所以你眼睛真正要掃的是每一列最右邊那一段。中間那幾串十六進位數字,在絕大多數消費端排錯情境用不到,不用逐個去解。

閱讀方向:由下往上。 最底下是比較早發生的呼叫,最上面是最後執行到的地方。以上面這個例子來說,由下往上是:核心處理 DPC 佇列 → 計時器到期 → 計時器清單展開 → USBPORT 的計時器 DPC 常式 → USBPORT_BadRequestFlush 出事。這條路徑講的是一個完整故事:這不是使用者按了什麼,而是一個 USB 連接埠驅動掛在計時器上的延後程序呼叫在跑的時候踩到爛位址。

你要驗證的就是這個故事合不合理。如果 MODULE_NAME 說是某張顯示卡驅動,但 STACK_TEXT 從頭到尾都是檔案系統與磁碟相關的呼叫,那這個歸因就值得懷疑。

還有一欄要一起看:

STACK_COMMAND:  .trap fffffffff8950dfc ; kb

官方定義:STACK_COMMAND 顯示的是用來取得這份 STACK_TEXT 的指令,你可以拿它重跑一次堆疊,或改一下來取得相關的堆疊資訊。實務上這一欄的價值在於——它告訴你這份堆疊是從哪個情境還原出來的。看到 .trap 開頭,表示堆疊是從陷阱框(trap frame)還原;看到 .ecxr 開頭,表示是從例外的內容紀錄還原。

順帶一提,官方文件也說明了 TRAP_FRAME 這一欄:它顯示這次當機的陷阱框,而同樣的資訊可以用 .trap 指令自己看一次。使用者模式那邊對應的則是 EXCEPTION_RECORD,可用 .exr 查看。

步驟五:讀分類指紋——BUCKET_ID 與 FAILURE_BUCKET_ID

DEFAULT_BUCKET_ID:  DRIVER_FAULT
BUCKET_ID:  0xD1_W_USBPORT!USBPORT_BadRequestFlush+7c

官方對這兩欄的定義很明確:

  • DEFAULT_BUCKET_ID:這次故障所屬的大分類(例如 DRIVER_FAULT、APPLICATION_FAULT)。
  • BUCKET_ID:這次故障所屬的具體分類。官方補了一句關鍵的話——這個分類會決定除錯器要在分析輸出中額外顯示哪些資訊。也就是說,BUCKET_ID 不只是標籤,它會回頭影響你看到的報告內容。

那 FAILURE_BUCKET_ID 呢? 這裡必須誠實講:微軟的〈Using the !analyze Extension〉逐欄說明中並沒有 FAILURE_BUCKET_ID 這一欄,官方逐欄定義的是 BUCKET_ID 與 DEFAULT_BUCKET_ID。FAILURE_BUCKET_ID 是現行 WinDbg 輸出中確實會出現的欄位,在微軟問答(Microsoft Q&A)的實際案例貼文裡隨處可見,例如:

  • 0x9F_3_nvlddmkm_IMAGE_pci.sys
  • 0x124_0_GenuineIntel_PROCESSOR__UNKNOWN_IMAGE_GenuineIntel.sys
  • AV_nt!MiReplenishPageSlist

從這些實例可以歸納出的組成樣態(以下為歸納,非官方規格):它是用底線串起來的複合字串,前段通常是停止碼或故障型別縮寫(0x9F、0x124、AV 代表 access violation),中段是子類型或參數值,後段則是被歸因的符號名稱或 IMAGE_<檔名>。

實務上你只要記住兩件事:

  1. 它是這一次當機的指紋。把整串貼進搜尋引擎或微軟問答,常常能直接找到別人同樣症狀的討論串——這比貼 MODULE_NAME 有效得多,因為它同時帶了停止碼、子類型與模組。
  2. 多份 dump 的指紋一不一樣,決定了你要怎麼修。全部相同 → 同一個根因,追那個模組就對了;各不相同、模組還每次換人 → 高機率是記憶體、電源或儲存這類底層問題在到處砸東西,追個別驅動只是浪費時間。
!analyze -v 報告的五段閱讀順序流程圖
依 Microsoft Learn〈Using the !analyze Extension〉整理(2026-08-08 查證)

步驟六:驗證——三個交叉檢查

拿到結論之後,做這三個檢查再下判斷:

  1. 符號到底載進來了沒? 如果 STACK_TEXT 裡出現大量 +0x 後面接著超長偏移量、或整列只有位址沒有模組名,就是符號沒到位。用官方建議的方式打開詳細訊息重跑:
!sym noisy
  1. MODULE_NAME 與 STACK_TEXT 對得起來嗎? 前面說過,歸因四欄有可能指向的是呼叫者而不是肇事者。把 MODULE_NAME 拿去 STACK_TEXT 裡找,看它出現在第幾層、上下文合不合理。
  1. 這是不是 minidump 的極限? 官方對小型記憶體傾印的說明寫得很直白:它包含當機執行緒的核心模式呼叫堆疊,如果堆疊超過 16 KB,只會保留最上面的 16 KB;而且由於內容有限,不是由當機當下執行的執行緒直接造成的錯誤,可能無法透過分析這份檔案發現。看到報告怎麼看都兜不起來,先確認你手上是不是只有 minidump。

⚠️ 容量數字要注意版本差異:除錯器文件寫的是「剛好 64 KB」,那是較早期的規格;現行 Windows 10 / 11 的「啟動及修復」下拉選單標示的是 Small memory dump (256k),實際檔案通常大於 64 KB。判斷「是不是 minidump」請看檔案位置(%SystemRoot%\Minidump)與檔名樣式,不要拿 64 KB 當判準。

🔬 底層機制:!analyze -v 的結論是怎麼被推出來的?

這一段是本文的核心,也是「知道它為什麼會錯」的關鍵。

微軟官方文件把 Followup 欄位的判定演算法寫得非常清楚,拆成四步:

  1. 除錯器從堆疊最上層那一個框開始,判斷它是不是該為這次錯誤負責。
  2. 如果不是,就往下一個框繼續分析。
  3. 除錯器嘗試判斷這個框裡的模組與函式的擁有者。找得到擁有者,這個框就被認定為「有錯」;找不到,就繼續往下一個框,直到找到為止,或整個堆疊都掃完。
  4. 搜尋過程中第一個「找得到擁有者」的框,就被認定為有錯。 如果整個堆疊掃完都沒有找到任何資訊,就不顯示 Followup 欄位。而當你用 !analyze -v 時,FOLLOWUP_IP、SYMBOL_NAME、MODULE_NAME、IMAGE_NAME、DEBUG_FLR_IMAGE_TIMESTAMP 這幾欄指的就是這個框。

看懂這個演算法,三個結構性限制就自動浮出來了:

限制一:它找的是「第一個找得到擁有者的框」,不是「最可能出錯的框」。 演算法本身是由上往下的線性搜尋,一旦命中就停。所以真正的兇手如果在更下層,而上層某個框剛好可以歸屬給某個模組,報告就會停在上層那個模組。

限制二:擁有者資訊來自 triage.ini,而那是要自己建的。 官方明確寫著:「若要讓 Followup 欄位顯示有用的資訊,你必須先建立一個包含模組與函式擁有者名稱的 triage.ini 檔案。」這個檔案本來是設計給驅動開發團隊分派責任用的,一般使用者的環境當然沒有客製版本。這就是為什麼你常常看到 FOLLOWUP_NAME 是 MachineOwner 這種泛泛的值——它不是在指控你的機器,只是預設歸屬。

限制三:演算法只能在「dump 裡還留著的框」上跑。 官方對小型記憶體傾印的說明寫明:它包含當機執行緒的核心模式呼叫堆疊,若超過 16 KB,只納入最上面的 16 KB;而且由於資訊有限,非由當機當時執行之執行緒直接造成的錯誤,可能無法透過分析這份檔案發現。把這兩句話疊到上面那個「由上往下找第一個有擁有者的框」的演算法上,結論很直接:堆疊被截掉的部分,演算法連看都看不到。手上只有 minidump 又碰到深堆疊時,歸因會系統性地偏向上層。

另外附帶一個常被誤會的訊息(這不是限制,是雜訊):官方使用者模式範例裡明白顯示了 Debugger SolutionDb Connection::Open failed 80004005 這行,並解釋——如果你有連上網際網路,除錯器會嘗試存取微軟維護的當機解決方案資料庫;出現這個錯誤訊息表示你的機器連不上網,或該網站當時無法運作。這行不是你的 dump 檔壞掉,不用理它。

所以正確的心態是: !analyze -v 是一個做了大量自動化分析的分類器,不是一個判案的法官。官方自己的定位就是「除錯當機的目標電腦或應用程式,第一步是使用 !analyze 擴充指令」——第一步,不是最後一步。

補充一個實用細節:-v 後面其實可以帶數字。官方說明 -v[0..99] 可以指定 0 到 99 的詳細程度,不指定時預設值是 1;還可以用 -vv 顯示所有可用資訊。使用者模式下 -v6 會顯示全域以及每個執行緒上發現的內容。多數情況 -v 就夠,遇到怎麼看都缺線索的 dump,再往上加。

🔙 萬一翻車:報告指錯人的時候怎麼辦

這一節不是「回復系統設定」,因為前面全部都是唯讀操作;這裡要回退的是你的判斷。

情境一:MODULE_NAME 顯示 nt(Windows 核心)

不要停在這裡。nt 出現在歸因欄,多半代表核心在執行某個由第三方驅動排入的工作時出事,或是上層框找不到擁有者而往下掃到了核心。回頭做兩件事:把 STACK_TEXT 整條看完,找出最上面那個非 nt、非 hal 的模組;然後用 lm 列出載入模組清單,比對這個模組的版本與日期。

情境二:每份 dump 的 FAILURE_BUCKET_ID 都不一樣

如同步驟五說的,這通常不是「有很多個壞驅動」,而是有個更底層的東西在破壞記憶體內容。這時候追個別驅動的投資報酬率很低,應該轉向記憶體、電源、儲存與散熱這條線。

情境三:報告看起來很合理,但換掉那個驅動還是照樣藍屏

代表歸因停在了「第一個找得到擁有者的框」,而不是真兇。這時候該換工具了——Driver Verifier 會主動對驅動施壓,讓問題在當場爆出來、而不是等它去破壞別人的資料之後才被發現;而 Driver Verifier 本身觸發的 DRIVER_VERIFIER_DETECTED_VIOLATION(0xC4) 藍屏,參數會直接告訴你是哪一條規則被違反。這是從「被動讀報告」轉成「主動抓現行犯」的分界點。

💡 總結:進階玩法與底層邏輯

站長我看過太多人把 !analyze -v 當成扭蛋機——跑一次,看 MODULE_NAME 是誰,就去把那個驅動砍掉重灌,然後藍屏繼續。問題不在工具,在於沒有把報告當成證據鏈來讀。

把本文的四段結構記起來,你的閱讀順序就固定了:

  1. 標頭與 Arguments → 這是什麼性質的事故(唯一由核心直接產生、最可信的一段)
  2. 歸因四欄 → 它認為誰有責任(方便,但可能指到呼叫者)
  3. STACK_TEXT → 憑什麼這樣說(證據,由下往上讀故事)
  4. BUCKET_ID / FAILURE_BUCKET_ID → 這次當機的指紋(拿去比對與搜尋)

第一段的可信度最高,第二段的可信度最低。 因為第一段是核心在當機當下寫進 dump 的原始資料,第二段是一個線性搜尋演算法配上一份你根本沒有的 triage.ini 猜出來的結論。多數人卻是只讀第二段。

進階一點的玩法有三個:

  • !analyze -v -xmf output.xml:官方支援把分析輸出寫成 XML 檔。多份 dump 要做比對統計時,這比人工複製貼上省事非常多;搭配 -xmi 可加入模組資訊,-xcs 可加入內容與呼叫堆疊框。
  • !analyze -hang:官方說明,在核心模式下它會去調查系統持有的鎖,再掃描 DPC 佇列鏈。當機器不是藍屏而是整台卡住時,這個比 !analyze -v 有用。
  • .bugcheck:如果你只想看基本的 bugcheck 參數、不想看兩百行報告,官方建議用這道指令。

最後講一句可能不中聽的:看得懂報告不等於修得好機器。 報告能告訴你事故現場的樣子,但「這張顯示卡驅動與這版 BIOS 不合」這種結論,還是要靠更換變因去驗證。!analyze -v 幫你把搜索範圍從「整台電腦」縮小到「這三個模組」,這就已經是它最大的價值了。

❓ 常見問題

Q:!analyze -v 跑出來的報告要從哪裡看起?

從最上面往下:先看 bugcheck 名稱與 Arguments 四個參數確認事故性質,再看 MODULE_NAME 與 IMAGE_NAME 拿嫌疑名單,接著用 STACK_TEXT 由下往上驗證,最後用 FAILURE_BUCKET_ID 當指紋去比對其他 dump 或搜尋。不要一開始就跳到中間找關鍵字。

Q:STACK_TEXT 那一大串數字是什麼意思?我需要看懂嗎?

不需要全懂。以 32 位元輸出為例,一列的結構是「堆疊框位址、返回位址、前三個參數、模組!函式+位移」;實務上你只要看每一列最右邊那一段的模組與函式名稱,以及它們由下往上串起來是不是一個合理的執行路徑。中間的十六進位數字是給要進一步追記憶體內容的人用的。

Q:要怎麼知道是哪個驅動程式的問題?

IMAGE_NAME 是最直接的候選,但官方文件明講:當控制權被轉移到無效位址時,SYMBOL_NAME、MODULE_NAME、IMAGE_NAME 會改成指向呼叫者。所以正確做法是:拿 IMAGE_NAME 當起點,回到 STACK_TEXT 找出最上面那個非 nt、非 hal 的第三方模組,兩者一致才下結論;不一致就以堆疊為準。

Q:FAILURE_BUCKET_ID 和 BUCKET_ID 差在哪?

官方文件逐欄定義的是 BUCKET_ID(這次故障的具體分類,會決定除錯器額外顯示哪些資訊)與 DEFAULT_BUCKET_ID(大分類);FAILURE_BUCKET_ID 則是現行輸出中會出現、但官方參考文件未逐欄定義的欄位。實務上把 FAILURE_BUCKET_ID 當成「這次當機的完整指紋」使用即可——它通常同時帶了停止碼、子類型與被歸因的模組,拿去搜尋比單獨貼模組名有效。

Q:報告裡的 Debugger SolutionDb Connection::Open failed 是不是我的 dump 檔壞了?

不是。官方範例裡就有這一行,並說明除錯器會嘗試連線微軟維護的當機解決方案資料庫,連不上時就顯示這個錯誤。它不影響本機分析結果,忽略即可。

Q:這個方法在舊版本也適用嗎?

適用。目前的 WinDbg(前身為 Microsoft Store 上的 WinDbg Preview)與 WinDbg classic 使用同一套底層引擎,支援相同的指令、擴充功能與工作流程,!analyze 的欄位語意一致。要除錯更舊版本的 Windows,官方建議改用「Debugging Tools for Windows」裡的 WinDbg classic。需要注意的是,微軟官方文件中的範例輸出取自較早期版本,實際欄位的出現順序與數量會隨 WinDbg 版本與 bugcheck 類型變動——本文的閱讀順序是依「資訊性質」分段,不依畫面上的先後,所以不受影響。

📎 參考資料來源

📖 第一級|廠商官方:

📖 第二級|實例參考(使用者貼文,僅作 FAILURE_BUCKET_ID 字串樣態舉例,不作規格依據):

⚠️ 本文核心事實以第一級為準,第二級僅供字串樣態舉例。

🔗 延伸閱讀

📅 本文查證戳記:2026-08-08 依據 Microsoft Learn 官方除錯器文件撰寫,適用 Windows 10 / Windows 11 上的現行 WinDbg。

若你在後續版本遇到欄位名稱變動或步驟失效,歡迎在留言區回報,站長會更新文章。

廣告