DumpChk 教學|免開 WinDbg 先驗傾印檔是否完整

內容目錄 顯示

⚡ 本文重點

文章屬性:教學實戰
適用系統:Windows 10、Windows 11(路徑與指令以 64 位元 x64 版為準)
難易度 / 耗時:★★☆ / 約 20–40 分鐘(多數時間花在安裝 Windows SDK)
核心結論:DumpChk 主要回答「這份傾印檔能不能被偵錯工具開啟」,另附檔案內容摘要;多數情況不必先設符號,也不做完整的根因分析,確認可用後再交給 WinDbg。
適用對象:手上有 MEMORY.DMP 或 Minidump 檔,準備自己分析或寄給技術人員的人

📌 快速答案

一句話答案:DumpChk 是微軟官方的傾印檔檢查工具,從 Windows SDK 安裝 Debugging Tools for Windows 後執行「dumpchk 傾印檔路徑」,結尾出現 Finished dump check 代表檔案可被偵錯工具開啟。
– 單獨安裝的 WinDbg 不含 DumpChk,要另外從 Windows SDK 安裝
– 結尾若是 DebugClient cannot open DumpFile,這份傾印檔已經損毀,改用另一份再分析

🧰 開始前的準備

系統需求:64 位元(x64)的 Windows 10 或 Windows 11;32 位元 Windows 請改用 32 位元工具(依微軟 Choosing the 32-bit or 64-bit Debugging Tools),Arm 裝置請依 KB 156280 改用與硬體平台相符的版本,兩者都不在本文步驟涵蓋範圍。要檢查的檔案可以是核心傾印 MEMORY.DMP、Minidump 資料夾裡的小型傾印,也可以是應用程式的使用者模式傾印(DumpChk 官方文件的健康範例就是一份使用者模式小型傾印)
權限需求:建議用系統管理員帳戶操作,並以系統管理員身分開啟命令提示字元;安裝軟體與讀取 C:\Windows 底下的系統檔案,在一般權限下可能被擋
需要工具:Windows SDK 安裝程式,安裝時只勾 Debugging Tools for Windows 即可
預計耗時:約 20–40 分鐘;工具裝好以後,檢查一個檔案只要一行指令
難度門檻:會開命令提示字元、會複製貼上檔案路徑就能做
磁碟空間:要把 MEMORY.DMP 複製一份到工作資料夾時,目的磁碟需要有與原檔相當的剩餘空間

🔍 為什麼你需要這個?

藍屏之後好不容易找到傾印檔,裝好 WinDbg、設好符號路徑,結果一開檔就報錯,前面花的時間全部白費。DumpChk(Microsoft Crash Dump File Checker)就是在這之前先確認檔案能不能用的工具:依微軟文件,它會快速分析傾印檔、列出檔案內容摘要,並找出已損毀、偵錯工具打不開的傾印檔。

DumpChk 的關鍵資訊分散在微軟好幾份文件裡,本文把會影響操作的三件事集中整理。

DumpChk 不在單獨安裝的 WinDbg 裡。微軟的 DumpChk 頁面附註寫明,獨立版的 Windows Debugger 不含 DumpChk,必須另外安裝 Debugging Tools for Windows(本文以 Windows SDK 安裝)。
依 KB 156280,它不需要存取符號,檢查核心傾印時還會印出停止碼。同一篇文件也寫明檢查完成時會顯示停止碼與參數;先跑一次就知道檔案能不能用,也知道是哪一種藍屏。
微軟兩份文件對「輸出中出現錯誤」的解讀不一樣。DumpChk 工具頁說有些錯誤無害,KB 156280 則說輸出任何部分出現錯誤就代表檔案損毀。本文把兩邊說法並列,並給出判讀順序。

要寄傾印檔給技術人員之前,這一步特別值得做:KB 156280 提到,先用 DumpChk 驗證可以省下上傳損毀傾印檔的時間與工夫。還沒設定好記憶體傾印的話,先看當機藍屏一閃就重開?先關自動重新啟動、設好記憶體傾印再抓兇手;想確認設定真的會產生傾印檔,可以參考 NotMyFault 教學:故意觸發 BSOD,驗證你的記憶體傾印設定真的有效。

🛠️ 實戰步驟

整個流程分成五步,前兩步只需要做一次;之後每次拿到新的傾印檔,從步驟三開始即可。

步驟一:確認電腦上有沒有 DumpChk

先以系統管理員身分開啟命令提示字元(開始功能表搜尋 cmd → 在「命令提示字元」上按右鍵 → 以系統管理員身分執行),輸入下面這行,在 Debugging Tools for Windows 的預設安裝資料夾裡搜尋 dumpchk.exe:

where /r "C:\Program Files (x86)\Windows Kits\10\Debuggers" dumpchk.exe

依微軟 where 命令參考,/r 會從指定資料夾開始逐層往下搜尋。有列出路徑,代表已經裝過;回報找不到檔案或找不到路徑,就繼續步驟二。C:\Program Files (x86)\Windows Kits\10\Debuggers 是微軟文件列出的 64 位元工具預設安裝根目錄,如果當初安裝時改過路徑,把指令裡的資料夾換成你的安裝位置。

where 可能列出好幾份 dumpchk.exe,因為微軟文件說明,安裝 Debugging Tools for Windows 會同時得到 32 位元與 64 位元兩套工具。KB 156280 建議使用和硬體平台相符的版本:一般 64 位元 Intel 或 AMD 電腦選路徑中含 x64 的那一份,微軟 KDNET 文件列出同一套工具的預設位置就是根目錄下的 C:\Program Files (x86)\Windows Kits\10\Debuggers\x64。另依微軟說明,在執行 64 位元 Windows 的 x64 電腦上分析傾印檔時,32 位元或 64 位元工具都可以使用。記下選定那一份所在的資料夾,已經裝過的話直接跳到步驟三。

💡 為什麼要先查? 電腦上裝了 WinDbg 不代表有 DumpChk。DumpChk 頁面的附註寫明,獨立版 Windows Debugger 不含 dumpchk,必須另外安裝 Debugging Tools for Windows;先查一次,可以避免在錯的資料夾裡找半天。

步驟二:從 Windows SDK 只安裝 Debugging Tools for Windows

到微軟的 Windows SDK 下載頁下載安裝程式。
執行安裝程式,走到選擇功能的畫面時,只勾 Debugging Tools for Windows,其餘項目全部取消。這是微軟文件說明的「單獨安裝除錯工具」方式,不必裝完整的 SDK。
安裝完成後,回到步驟一重跑 where /r 指令,這次應該會列出至少一個 dumpchk.exe 路徑。

列出多份時,依步驟一的說明選定路徑中含 x64 的那一份,記下所在資料夾。

💡 為什麼只勾一項? DumpChk 屬於 Debugging Tools for Windows 這個元件,SDK 的其他元件與檢查傾印檔無關;只裝需要的元件,下載量與安裝時間都比較少。

步驟三:把傾印檔複製到工作資料夾

微軟記憶體傾印檔選項文件列出的 CrashControl 登錄值 DumpFile 為 %SystemRoot%\Memory.dmp(一般就是 C:\Windows\MEMORY.DMP,核心或完整記憶體傾印就是這個檔),MinidumpDir 為 %SystemRoot%\Minidump,小型傾印每次當機會在這裡產生一個新檔。動手檢查前,先把要檢查的檔案複製一份出來:

mkdir C:\DumpCheck
copy C:\Windows\MEMORY.DMP C:\DumpCheck\
copy C:\Windows\Minidump\*.dmp C:\DumpCheck\

某一行回報找不到檔案,代表那一種傾印檔目前不存在,可能是這次當機沒有產生該類型,或檔案已被清除;傾印類型與存放路徑的設定方式,見前面連結的記憶體傾印設定教學。
如果你在 Startup and Recovery(啟動及修復)設定裡改過傾印檔路徑,把 C:\Windows\MEMORY.DMP 換成你設定的路徑。

💡 為什麼要先複製? 依微軟文件,勾選 Overwrite any existing file 時,下一次當機產生的核心或完整傾印會覆蓋舊檔;小型傾印則每次另存新檔、保留歷史。先複製一份,之後不管檢查結果如何,手上都有原始檔可以重來或寄出。

步驟四:執行 DumpChk 並把結果存成文字檔

切換到步驟一或步驟二記下的資料夾(下方指令以預設的 x64 資料夾為例),對傾印檔執行 DumpChk。輸出可能很長(官方範例光是一份使用者模式小型傾印,就印出了模組清單與整份環境變數),建議直接存成文字檔再看:

cd /d "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64"
dumpchk C:\DumpCheck\MEMORY.DMP > C:\DumpCheck\MEMORY_chk.txt 2>&1
notepad C:\DumpCheck\MEMORY_chk.txt

傾印檔路徑含空白時,依微軟文件規定必須用引號包起來,例如 dumpchk "D:\My Dumps\MEMORY.DMP"。
2>&1 讓錯誤輸出也寫進同一個文字檔,避免錯誤訊息只出現在螢幕上。
KB 156280 說明 DumpChk 會逐一驗證檔案裡所有的虛擬與實體位址;依此推論,檔案越大通常要等得越久,核心或完整傾印可能比小型傾印跑得久。

Minidump 資料夾一次有好幾個檔案時,可以在同一個命令提示字元視窗用一行 for 迴圈全部檢查,每個傾印檔會各產生一份同名的 .txt 結果檔:

for %f in (C:\DumpCheck\*.dmp) do dumpchk "%f" > "%f.txt" 2>&1

跑完以後,用 findstr 分兩次篩出結果:

findstr /m /c:"Finished dump check" C:\DumpCheck\*.txt
findstr /m /c:"DebugClient cannot open DumpFile" C:\DumpCheck\*.txt

依微軟 findstr 文件,/m 只列出含有該字串的檔名,/c: 會把引號內的整句當成字面字串比對。第一行列出的是檢查完成的結果檔,第二行列出的是打不開的檔案;兩邊都沒出現的結果檔,依〈讀懂 DumpChk 輸出結果〉判讀表「最後一行兩者都不是」那一列處理。

步驟五:驗證結果並決定下一步

打開結果檔,先看最後一行:是 Finished dump check,就可以把這份傾印檔交給 WinDbg 分析,或放心寄給技術人員;是 DebugClient cannot open DumpFile,這份檔案不必再花時間分析,直接換另一份。中間出現其他錯誤、或最後一行兩者都不是時,依〈讀懂 DumpChk 輸出結果〉一節的判讀表處理。

🧾 DumpChk 指令語法:一個選用參數加檔案路徑

DumpChk 的語法只有一行,依微軟文件的格式,方括號內的 -y 可以省略。

DumpChk [-y SymbolPath] DumpFile

參數	作用	什麼時候用
`-y SymbolPath`	指定 DumpChk 搜尋符號的位置,讓輸出中的名稱解析得更完整	結果不明確,或遇到需要符號資訊的傾印檔時
`DumpFile`	要檢查的傾印檔,可用絕對路徑、相對路徑或 UNC 網路路徑	每次都要給;路徑含空白必須加引號

大多數情況只需要「dumpchk 檔案路徑」這一種寫法。
要用微軟公開符號伺服器,可以把 SymbolPath 寫成 srv*C:\Symbols*https://msdl.microsoft.com/download/symbols,這是微軟 KB 315263 範例指令使用的符號路徑;C:\Symbols 是本機快取資料夾,可自行更換。
關於符號,微軟文件的說法有落差:KB 156280 與 KB 315263 都寫 DumpChk 不需要存取符號,DumpChk 工具頁則說某些傾印檔可能需要符號資訊。建議先不加 -y 跑一次,結果不明確時再加上 -y 重跑。

加上符號路徑的完整寫法如下。符號路徑較長,先存進變數 SYM 再帶入,避免單行指令過長:

set SYM=srv*C:\Symbols*https://msdl.microsoft.com/download/symbols
dumpchk -y %SYM% C:\DumpCheck\MEMORY.DMP > C:\DumpCheck\MEMORY_sym.txt 2>&1

🔎 讀懂 DumpChk 輸出結果:先看最後一行,再看中間的錯誤

DumpChk 工具頁以最後一行判定檔案能否開啟。依該頁說明,檔案沒有損毀時,輸出會以 Finished dump check 結尾;打不開的檔案則會以 DebugClient cannot open DumpFile 這類錯誤收尾。

輸出特徵	代表什麼	下一步
最後一行是 `Finished dump check`	檔案大致沒有損毀,偵錯工具能開啟;官方提醒仍可能有較細微的損毀	用 WinDbg 開啟並執行 `!analyze -v`
出現 `invalid file format`、`HRESULT 0x80004002`,最後是 `DebugClient cannot open DumpFile`	檔案已損毀,偵錯工具打不開	換另一份傾印檔,或重新複製、重新取得
沒指定符號路徑時出現大量符號錯誤	KB 156280 說明檢查損毀時可以忽略	不必處理,或加 `-y` 重跑
其他錯誤訊息,例如 `error 3 InitTypeRead( nt!_PEB at 7ffd5000)`	兩份官方文件說法不同,見下方說明	以最後一行為主,再用 WinDbg 開檔確認
最後一行兩者都不是	最後一行不是 `Finished dump check`,依微軟文件視為未通過檢查(可能損毀,或 DumpChk 沒有正常跑完)	重新複製傾印檔再跑一次;仍未通過就改用另一份,或用 WinDbg 開檔確認

DumpChk 輸出判讀對照圖:最後一行是 Finished dump check 代表大致沒有損毀、可被開啟;以 DebugClient cannot open DumpFile 收尾代表已損毀;未指定符號時的符號錯誤可忽略;其他錯誤兩份官方文件說法不同,以最後一行為主再用 WinDbg 確認;最後一行兩者都不是時重新複製再跑,或用 WinDbg 確認

官方的損毀範例依序出現三個訊號:Could not match Dump File signature - invalid file format、HRESULT 0x80004002 "No such interface supported",最後是 DebugClient cannot open DumpFile - error 80004002。
Finished dump check 只代表檔案「很可能」沒有損毀。DumpChk 工具頁提醒,檔案裡仍可能存在較細微的損毀;之後在 WinDbg 裡若遇到解不開的異常,傾印檔本身仍是嫌疑之一。
檢查核心傾印時,依 KB 156280 的範例,DumpChk 結束時會列出 BUGCHECK_CODE(停止碼)、BUGCHECK_P1 到 BUGCHECK_P4 四個參數,以及 IMAGE_NAME、FAILURE_BUCKET_ID 等欄位。這些欄位的意義,可以對照 WinDbg !analyze -v 完整教學逐欄解讀。
官方文件對「中間出現的其他錯誤」解讀不一致。DumpChk 工具頁說有些錯誤是無害的,並以 error 3 InitTypeRead( nt!_PEB at 7ffd5000) 為例;KB 156280 則寫,只要輸出任何部分出現錯誤,檔案就已損毀、無法分析。符號相關的錯誤,KB 156280 明寫可以忽略。

編輯部的建議是以最後一行為主要依據:結尾是 Finished dump check、中間卻有非符號類錯誤時,直接用 WinDbg 開檔;能正常載入並跑完 !analyze -v,就代表這份檔案可以用來分析。

🔬 底層機制:傾印檔在哪個環節可能壞掉?

傾印檔是在系統已經出錯的狀態下寫出來的,任何一個環節被打斷,檔案都可能不完整。依微軟文件,整個過程可以拆成三段:

當機當下:電腦當機並重新啟動時,實體記憶體的內容會寫進作業系統所在磁碟分割區的分頁檔;分頁檔或專用傾印檔必須大到足以容納所選的傾印類型,否則系統無法建立傾印檔。
寫入期間:傾印檔寫完之前,系統不會重新開機;而且依磁碟速度,寫出 2 GB 以上的記憶體內容可能要花很長時間。依這兩點推論,寫入過程若被強制關機或斷電打斷,留下的檔案就可能不完整,這正是 DumpChk 要抓的狀況。
寫完之後:勾選覆寫選項時,核心與完整傾印會被下一次當機的新檔覆蓋,這也是步驟三要先複製的原因。

DumpChk 檢查的是檔案本身能不能被解讀。KB 156280 說明,DumpChk 執行時會先顯示傾印檔的基本資訊,再驗證檔案裡所有的虛擬與實體位址,並回報找到的錯誤;DumpChk 工具頁也寫明,以 Finished dump check 結尾的檔案可以被偵錯工具開啟。它回答的是「這份檔案能不能用」,當機的根因仍要交給 WinDbg 分析。

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

把 DumpChk 放在 WinDbg 之前,是成本最低的一道關卡:複製傾印檔、執行 DumpChk、看最後一行,確認檔案可用之後再投入時間設定符號與分析。檢查核心傾印時,結尾順便列出的停止碼與參數,也能讓你先知道該查哪一種藍屏。

DumpChk 通過之後,還能用雜湊值、批次迴圈與符號路徑把檢查做得更完整。

確認複製前後內容一致:DumpChk 檢查的是檔案結構,要確認複製或上傳後的檔案和原檔一模一樣,可以在兩端各用 PowerShell 的 Get-FileHash C:\DumpCheck\MEMORY.DMP 算一次雜湊值。依微軟文件,Get-FileHash 預設使用 SHA256,兩個檔案雜湊值相同,內容就相同。
批次檢查整個 Minidump 資料夾:用步驟四的 for 迴圈與 findstr,一次篩出可用與損毀的檔案。
需要更完整的名稱解析時:加上 -y 指定符號路徑重跑。

DumpChk 不適用的情況也要知道:它只附帶停止碼與 IMAGE_NAME 等初步欄位,不做完整的根因分析,也不會修復損毀的檔案(官方文件沒有提到任何修復功能)。本文依 Microsoft Learn 上的 DumpChk、Debugging Tools for Windows 與記憶體傾印相關文件撰寫(2026-09-25 查證),適用 Windows 10 與 Windows 11。

❓ 常見問題

Q:DumpChk 跟 WinDbg 差在哪?

DumpChk 只回答「這份傾印檔能不能用」,並附上檔案內容摘要;WinDbg 是完整的偵錯工具,用來追查當機原因。KB 156280 寫明 DumpChk 不需要存取符號;用 WinDbg 解讀小型傾印時,KB 315263 則指出要一併載入符號與對應的二進位檔,才能正確解讀。

Q:傾印檔壞掉打不開怎麼辦?

DumpChk 只做檢查,官方文件沒有提到修復功能,所以處理方式是換一份可用的檔案。可以依序試這三個做法:回到原始位置重新複製一次;改用 Minidump 資料夾裡其他日期的小型傾印,微軟文件說明小型傾印每次當機都會另存新檔;確認分頁檔大小足以支援所選的傾印類型,再等下一次當機產生新檔,或參考前面連結的 NotMyFault 教學主動產生一份測試傾印。

Q:不裝 WinDbg,可以先做什麼?

先用 DumpChk 檢查:安裝 Debugging Tools for Windows 後,在命令提示字元執行 dumpchk,不必開啟任何偵錯工具視窗,也不必先設定符號路徑。這個元件本身包含 WinDbg 等偵錯工具,所以沒辦法完全不裝;另外,單獨安裝的 WinDbg 不含 DumpChk。

Q:明明裝了 WinDbg,為什麼找不到 dumpchk.exe?

因為單獨安裝的 WinDbg 不含 DumpChk。微軟 DumpChk 頁面的附註寫明,要使用 dumpchk 必須安裝 Debugging Tools for Windows;照步驟二從 Windows SDK 只勾 Debugging Tools for Windows 安裝即可,兩者可以並存。

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

本文步驟以 Windows 10 與 Windows 11 為準。要替較舊版本的 Windows 取得除錯工具,微軟文件建議到 Windows SDK 封存頁,下載你要除錯的那個 Windows 版本所對應的 SDK,安裝時同樣只選 Debugging Tools for Windows;KB 315263 也另外列出了 Windows XP、Vista、7 適用的 Dumpchk 說明頁。

🔗 延伸閱讀

📎 參考資料來源

📖 第一級|廠商官方:

DumpChk(Microsoft Learn) — 2026-09-25 查證
Use Dumpchk.exe to check a memory dump file(Microsoft Learn,KB 156280) — 2026-09-25 查證
How to read the small memory dump file that is created by Windows if a crash occurs(Microsoft Learn,KB 315263) — 2026-09-25 查證
Debugging Tools for Windows SDK and WDK(Microsoft Learn) — 2026-09-25 查證
Tools included in Debugging Tools for Windows(Microsoft Learn) — 2026-09-25 查證
Choosing the 32-bit or 64-bit Debugging Tools(Microsoft Learn) — 2026-09-25 查證
Set up KDNET network kernel debugging automatically(Microsoft Learn) — 2026-09-25 查證
Overview of memory dump file options for Windows(Microsoft Learn) — 2026-09-25 查證
Varieties of Kernel-Mode Dump Files(Microsoft Learn) — 2026-09-25 查證
Generate a kernel or complete crash dump(Microsoft Learn) — 2026-09-25 查證
How to determine the appropriate page file size for 64-bit versions of Windows(Microsoft Learn) — 2026-09-25 查證
where 命令參考(Microsoft Learn) — 2026-09-25 查證
findstr 命令參考(Microsoft Learn) — 2026-09-25 查證
Get-FileHash(Microsoft Learn) — 2026-09-25 查證

⚠️ 本文核心事實以第一級為準。

📅 本文查證戳記:2026-09-25 依據 Microsoft Learn 之 DumpChk、Debugging Tools for Windows 與記憶體傾印相關文件查證撰寫,內容整理自官方文件,未在實機上執行。
若你在後續版本遇到步驟失效,歡迎在留言區回報。