ProcDump 教學|抓應用程式當機與沒回應傾印檔

一句話答案:ProcDump 是微軟官方的命令列傾印工具,對「沒回應」的程式執行 procdump -accepteula -h -ma 程式名 C:\Dumps、對「會當掉」的程式執行 procdump -accepteula -e -ma 程式名 C:\Dumps,就會在觸發當下把該行程的記憶體寫成 .dmp 檔供 WinDbg 分析。

🧰 開始前的準備

系統需求:官方頁面標示的支援範圍為用戶端 Windows 11 以上、伺服器 Windows Server 2016 以上
權限需求:建議以系統管理員身分開啟命令提示字元;若要抓服務或其他帳號的行程,系統管理員權限是必要的
需要工具:ProcDump v12.01(官方下載約 1.2 MB,2026 年 7 月 9 日發布,作者 Mark Russinovich 與 Andrew Richards);分析階段需要 WinDbg
預計耗時:解壓縮即可使用,無安裝程序;實際擷取時間依傾印類型與該行程的記憶體用量而異(官方文件未提供時間基準)
難度門檻:只要會開命令提示字元、會 cd 到解壓縮的資料夾就能做完抓取;分析階段才需要 WinDbg 基礎

🔍 為什麼你需要這個?

程式卡死的當下,你能做的事情其實少得可憐。工作管理員只告訴你「沒有回應」,事件檢視器頂多留下一行 Application Error 加上模組名稱與位移值,重開機之後現場就消失了。等你想找原廠回報,對方第一句話多半是:「請提供當機時的傾印檔。」——問題是,那個檔案沒人幫你留。

ProcDump 解決的正是「現場只發生一次、而且不在你按下按鈕的時候」這件事。 它不是等你手動去按,而是掛在目標行程旁邊當監控者,設定好觸發條件之後就一直等;等到條件成立的那一瞬間,才把整個行程的記憶體狀態寫成 .dmp 檔。你人不必在電腦前面。

這篇要先講清楚三件很多教學會混在一起、抓錯就等於白抓的事:

「當機」和「沒回應」是兩種完全不同的觸發條件。 閃退走的是未處理例外(-e),卡死不動走的是視窗掛起(-h),兩者的偵測機制不一樣,參數也不能互換。用 -e 去等一個永遠不會拋例外、只是卡住的程式,你會等到天荒地老。
應用程式傾印檔不等於藍屏的核心傾印檔。 兩者副檔名同樣是 .dmp,但內容、分析指令、甚至能不能用某個指令都不一樣——例如關鍵的 .ecxr,官方文件明白寫著只在使用者模式、而且只在小型傾印(minidump)上可用。
傾印檔是一份記憶體快照,不是一份記錄檔。 裡面可能包含你當下打在那個程式裡的任何東西。這件事在你要把檔案寄給第三方之前,必須先想清楚。

以下的步驟全部依微軟官方文件撰寫,參數說明與範例皆對回 Sysinternals 官方 ProcDump 頁面。

🛠️ 實戰步驟

⚠️ 操作前提醒:ProcDump 監控時會附加到目標行程上,觸發時會短暫暫停該行程來寫出記憶體內容。在正式環境或線上服務上使用之前,請先評估這段暫停造成的影響;官方也為此提供了 -r(以複本方式傾印)與 -a、-at 這一組降低服務中斷的參數,本文最後一節會說明。

步驟一:下載、解壓縮與第一次執行

ProcDump 沒有安裝程式,官方發布的就是一個 ZIP 壓縮檔,解開後直接用。到 Sysinternals 官方 ProcDump 頁面按下載,取得的 Procdump.zip 約 1.2 MB,解壓縮之後會看到 procdump.exe 與 procdump64.exe(另有 ARM64 版本)。把整個資料夾放在一個你記得住的路徑,例如 C:\Tools\Procdump。

請務必從官方網域取得。 ProcDump 是一支能夠讀取任意行程記憶體的工具,從第三方軟體站下載到被改過的版本,後果不會只是「工具壞掉」而已。

接著建立一個專門放傾印檔的資料夾,例如 C:\Dumps。傾印檔動輒數百 MB 到數 GB,不要讓它散落在桌面或系統磁碟根目錄。

第一次執行時,工具會跳出 Sysinternals 授權條款對話框。如果你打算把指令寫進批次檔或排程,這個對話框會讓自動化整個卡住,官方為此提供了 -accepteula 參數,自動接受授權條款:

cd /d C:\Tools\Procdump
procdump.exe -accepteula

看到用法說明就代表可以動工了。本文後續所有範例都會帶上 -accepteula,養成習慣比較不會在無人值守的場合翻車。

步驟二:抓「沒回應」的視窗——`-h`

這是最常見、也最容易被誤解的情境:程式視窗變白、標題列出現「沒有回應」、滑鼠游標轉圈,但行程還活著,沒有閃退。

官方對 -h 的定義很明確:當行程有一個視窗至少 5 秒未回應視窗訊息時,就寫出傾印檔。這和 Windows 與工作管理員判定「沒有回應」用的是同一套定義,所以你在工作管理員上看到的狀態,就是 ProcDump 會抓的那個狀態。

procdump.exe -accepteula -h -ma myapp.exe C:\Dumps

拆開來看:

-h:觸發條件為視窗掛起
-ma:傾印類型為完整傾印(Full),包含所有記憶體(Image、Mapped、Private)與全部中繼資料
myapp.exe:目標行程名稱(同名行程只能有一個,否則要改用 PID)
C:\Dumps:輸出資料夾

指令下去之後視窗不要關,ProcDump 會一直等。等到程式真的卡住超過 5 秒,你會看到它寫出檔案,預設檔名格式是 PROCESSNAME_YYMMDD_HHMMSS.dmp。

如果同名行程有很多個(瀏覽器、svchost.exe 這類),用 PID 取代名稱。PID 可以在工作管理員的「詳細資料」分頁看到:

procdump.exe -accepteula -h -ma 4572 C:\Dumps

如果程式是一啟動就卡住,你根本來不及在它卡死前下指令。官方給了 -w:等待指定的行程啟動。先把 ProcDump 掛好,再去開程式:

procdump.exe -accepteula -w -h -ma myapp.exe C:\Dumps

💡 為什麼要這樣做? 掛起判定發生在視窗訊息迴圈這一層——程式的主執行緒沒有把訊息取走處理。這也是為什麼傾印檔抓回來之後,第一件事通常是去看主執行緒的呼叫堆疊:卡住的原因幾乎都寫在那裡,可能是等一個永遠不會回來的鎖、可能是在 UI 執行緒上做了同步的網路或磁碟 I/O。

步驟三:抓「當機、閃退」的瞬間——`-e` 與 `-t`

程式直接消失、跳出「已停止運作」,這是另一條路。官方文件的 -e 定義是:當行程遇到未處理的例外(unhandled exception)時寫出傾印檔。

procdump.exe -accepteula -e -ma myapp.exe C:\Dumps

如果閃退是被程式自己攔下來、外面看不到未處理例外,可以加上 1 改抓第一次機會例外(first chance exception):

procdump.exe -accepteula -e 1 -ma myapp.exe C:\Dumps

注意 -e 1 會抓到大量傾印檔。 正常運作的程式內部就會拋出並自行處理不少例外,每一次都寫一份完整傾印,磁碟很快就會滿。官方提供了兩個控制閥:-n 限制傾印次數上限、-f 依例外內容過濾。例如「只抓訊息含 NotFound 的例外,最多 10 份」:

procdump.exe -accepteula -ma -n 10 -e 1 -f NotFound myapp.exe C:\Dumps

還有一種情況是:程式不是當掉,是自己悄悄結束了。這時用 -t,在行程終止時寫出傾印:

procdump.exe -accepteula -t -ma myapp.exe C:\Dumps

如果閃退發生得毫無規律、你不可能一直守著, 官方的做法是把 ProcDump 註冊成系統的事後除錯器(AeDebug postmortem debugger),之後任何應用程式當掉都會自動產生傾印檔到指定資料夾:

procdump.exe -accepteula -ma -i C:\Dumps

這個指令會寫入登錄檔、改變系統的當機處理行為,用完務必依「萬一翻車」一節解除註冊。

步驟四:選對傾印類型——`-mm` / `-ma` / `-mt` / `-mp`

參數挑錯,檔案不是大到不能寄,就是小到看不出東西。官方定義的四種常用類型如下:

參數	類型	內容	適用時機
`-mm`	Mini(預設)	直接與間接被參考到的記憶體(堆疊及其所指向的內容)+ 全部中繼資料	只想看呼叫堆疊、要快要小
`-ma`	Full	所有記憶體(Image、Mapped、Private)+ 全部中繼資料	要看物件內容、記憶體洩漏,最常用
`-mt`	Triage	僅直接被參考的記憶體(堆疊)+ 有限中繼資料	要把檔案交給外部時
`-mp`	MiniPlus	所有 Private 記憶體與可讀寫的 Image/Mapped 記憶體	完整度接近 Full 但要控制檔案大小

-mp 的機制值得單獨說明:官方說明它會排除超過 512 MB 的最大單一 Private 記憶體區域(記憶體區域定義為同尺寸配置的總和)以縮小體積,結果是「細節與 Full 相當、大小約為 Full 的 10% 到 75%」。但官方同時註明:CLR 行程因為除錯限制,使用 -mp 時仍會以 Full(-ma)方式傾印——換句話說,.NET 程式用 -mp 省不到空間。

-mt(Triage)則是唯一一個以「減少敏感資訊」為設計目標的類型,官方原文的措辭是「嘗試移除敏感資訊,但不保證」。這個「不保證」四個字請記牢,下一節會回頭談。

還有一個常被忽略的 -mk:額外再寫一份核心傾印,內容是該行程各執行緒的核心堆疊。當你懷疑卡住的點其實在核心那一側(例如卡在某個驅動程式的 I/O),這份會很有用:

procdump.exe -accepteula -ma -mk -h myapp.exe C:\Dumps

官方註明 -mk 與 -r(複本傾印)不能併用,因為作業系統不支援對複本取核心傾印。

步驟五:驗證結果

ProcDump 觸發成功時,主控台會印出寫檔進度並顯示傾印檔完整路徑。要確認這份檔案能用,做三件事:

看檔案大小。 -ma 抓一個吃 1.5 GB 記憶體的程式,產出的檔案就該是那個量級。只有幾 MB,通常代表你抓的是預設的 -mm,或抓錯了行程。
看檔名。 預設格式為 PROCESSNAME_YYMMDD_HHMMSS.dmp。時間戳記要對得上你觀察到當機或卡死的時間點,對不上就是抓到別次事件。
用 WinDbg 開得起來。 這是唯一確定的驗證方式,見下一節。

🔬 底層機制:這個問題到底在系統哪一層?

使用者模式傾印與核心模式傾印,是兩種不同的東西

副檔名都是 .dmp,很容易讓人以為是同一類檔案。但它們來自系統完全不同的兩層:

使用者模式傾印(ProcDump 產出的這種)是「一個行程」的快照。它由 MiniDumpWriteDump 這條路徑寫出,內容是該行程的虛擬記憶體、執行緒、模組、控制代碼。系統其他部分不在裡面,核心也不在裡面(除非你加了 -mk)。

核心模式傾印(藍屏產生的那種)則是整個系統崩潰當下的核心記憶體快照,由系統在 bug check 之後寫出。要有這種檔案,前提是你事先在系統內設定好傾印類型與分頁檔——這部分我在Windows 記憶體傾印檔設定教學寫過完整流程。

這個分野會直接影響你能下什麼指令。以分析當機最關鍵的 .ecxr 為例,它的作用是把除錯器的暫存器內容切換到「例外發生當下」的那份 context record,讓你看到的堆疊是出事的堆疊,而不是傾印被寫出時的堆疊。官方文件在 Environment 表格裡把適用範圍寫得很死:Modes 為 User mode、Targets 為 Crash dump only(minidumps only)。拿它去對付核心傾印,不會有結果。

「沒回應」在系統裡是怎麼被判定的

Windows 判定一個視窗沒有回應,看的不是 CPU 使用率,也不是程式有沒有在做事,而是這個視窗的執行緒有沒有在時限內去取走訊息佇列裡的訊息。官方 IsHungAppWindow 文件把判準寫得很直白:程式若不是在等待輸入、也不是處於啟動處理中,而且在內部逾時時間 5 秒內沒有呼叫過 PeekMessage,就會被視為沒有回應——系統接著替它畫上那層白霧,並在標題列加上「沒有回應」。

ProcDump 的 -h 直接沿用這套定義,官方明寫門檻是「至少 5 秒未回應視窗訊息」。所以有兩件事必須先說清楚:

沒有視窗的程式(服務、背景常駐程式)不適用 -h。 它們根本沒有訊息迴圈,不會被判定掛起。這類目標要改用 -c(CPU 門檻)、-m(記憶體認可量門檻)或 -p(效能計數器門檻)當觸發條件。
「卡了 5 秒」不代表「壞了」。 一個正在讀大檔的程式也可能在主執行緒卡上幾秒。-h 會忠實地抓,你要自己判斷這份傾印有沒有意義。

隱私紅線:傾印檔裡面到底有什麼

-ma 的定義是「包含所有記憶體」。這句話沒有任何修辭成分——那個程式當下持有的字串、你剛剛輸入還沒送出的內容、記憶體裡的權杖與工作階段資料,只要它在該行程的位址空間裡,就會一起被寫進去。

這就是為什麼官方要另外設計 -mt(Triage),而且在說明中明白寫著它對敏感資訊的處理是「嘗試移除但不保證」。官方自己都不保證,你就不該當作它保證。

所以在把 .dmp 檔寄給軟體廠商、上傳到問題回報平台或貼進任何雲端空間之前,請先照這三點做:

能用 -mt 就不要用 -ma——除非對方明確要求完整傾印。
抓取之前先把該程式裡的敏感視窗關掉、登出帳號,再重現問題。
送出之前確認對方的資料處理政策。傾印檔屬於高含量的個人資料載體,不是一般的記錄檔。

🔙 萬一翻車:回退步驟

情境一:註冊成事後除錯器之後想還原

如果你用過 -i 把 ProcDump 註冊成 AeDebug 事後除錯器,系統的當機處理行為已經被改掉。官方提供的解除指令是:

procdump.exe -accepteula -u

執行後系統會恢復原本的當機處理設定。只要你不再需要自動抓取,就該立刻解除——放著不管,之後每一次應用程式當機都會產生一份完整傾印,磁碟空間會被慢慢吃掉。

情境二:ProcDump 卡住,目標行程被停住不動

寫出大型傾印檔時,目標行程會被暫停。如果你在這個時候直接關掉 ProcDump 的視窗,行程有可能維持在暫停狀態。官方為此設計了優雅終止的機制:對 ProcDump 視窗按 Ctrl+C,或用另一個視窗執行——

procdump.exe -accepteula -cancel 4572

(4572 換成目標行程的 PID)。官方說明這個做法與按 Ctrl+C 等效,而且優雅終止會確保目標行程在擷取中途被恢復執行;這道取消會套用到所有正在監控該行程的 ProcDump 執行個體。

情境三:磁碟被傾印檔塞爆

-e 1 或事後除錯器模式最容易造成這件事。處理順序:先用上面的方式停掉 ProcDump 或執行 -u 解除註冊,再去清理輸出資料夾。日後重新開跑時,務必加上 -n 限制份數,例如 -n 3。

如果你曾經改過 Windows 錯誤報告的本機傾印設定(下一節會提到),那些檔案預設會落在 %LOCALAPPDATA%\CrashDumps,別忘了一併檢查。

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

把 `.dmp` 丟進 WinDbg

抓到檔案只是一半。依官方《Analyzing a User-Mode Dump File》的說明,開啟方式有三種:命令列 windbg -z <檔名>、在 WinDbg 裡用官方文件所載的 File | Open Crash Dump 選單(快速鍵 Ctrl+D;該選單名稱為官方文件沿用的 WinDbg classic 介面用語,現行版本介面已更新,實務上以 Ctrl+D 或 windbg -z 最穩),或在除錯器執行中用 .opendump 指令再 g 繼續。官方也提到,除錯器可以直接讀取打包在 CAB 檔裡的傾印檔,但一個 CAB 裡有多份傾印時只會讀其中一份。

符號檔是成敗關鍵。 官方文件把「取得產生該傾印檔的 Windows 版本符號檔」列在分析步驟之前,而且提醒你還需要出問題那支應用程式本身的符號檔;若是商業軟體,得問原廠有沒有提供。沒有符號檔的分析報告會滿是問號,這件事我在 WinDbg Preview 安裝與符號路徑設定教學裡整理過完整設定方式。

開起來之後,一般的入手順序是先跑 !analyze -v 讓除錯器做初步歸因,再依照它給的方向往下查;!analyze -v 各欄位怎麼讀,可以參考逐欄位讀懂當機分析報告。要留意官方對小型傾印的提醒:分析 minidump 的方式與 full dump 相同,但因為保留的記憶體少很多,任何嘗試存取未保留記憶體的指令都無法正常運作——這也是當你需要深入看物件內容時應該一開始就用 -ma 的理由。

不想裝工具的兩條替代路

其一,工作管理員。 Windows 11 的工作管理員可以直接在「處理程序」或「詳細資料」分頁對行程按右鍵,選擇建立記憶體傾印檔。官方文件說明,這樣產生的使用者模式傾印檔會存放在 %localappdata%\Temp。缺點很明顯:你必須人在現場、而且趕得上在程式消失前按下去——ProcDump 存在的理由正是為了解決這件事。

其二,Windows 錯誤報告的本機傾印。 官方文件《Collecting User-Mode Dumps》說明,可以在 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps 底下設定,讓應用程式當機後自動把傾印檔留在本機。幾個官方載明的重點:這個功能預設未啟用、啟用需要系統管理員權限;DumpFolder 預設為 %LOCALAPPDATA%\CrashDumps;DumpCount 預設 10,超過就以新檔取代最舊的檔案;DumpType 預設值是 1(小型傾印),要完整傾印得改成 2。你也可以在 LocalDumps 底下建立以執行檔命名的子機碼(例如 MyApplication.exe),做單一程式的個別設定,系統會先讀全域設定再用個別設定覆寫。官方另外註明:若已為應用程式當機設定了自動除錯,就不會收集當機傾印——這正好和上面 ProcDump 的 -i 事後除錯器模式互斥,兩條路請擇一。

⚠️ 修改登錄檔前請先匯出備份。這一段涉及 HKEY_LOCAL_MACHINE,設錯會影響全系統的當機處理行為。

線上服務怎麼降低中斷

正式環境上跑 ProcDump 最大的顧慮是傾印期間行程被暫停。官方的解法是 -r:以複本(clone)方式傾印,Windows 8.1 之後使用 PSS 機制,支援所有觸發類型,並行上限預設 1、最多 5。搭配 -a(避免中斷,需與 -r 併用,當並行上限被超過而會造成長時間暫停時直接略過該次觸發)與 -at <秒數>(逾時就取消該次擷取),可以把風險壓下來。官方對並行數有明確警告:數值開太高會影響系統效能。

procdump.exe -accepteula -r 5 -ma -n 5 -s 15 myapp.exe C:\Dumps

站長的話

老實說,這篇的參數與行為全部來自微軟官方文件與 Sysinternals 官方頁面的交叉查證,不是站長我在特定機器上的實測數據——ProcDump 的行為高度依賴目標程式本身,拿我的環境數字當你的預期值,反而會誤導。我能給的判斷是:遇到「重現不了、發生時人不在」的當機問題,先用 -h 或 -e 掛著,比反覆猜測有效率得多;而在把傾印檔交出去之前多想三十秒,通常比你事後補救划算。

若你在後續版本遇到參數行為改變,歡迎在留言區回報。

❓ 常見問題

Q:ProcDump 要去哪裡下載、需要安裝嗎?

到微軟 Learn 的 Sysinternals ProcDump 官方頁面下載,檔案是一個約 1.2 MB 的 ZIP。不需要安裝,解壓縮後直接執行 procdump.exe 即可。目前官方頁面上的版本是 v12.01,發布日期為 2026 年 7 月 9 日。請勿從第三方軟體站取得。

Q:應用程式沒回應,我要下哪一條指令?

procdump.exe -accepteula -h -ma 程式名 C:\Dumps。-h 的官方定義是「視窗至少 5 秒未回應視窗訊息時寫出傾印」,和工作管理員判定「沒有回應」用的是同一套標準。如果同名行程不只一個,把程式名換成 PID。

Q:-ma 和預設的 -mm 差在哪?我該用哪個?

-mm(預設)只包含直接與間接被參考到的記憶體,-ma 包含所有記憶體。只想看呼叫堆疊用 -mm 就夠,要看物件內容或查記憶體洩漏就要 -ma。官方也提醒,小型傾印保留的記憶體少,存取未保留記憶體的除錯指令會無法正常運作。

Q:抓到的 .dmp 檔要怎麼用 WinDbg 分析?

用 windbg -z <檔名>,或在 WinDbg 中按 Ctrl+D 選 Open Crash Dump。開啟前務必先設定好符號路徑,而且除了 Windows 的符號檔之外,還需要出問題那支應用程式的符號檔——商業軟體要向原廠索取。

Q:跟藍屏的核心傾印檔有什麼不同?

ProcDump 產生的是單一行程的使用者模式傾印;藍屏產生的是整個系統的核心模式傾印,而且需要事先在系統內設定傾印類型與分頁檔。兩者能用的除錯指令並不相同,例如 .ecxr 官方標示為 User mode、且僅適用於 crash dump 中的 minidump。

Q:這些方法在 Windows 10 也能用嗎?

官方 ProcDump 頁面目前標示的支援範圍是用戶端 Windows 11 以上、伺服器 Windows Server 2016 以上,Windows 10 已不在官方標示的支援清單內。WER 本機傾印(LocalDumps)則是自 Windows Server 2008 與 Windows Vista SP1 起就提供的機制。

Q:抓傾印檔會不會把我的密碼一起抓走?

有可能。-ma 的定義是包含所有記憶體,程式當下持有的任何內容都可能在裡面。官方唯一針對敏感資訊設計的類型是 -mt(Triage),但其原文措辭是「嘗試移除敏感資訊但不保證」。要交給第三方時,請優先使用 -mt,並在抓取前先關閉敏感視窗、登出帳號。

🔗 延伸閱讀

📎 參考資料來源

📖 第一級|廠商官方:

ProcDump v12.01 — Sysinternals(Microsoft Learn) — 2026-08-22 查證
Collecting User-Mode Dumps — Win32 apps(Microsoft Learn) — 2026-08-22 查證
Analyzing a User-Mode Dump File — Windows drivers(Microsoft Learn) — 2026-08-22 查證
.ecxr (Display Exception Context Record) — Windows drivers(Microsoft Learn) — 2026-08-22 查證
IsHungAppWindow 函式 — Win32 apps(Microsoft Learn) — 2026-08-22 查證
Task Manager live memory dump — Windows drivers(Microsoft Learn) — 2026-08-22 查證

⚠️ 本文核心事實以第一級官方文件為準,全文未輸出第一人稱實測數據。

📅 本文查證戳記:2026-08-22 依據 Sysinternals ProcDump v12.01 官方文件撰寫。
若你在後續版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。