LiveDump 教學:不必讓系統當機重開,也能產生完整核心傾印檔

⚡ 站長快讀:核心重點

• 文章屬性:教學實戰
• 適用系統:Windows 11(工作管理員路徑需 OS build 22621.1992 以上);其他情境走 LiveKd 或 PowerShell 儲存診斷路徑
• 難易度 / 耗時:⭐⭐(調整節流的登錄檔進階段為 ⭐⭐⭐)/ 約 15 分鐘
• 核心結論:LiveDump 即時核心傾印讓系統照常執行,就能把核心記憶體的一致快照寫成 .dmp 檔,不必等藍屏、也不會重新開機。
• 適用對象:遇到系統卡頓、黑畫面、裝置沒回應,但機器沒當機、手上沒有 MEMORY.DMP 可分析的人

📌 快速答案

一句話答案:LiveDump 即時核心傾印是 Windows 內建能力,在工作管理員對 System 程序按右鍵選「建立即時核心記憶體傾印檔」,就能不當機、不重開機地取得完整核心傾印檔。

🧰 開始前的準備

• 系統需求:工作管理員內建路徑需 Windows 11 OS build 22621.1992 以上(2023 年 7 月 KB5028185 起提供);Windows Insider 早於此,Canary 通道 build 25276、Dev 通道 build 23419 起就有
• 權限需求:系統管理員。工作管理員必須以管理員層級帳號執行,否則會直接回錯誤
• 需要工具:分析端需 Debugging Tools for Windows(WinDbg);命令列路徑另需 LiveKd
• 磁碟與記憶體:官方儲存診斷範例產出的 LiveDump.dmp 為 867,135,488 位元組(約 827 MB),實際大小視所選項目與記憶體量而定;擷取當下還需要一塊足夠的可用實體記憶體暫存
• 預計耗時:官方文件未載明產檔需時多久,實際取決於你勾選的項目與記憶體量
• 難度門檻:會用工作管理員按右鍵就能完成第一條路;只有文末「🔙 萬一翻車」那段的登錄檔節流調整才需要看得懂 PowerShell

🔍 為什麼你需要這個?

排查 Windows 問題最尷尬的情況不是藍屏,而是「明明不對勁,但它就是不當機」:滑鼠會動、畫面會更新,可是某個 USB 裝置消失了、Wi-Fi 卡在連線中、或者整台機器每隔幾分鐘凍住兩秒。這種狀態下沒有 bug check、沒有 MEMORY.DMP,事件檢視器也只留下一行語焉不詳的警告,你手上根本沒有可以拿去分析的現場。

LiveDump 即時核心傾印就是為了填這個洞。微軟官方對它的定位寫得很直白:傳統 bug check 會重設電腦、打斷使用者的工作,而即時核心傾印的目標是「在異常狀況下蒐集資料,同時讓作業系統繼續運作」,適用於那些「非致命但影響很大」的失敗與停頓。換句話說,它把「取得核心記憶體快照」這件事,從「必須先讓系統死一次」的代價中解放出來。

這篇要講清楚三件在中文資料裡最常被跳過的事:

1. LiveDump 不是另一種當機:它產出的檔案用 WinDbg 打開後會顯示一個停止碼(例如 0x161 LIVE_SYSTEM_DUMP),但官方明講「這個碼永遠不會用於真正的 bug check,它只是用來標示這是即時傾印」——看到停止碼別急著以為系統當過機。
2. 產生的路徑有三條,適用面不同:工作管理員(最快、有 GUI)、LiveKd -ml(命令列與自動化)、Get-StorageDiagnosticInfo -IncludeLiveDump(專打儲存堆疊)。選錯路徑會白忙。
3. 抓不到檔案多半是節流,不是功能壞掉:系統自動產生的完整即時傾印預設在磁碟上「最多留 1 份」,而且全機預設 120 小時、單一元件預設 168 小時才准再產一次。不知道這件事的人,會誤判成功能沒開。

順帶一提,這篇跟站內既有的 LiveKd 即時核心除錯教學是互補關係:LiveKd 那篇重「互動」——把執行中的核心接給除錯器下指令;本篇重「產檔」——留下一份可以帶走、可以寄給廠商、可以事後慢慢看的傾印檔。

🛠️ 實戰步驟

⚠️ 執行前提醒:本節五個步驟都是唯讀取樣或產檔,不改系統設定;唯一會動到登錄檔的是文末「🔙 萬一翻車」段所講的節流調整,動手前請先看該段的備份說明與停止條件。擷取傾印檔時系統可能短暫停頓,請避開正在存檔或燒錄的時機。

步驟一:用工作管理員抓一份即時核心傾印檔

這是 Windows 11 內建、最快的一條路,也是多數人唯一需要的路徑。它的操作邏輯刻意做得跟「幫某個應用程式建立傾印檔」一樣,只是對象換成代表核心的 System 程序。

1. 以系統管理員身分啟動工作管理員。
2. 切到處理程序或詳細資料分頁。
3. 找到 System 程序。
4. 在該程序上按右鍵,選擇 建立即時核心記憶體傾印檔(Create live kernel memory dump file)。
5. 從展開的選單挑一種:完整即時核心記憶體傾印(Full live kernel memory dump)或 核心堆疊記憶體傾印(Kernel Stacks memory dump)。

完成後會跳出對話框告訴你檔案位置,按 開啟檔案位置 就能直接跳到資料夾。預設路徑是:

%LocalAppData%\Microsoft\Windows\TaskManager\LiveKernelDumps

也就是一般帳號下的 C:\Users\<你的帳號>\AppData\Local\...。順帶記一下對照:同一個右鍵選單對「一般應用程式」建立的使用者模式傾印檔,是丟在 %LocalAppData%\Temp,兩者不是同一個位置,別找錯資料夾。

💡 為什麼要這樣做? 這條路徑不需要事先調整任何當機傾印設定、只要工作管理員以系統管理員層級執行即可,是因為它走的是工作管理員自己送出的請求;分析時 !analyze 會回報 0x161 LIVE_SYSTEM_DUMP,而該停止碼的第一個參數固定是 0x005461736b6d6772——那串十六進位就是字串 Taskmgr 的編碼。看到這個參數,你就知道這份檔案是「有人手動按出來的」,不是系統自己出事。

步驟二:完整傾印還是核心堆疊?先想清楚要查什麼

兩個選項的差異不是「大小」而已,而是「能回答什麼問題」:

實務上的判斷很簡單:要看「誰在等誰」就選核心堆疊,檔案小、產得快;要看「記憶體裡到底放了什麼」才選完整。官方也提醒,加進去的資訊愈多,檔案愈大、錄製當下佔用的記憶體也愈多。

進階選項藏在工作管理員的設定裡,有三個開關值得認識:

• Capture Hypervisor memory pages:納入 hypervisor 為 Hyper-V 與虛擬機所使用的記憶體區域,可再選要不要含非必要頁面。
• Capture User Pages:當你要查的問題牽涉使用者模式記憶體時才需要打開。
• 記憶體壓力時中止:預設啟用。可用記憶體不足時直接放棄本次擷取,用意是把「抓傾印檔」對系統回應速度的影響壓到最低。

設定頁最上方那顆按鈕可以把這些選項一鍵還原成預設值——這也是本文唯一需要記住的「還原」動作,因為到這一步為止你完全沒有動到系統設定。

步驟三:用 WinDbg 驗證這份檔案真的可用

產完檔不代表事情做完了。把 .dmp 拉進 WinDbg(官方文件記載的開檔路徑是 File → Open Crash Dump,快速鍵 <kbd>Ctrl</kbd> + <kbd>D</kbd>;新版 WinDbg 的 Start debugging 面板另有開啟傾印檔的分頁,官方文件未列出該項目名稱),載入符號後先跑最基本的一行:

!analyze -v

你應該看到停止碼 0x161 (LIVE_SYSTEM_DUMP) 與上面提到的 Taskmgr 參數。若拿到的是系統自動產生的傾印檔、停止碼卻查不到說明,官方提供了一個很少人用的查詢法:

!analyze -show 0x144 0x3003

!analyze -show <code> 會直接把該即時傾印碼的說明與參數意義印出來(預設進位不是 16 進位時,<code> 要加 0x 前綴)。以上面的例子來說,它會告訴你 0x144 BUGCODE_USB3_DRIVER 的參數 1 值 0x3003 代表 USB3_WER_BUGCODE_USBHUB3_DEVICE_ENUMERATION_FAILURE,也就是「USB 裝置列舉失敗」。這比在搜尋引擎瞎猜停止碼有效率得多。

如果 WinDbg 開得起來、但讀某些位址時報錯,先別急著判斷檔案壞掉,見下方「底層機制」對部分即時傾印的說明。至於 !analyze 之後怎麼往下追模組與執行緒,站內另有 WinDbg 藍屏 minidump 分析教學可以接著看。

步驟四:命令列與自動化路徑(LiveKd 與儲存診斷)

工作管理員很方便,但它需要有人坐在電腦前面按。要遠端、排程或寫進腳本,有兩條官方路徑。

路徑 A:LiveKd -ml。Sysinternals 的 LiveKd(截至 2026 年 7 月 9 日發行的 v5.65)有兩個容易被搞混的參數:

livekd -ml -o C:\dumps\live.dmp

• -ml:用系統原生支援產生即時傾印(Windows 8.1 以上)。這才是本文講的 LiveDump。
• -m:產生鏡像傾印(mirror dump),那是 LiveKd 自己做的一致核心記憶體檢視,只含核心模式記憶體,而且可能需要相當可觀的可用實體記憶體;可用旗標遮罩挑選要納入的區域,預設 0x18F8。
• -o <檔名>:把記憶體傾印存到磁碟,而不是啟動除錯器。

這裡有個容易誤讀的地方要講清楚:-ml 所依賴的系統原生即時傾印支援始於 Windows 8.1,但LiveKd 工具本身官方標示的執行環境是用戶端 Windows 11 以上、伺服器 Windows Server 2016 以上——換句話說,更舊的用戶端版本不在 LiveKd 的官方支援範圍內,兩個「版本下限」不是同一件事。另外它需要先安裝 Debugging Tools for Windows。安裝與執行請分開兩次動作,不要串成一行。

路徑 B:儲存子系統診斷。當症狀集中在磁碟、SSD 或儲存控制器,微軟文件直接給了一組 PowerShell:

Get-StorageSubSystem

$sub = (Get-StorageSubSystem).FriendlyName
Get-StorageDiagnosticInfo -StorageSubSystemFriendlyName $sub `
  -IncludeLiveDump -DestinationPath C:\Diag

執行後會顯示蒐集進度,完成的傾印檔放在 [DestinationPath]\localhost 下,檔名就叫 LiveDump.dmp。官方範例中該檔為 867,135,488 位元組,用 !analyze 打開同樣會顯示 LIVE_SYSTEM_DUMP (161)。這條路的附加價值是它會連同其他儲存診斷記錄一起打包,適合要交給廠商的情境。

步驟五:讓系統「自己」在出事那一刻抓檔

前面三條都是「你知道要抓」才抓得到。真正難搞的間歇性問題,得靠系統在偵測到異常時自動出手——這正是 Windows 內建 watchdog 機制在做的事:某個操作啟動時初始化計時器,逾時未完成就對系統取一份即時傾印,事後再從呼叫堆疊與等待鏈回推它為什麼沒做完。

這類檔案預設放在 C:\WINDOWS\LiveKernelReports,而且分兩層擺:

完整傾印:%systemroot%\LiveKernelReports\*.dmp
迷你傾印:%systemroot%\LiveKernelReports\<元件名稱>\*.dmp

元件子資料夾就是官方列出的那幾個常見來源:

NDIS
PDCRevocation
PoW32kWatchdog
USBHUB3
WATCHDOG

官方只列出目錄名稱,沒有定義各目錄對應什麼症狀。從命名可以合理推測 NDIS 對應網路堆疊、PoW32kWatchdog 對應電源(Po)與 win32k 相關的逾時,但這是依名稱推測,不是官方定義,實際成因仍要打開檔案看。這些檔案是白撿的線索,查間歇性問題時值得先去翻一輪——順帶一提,顯示卡逾時的 0x117 VIDEO_TDR_TIMEOUT_DETECTED 與 0x141、0x142 也都在官方的即時傾印碼清單裡,如果你正在追顯卡逾時黑屏,這個資料夾值得先確認一次;不過受下面講的節流限制,有沒有檔案並不保證。

還有一個很少人知道的手動觸發點:停止碼 0x21C8 MANUALLY_INITIATED_BLACKSCREEN_HOTKEY_LIVE_DUMP 對應的是「系統已被設定為擷取即時傾印,而使用者按下了黑畫面熱鍵 <kbd>Ctrl</kbd> + <kbd>Shift</kbd> + <kbd>Win</kbd> + <kbd>B</kbd>」。也就是說,黑畫面當下按那組熱鍵,除了重設顯示驅動,在已設定的機器上還會留下一份可供分析的即時傾印。

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

要理解 LiveDump 為什麼「不用當機也做得到」,得先看它跟傳統 bug check 在時間軸上的差別。

傳統當機傾印的邏輯是:系統先停下來(所有處理器凍結、不再有新的寫入),再把記憶體慢慢寫進分頁檔。因為世界已經靜止,寫出來的東西必然一致。代價就是你得先失去這台機器。

即時核心傾印走的是另一條路:它建立的是核心記憶體的一致快照,並且為了把效能衝擊壓到最低,採用記憶體複製技術在短時間內完成檔案產出。系統照常跑,只是有一段極短的時間被拿去複製記憶體。這也解釋了為什麼工作管理員預設要開「記憶體壓力時中止」——複製需要一塊暫存空間,可用實體記憶體不夠時硬做,受害的是使用者體感。

內容上它也不是「整台機器的照片」。為了效能、檔案大小與擷取可靠度,官方明說有些東西不會收:待命清單(standby list)的頁面與檔案快取就不在裡面。實際會進到檔案裡的典型內容包括 KdDebuggerBlock 與已載入模組清單;每顆處理器則收 KiProcessorBlock、PRCB、目前堆疊、目前分頁目錄表、KI_USER_SHARED_DATA、NTOS 核心映像與 HAL 映像。視情況還可能包含執行緒與記憶體狀態、記憶體內記錄,以及某些使用者模式程序頁面;針對特定領域的失敗(例如 USB)還會另外收該領域的資料。

接著是最容易被誤判成「檔案壞了」的一種狀況:部分即時傾印(partial kernel live dump)。 當系統沒辦法可靠地擷取所有預期頁面時,它會改採過濾與排序的策略——先確保拿到「產出一份有效傾印檔所必需的重要資料」,例如核心頁面優先於使用者頁面。結果就是:檔案 WinDbg 仍然認得,但你去 dump 某個位址時可能會報錯。官方給的判斷方法是用 !pte 擴充指令檢查該位址的 PTE 是否有效:

!pte <位址>

PTE 有效卻讀不到,代表那頁只是沒被收進這份檔案,不是位址本身無效——這個區分,決定你要「再抓一次更完整的傾印」還是「回頭懷疑自己的位址算錯」。

一個常被忽略的前置動作

即時傾印跟一般當機傾印共用同一套除錯知識,但不共用設定。你在系統內容裡調的「寫入偵錯資訊」那組選項,管的是當機時要寫多大的 MEMORY.DMP;而官方文件在說明工作管理員即時核心傾印時,並未把那組設定列為前置條件,列出的失敗原因只有權限、逾時、前一份未完成與可用記憶體不足四項。反過來說,把即時傾印摸熟了,真的藍屏時能不能留下檔案,仍然得看當機傾印那一組設定——這兩件事該分開做,站內的當機藍屏記憶體傾印設定那篇講的是後者。

🔙 萬一翻車:回退步驟

只有調整系統自動產生即時傾印的節流設定,才會動到登錄檔。以下是完整的備份、變更與還原做法。

先備份,再動手(以下腳本含管理員檢查與登錄檔匯出):

# ===========================================
# 安全前綴:管理員權限檢查 + 操作前備份
# ===========================================
$id = [Security.Principal.WindowsIdentity]::GetCurrent()
$p  = New-Object Security.Principal.WindowsPrincipal($id)
$role = [Security.Principal.WindowsBuiltInRole]::Administrator
if (-not $p.IsInRole($role)) {
    Write-Warning "Task aborted: re-run this script as Administrator."
    exit 1
}

$BackupDir = "C:\Users\Public\Documents\TedTechBackup"
if (-not (Test-Path $BackupDir)) {
    New-Item -ItemType Directory -Path $BackupDir | Out-Null
}
$Stamp = Get-Date -Format "yyyyMMdd_HHmmss"
$BackupFile = Join-Path $BackupDir "CrashControl_$Stamp.reg"

# reg.exe 要用 HKLM\ 路徑,不是 HKLM:\
$RegPath = "HKLM\SYSTEM\CurrentControlSet\Control\CrashControl"
& reg.exe export "$RegPath" "$BackupFile" /y | Out-Null
if ($LASTEXITCODE -ne 0) {
    Write-Warning "Backup failed. Aborting registry modification."
    exit 1
}
Write-Output "Backup saved: $BackupFile"

可調的值(WER 即時核心報告設定)。Windows 10 1703、Windows Server 2019 以後,這組設定位於 HKLM\SYSTEM\CurrentControlSet\Control\CrashControl;Windows 10 1607 以前、Windows 8.1 與 Windows Server 2012 R2/2016 則在 HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting。

FullLiveKernelReports 子機碼下四個值:

另有 LiveKernelReports 子機碼下的 LiveKernelReportsPath(REG_SZ),可把儲存位置改到別的磁碟,但必須寫成 NT 路徑格式,例如 \??\C:\LiveDumpsFolder。

三個必須先講清楚的停止條件——符合任一項就不要繼續:

1. 你不確定目前這台機器上這些值原本是多少(先跑查詢再說,查詢腳本純唯讀)。
2. 備份腳本沒有印出 Backup saved。
3. 這是公司或學校的管控設備,而你沒有 IT 授權。

查詢現值(唯讀,免前綴):

$k = 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl\FullLiveKernelReports'
Get-ItemProperty -Path $k -ErrorAction SilentlyContinue |
  Format-List SystemThrottleThreshold, ComponentThrottleThreshold, FullLiveReportsMax

還原方式,依情境三選一:

情境一:改了節流值,但傾印檔還是沒出現

先把兩個門檻值還原成你備份檔裡的原值(不是憑印象填 120/168——各版本、各 OEM 映像的實際值不保證相同,要以 .reg 備份為準)。最保險的做法是直接匯入備份:

& reg.exe import "C:\Users\Public\Documents\TedTechBackup\CrashControl_<時間戳>.reg"

情境二:改完之後系統行為異常

同樣先匯入上面那份 .reg 備份,再重新開機讓設定生效。若備份檔遺失,以系統管理員身分執行 sfc /scannow 只能修檔案、修不了登錄值,此時應改由系統還原點回復。

情境三:系統無法正常開機

進入 Windows 復原環境(WinRE),選疑難排解 → 進階選項 → 系統還原,挑一個修改前的還原點。若你在動手前沒有建立還原點,也可以在 WinRE 的命令提示字元用 reg load 掛載離線的 SYSTEM 機碼後匯入備份——這一步難度較高,不確定就交給有經驗的人處理。

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

站長我把這篇的價值濃縮成一句話:LiveDump 即時核心傾印把「取得核心現場」的門檻,從一次當機降到一次右鍵。

有三個延伸玩法值得記住。第一,把即時傾印當成「對照組」——系統正常時先抓一份核心堆疊傾印存著,等問題發生再抓一份,兩份對比,誰多了一條卡住的等待鏈會非常明顯,這比對著單一份檔案硬猜有效得多。第二,交件給廠商時,Get-StorageDiagnosticInfo 那條路會連診斷記錄一起打包,比單獨寄一個 .dmp 更容易讓對方接手。第三,C:\WINDOWS\LiveKernelReports 值得排進你的例行檢查清單:那裡的檔案是系統自己在你沒注意的時候留下的,而且因為節流機制,它們往往代表了「最近一次真的很嚴重」的事件。

也講清楚本文的證據性質:本篇為官方文件導向的整理,所有步驟、預設值與路徑均取自 Microsoft Learn 與 Sysinternals 官方文件(查證日 2026-09-09),文中未包含站長第一手實機量測數據。你在自己的機器上會看到的檔案大小、產檔秒數與節流剩餘時間,都取決於硬體與版本,請以實際輸出為準。

最後一個容易踩的坑:即時傾印檔的分析需要對應的符號檔。用公開符號伺服器可以看到模組與函式名稱,但微軟未公開的內部資料結構仍然讀不出來——這是所有核心傾印分析共同的天花板,不是 LiveDump 特有的限制。

❓ 常見問題

Q:LiveDump 跟 LiveKd 到底差在哪?

差在「產物」。LiveKd 是把執行中的核心接給 kd 或 WinDbg,讓你即時下 !process、!thread 這類指令,重點是互動;LiveDump 是產生一份 .dmp 檔案,重點是留下可攜帶、可事後分析的現場。兩者可以合用:LiveKd 的 -ml 參數本身就是呼叫系統原生的即時傾印能力來產檔。

Q:抓即時核心傾印會讓系統當機或重開嗎?

不會。官方對此的說法是「不像其他手動產生核心記憶體傾印的方法,這個方法不會造成系統當機」。系統可能在複製記憶體那段極短時間內出現停頓感,但不會重新開機,也不會出現藍屏。

Q:我按了「建立即時核心記憶體傾印檔」卻失敗,怎麼辦?

官方列了幾個常見原因:工作管理員必須以管理員層級使用者執行;遇到逾時就過幾分鐘再試;還有前一份傾印尚未完成時不要接著再要一份。另外也可能「產生成功但內容不完整」——擷取當下需要足夠的可用實體記憶體來暫存要寫出去的內容,關掉不需要的程式,或取消勾選 hypervisor 與使用者模式頁面的擷取,通常就能改善。

Q:為什麼 C:\WINDOWS\LiveKernelReports 裡什麼都沒有?

多半是節流而不是故障。完整即時傾印預設在磁碟上最多只留 1 份(FullLiveReportsMax=1),而且全系統預設 120 小時、單一元件預設 168 小時內不會重複產生。另外在 Windows 10 1803、Windows Server 2019 以後,把 FullLiveReportsMax 設為 0 會直接停用即時傾印功能——如果這台機器被人動過設定,值得先查一下這個值。

Q:舊版 Windows 沒有工作管理員這個選單怎麼辦?

工作管理員的即時核心傾印是 2023 年才進入正式版的功能(OS build 22621.1992 起)。-ml 依賴的原生支援雖然始於 Windows 8.1,但 LiveKd 官方標示的執行環境是用戶端 Windows 11 以上、伺服器 Windows Server 2016 以上,舊用戶端不在官方支援範圍;針對儲存問題則可用 Get-StorageDiagnosticInfo -IncludeLiveDump。系統自動產生的 watchdog 即時傾印則不受此限,更早的版本就已存在。

📎 參考資料來源

📖 第一級|廠商官方:

• Kernel Live Dump Code Reference — 2026-09-09 查證
• Task Manager live memory dump — 2026-09-09 查證
• Bug Check 0x161: LIVE_SYSTEM_DUMP — 2026-09-09 查證
• Bug Check 0x21C8: MANUALLY_INITIATED_BLACKSCREEN_HOTKEY_LIVE_DUMP — 2026-09-09 查證
• WER Settings(FullLiveKernelReports 與 LiveKernelReports 子機碼) — 2026-09-09 查證
• LiveKd v5.65(Sysinternals) — 2026-09-09 查證
• Analyzing a Kernel-Mode Dump File with WinDbg — 2026-09-09 查證

⚠️ 本文核心事實以第一級為準,無第二級來源引用。

🔗 延伸閱讀

• WinDbg lmvm 教學:一行指令看懂當機驅動模組與版本資訊
• WinDbg 進階指令教學:用 !process、!irp、!thread 追出卡死的驅動程式與 I/O 請求
• WinDbg Time Travel Debugging 教學:錄製並回放程式執行過程
• ProcDump 教學:抓出應用程式沒回應與當機瞬間的記憶體傾印檔

📅 本文查證戳記:2026-09-09 依 Microsoft Learn 與 Sysinternals 官方文件撰寫。

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