⚡ 本文重點
- 文章屬性:教學實戰(WinDbg 進階除錯指令)
- 適用系統:Windows 11 或 Windows 10 1607 以上的 WinDbg,分析核心模式傾印檔
- 難易度 / 耗時:★★★ / 約 20–40 分鐘
- 核心結論:有差異之後還要判讀:跳往其他模組的指令可能是驅動 hook 或重新導向,整段變成無意義內容是官方範例中的記憶體損毀,用
-p比對後差異遍布整個模組則先懷疑參照檔版本。 - 適用對象:看過
!analyze -v、懷疑驅動改動核心或記憶體損毀的進階使用者與 IT 人員
📌 快速答案
一句話答案:WinDbg !chkimg 把記憶體中的驅動與核心映像,和符號伺服器上同版本的原檔逐位元組比對,列出被改的位址與前後數值,用來判斷程式碼是否遭竄改或損毀。
– 小型傾印檔(Minidump)不含執行檔映像,要完整比對整個模組,請改用核心記憶體傾印(Memory.dmp)
– 有差異只代表「不一樣」,還要反組譯差異位址、確認參照檔版本,才能判斷改動從哪裡來
🧰 開始前的準備
- 系統需求:WinDbg 支援 Windows 11 各版本與 Windows 10 1607 以上,處理器架構為 x64 與 ARM64;產生傾印檔的電腦,Windows 版本不必和分析用的電腦相同
- 權限需求:建議用系統管理員帳戶操作;從
%SystemRoot%複製Memory.dmp、開啟Minidump資料夾,或在出問題的電腦上把傾印類型改成核心記憶體傾印(見步驟一),在一般權限下可能被擋。分析本身只需要讀得到傾印檔副本 - 需要工具:WinDbg(官方安裝頁提供安裝檔、Microsoft Store 與
winget install Microsoft.WinDbg三種方式),以及能連上微軟公用符號伺服器的網路(只接受 TLS 1.2 以上的 https 連線) - 要分析的檔案:核心記憶體傾印(預設為
%SystemRoot%\Memory.dmp)或完整記憶體傾印;%SystemRoot%\Minidump裡的小型傾印檔幫助有限,原因見步驟一 - 預計耗時:約 20–40 分鐘;第一次比對時要從符號伺服器取回原始檔,網路慢會更久
- 難度門檻:會在 WinDbg 指令列輸入指令,看得懂
!analyze -v報告的基本欄位 - 磁碟空間:微軟概估核心記憶體傾印約為實體記憶體的三分之一(依情況差異很大),複製副本時目的磁碟要留足空間
🔍 為什麼你需要這個?
!analyze -v 把原因歸為 Probably caused by : memory_corruption,或是遇到 0x109 CRITICAL_STRUCTURE_CORRUPTION 這種「核心程式碼或資料被改」的藍屏時,光看報告通常還不夠:要換模組比對、看完整的差異與原本的指令,得自己動手比對。改動落在模組映像的程式碼時,WinDbg !chkimg 補的就是這一段:依微軟文件,它拿記憶體中的執行檔映像和符號伺服器上的原始檔比對,偵測映像損毀;官方也寫到,有些驅動會用 hook、重新導向等方式改動 Windows 核心,即使該驅動已經不在堆疊上,!chkimg 仍能找出核心哪些部分被改、被改成什麼樣子。
這個指令的官方參考頁只有一頁,影響判讀的細節卻散在傾印檔、符號伺服器與模組清單等多份文件裡,本文把四個最容易踩錯的地方放在最前面。
- 比對對象是原始執行檔,PDB 符號檔的作用是把差異位址顯示成函式名稱與位移。微軟公用符號伺服器除了符號,也提供部分二進位碼與執行檔;SymStore 以映像的時間戳記與大小存放執行檔,所以偵錯器取回的是和記憶體中同一版本的
.sys、.exe或.dll。 - 小型傾印檔能比對的範圍很有限。小型傾印檔不含任何執行檔映像,只另外收錄 Windows 判斷對除錯有用的記憶體頁,官方也寫明這種比對在完整傾印檔上最有效;手上只有 Minidump 時,先照步驟一改用核心記憶體傾印。
- 0 個差異不等於沒被動過。預設掃描會略過可寫入、不可執行、名稱含 PAGE 與可捨棄的區段;匯入位址表(IAT)則是官方列出的不檢查範圍,文件也沒有提供把它納入的參數。改動若落在這些地方,預設掃描看不到;其中可寫入、不可執行與名稱含 PAGE 的區段可加
-as納入,可捨棄區段與 IAT 則沒有參數能納入。 - 第三方驅動常要自己準備原始檔。符號伺服器上找不到的檔案,要用
-p指向你手上同版本的原始檔;拿不同版本比對,差異再多也不代表竄改。
📖 WinDbg !chkimg 指令語法與參數
!chkimg 的語法是「選項+模組」,日常最常用的是 -d、-db、-p 與模組名稱。
!chkimg [Options] [-mmw LogFile LogOptions] [Module]Module 可以寫模組名稱、模組起始位址,或模組內的任一位址;省略時,偵錯器會檢查目前指令指標所在的模組。模組名稱通常是檔名去掉副檔名,核心 Ntoskrnl.exe 的模組名是 nt,官方文件以 Flpydisk.sys 為例,對應的模組名寫成 flpydisk。這個擴充指令放在 Ext.dll,官方頁面標示適用於 Windows XP 以後的版本。
| 參數 | 作用 | 什麼時候用 |
|---|---|---|
-d | 掃描時列出每一段差異的摘要 | 想知道差異在哪、原本與現在的位元組 |
-db | 以類似 db 指令的格式顯示,不同的位元組以星號標示 | 想逐位元組對照 |
-lo 行數 | 限制 -d 或 -db 的輸出行數 | 差異很多,只想先看前幾段 |
-p 路徑 | 先在指定資料夾(含子資料夾)找原始檔,找不到才去符號伺服器 | 第三方驅動、符號伺服器上沒有的檔案 |
-as | 掃描可捨棄區段以外的所有區段 | 懷疑改動落在預設略過的區段 |
-ss 名稱 | 只掃名稱含指定字串的區段(區分大小寫,最多 8 字元) | 只想看特定區段 |
-r 起點 終點 | 只掃指定位址範圍 | 只想確認某個函式附近 |
-nospec | 連 Hal.dll 與 Ntoskrnl.exe 的保留區段一起檢查 | 要把 nt 與 hal 查到最徹底 |
-noplock | 把 0x90 與 0xF0 的差異也列出來 | 想看到這類互換造成的差異時 |
-f | 把原始檔內容覆寫回記憶體中的映像 | 只在傾印檔副本上用,讓反組譯看到原本的指令 |
-mmw 檔案 選項 | 把每一筆差異寫成逗號分隔的記錄檔 | 要留存結果或交給他人比對 |
- 看總數用
!chkimg 模組名,看位置用-d,看位元組用-db,這三種用法涵蓋大部分情境。 -as、-nospec會擴大掃描範圍,也會把本來就會變動的區域帶進來,判讀時要回頭和預設結果對照。- 找不到原始檔時先用
-p指定資料夾,不要急著下結論。 -f會改寫記憶體中的映像,官方提醒即時偵錯時可以先建立傾印檔再執行;本文只在傾印檔副本上使用。- 其餘
-nar、-np、-v等參數用途較少,細節請看官方參考頁。
🛠️ 實戰步驟
⚠️ 執行前先確認:本文的分析步驟只讀取傾印檔,不會改動出問題的電腦;唯一例外是只有小型傾印檔時,步驟一需要變更傾印類型設定。請先把傾印檔複製一份,之後都在副本上操作。
-f參數會改寫記憶體中的映像,連線到正在執行的電腦做即時核心偵錯時,官方提醒可以先建立傾印檔再執行;正式環境請不要這樣做。
遇到下面任何一種情況就先停手,不要繼續往下做。
- 分不出手上的檔案是小型傾印檔還是核心記憶體傾印
- 設好符號路徑後,
!analyze -v仍大量出現找不到符號的錯誤 - 傾印檔來自公司或學校管控的設備,尚未取得 IT 同意就要帶出或轉交(核心記憶體傾印包含當機當下核心使用中的記憶體)
- 指令輸出和本文描述明顯對不上,又找不出原因
- 準備對正在執行的正式環境電腦使用
-f
步驟一:確認傾印檔類型,小型傾印檔換成核心記憶體傾印
要完整比對整個模組,請搭配核心記憶體傾印或完整記憶體傾印。依微軟文件,小型傾印檔(Small Memory Dump)包含停止碼與參數、當機執行緒的堆疊、已載入的驅動清單,以及 Windows 判斷對除錯有用的額外記憶體頁,但不含任何執行檔映像;偵錯器分析這種檔案時,要另外找到執行檔、把映像檔對應進來(微軟稱為 mapped image)。從原始檔補進來的程式碼,和原始檔比不出差異;能比出差異的只有傾印檔本身收錄的記憶體頁,所以比對範圍很有限,這也符合官方「這種比對在完整傾印檔上最有效」的說法。
看檔案放在哪裡,就能大致分辨類型。
%SystemRoot%\Minidump資料夾裡的是小型傾印檔,檔名含當機日期,例如官方範例的mini022900-01.dmp%SystemRoot%\Memory.dmp是核心記憶體傾印與自動記憶體傾印的預設檔名,兩者內容相同;核心記憶體傾印包含核心、HAL 與核心模式驅動使用中的記憶體
手上只有小型傾印檔時,先依當機藍屏一閃就重開?先關自動重新啟動、設好記憶體傾印再抓兇手把傾印類型改成核心記憶體傾印或自動記憶體傾印,等下次當機再分析。拿到 Memory.dmp 後立刻用系統管理員帳戶複製到工作資料夾:依官方說明,再次當機產生新的核心記憶體傾印時,舊檔會被覆寫。
步驟二:設定符號路徑,讓 WinDbg 取回同版本原始檔
用 WinDbg 開啟傾印檔副本後,在指令列輸入下面兩行。
.symfix C:\Symbols
.reload.symfix 把微軟公用符號伺服器設為符號路徑,C:\Symbols 是本機快取資料夾;省略這個參數時,會改用 WinDbg 安裝目錄下的 sym 子資料夾。.reload 讓偵錯器更新模組清單並清除舊的符號資訊,符號會在實際用到時才載入。輸入 .sympath 可以確認目前的完整路徑。
!chkimg 取原始檔也靠這條路徑。微軟文件說明,公用符號伺服器除了符號,也提供部分二進位碼與執行檔,所以 nt、hal 這類微軟模組通常能直接取回。符號路徑的完整設定與常見錯誤,可以參考 WinDbg Preview 安裝與符號路徑設定完整教學。
步驟三:從 !analyze -v 找出該查哪個模組
!analyze -v先找報告裡有沒有 CHKIMG_EXTENSION 這一行。在微軟的範例中,!analyze 判斷為 Probably caused by : memory_corruption,並附上 CHKIMG_EXTENSION: !chkimg !win32k,指出 win32k 可能是損毀的模組。官方也提醒,即使報告沒有這一行,仍可考慮堆疊最上方的模組是否損毀。
步驟四:對可疑模組執行 !chkimg,再展開差異細節
先不加參數跑一次,看總共有幾個位元組不同。下面沿用步驟三官方範例中的 win32k,實際操作時換成步驟三找到的模組名(核心本身的模組名是 nt)。
!chkimg win32k官方範例得到 Number of different bytes for win32k: 31,代表 win32k 有 31 個位元組和原始檔不同。數字是 0 也別急著結案,原因見後面「讀懂 !chkimg 比對輸出」一節。
接著加上 -d,列出每一段差異的位置。
!chkimg -d win32k官方範例的 -d 輸出,每段差異占兩行。
bf920e40-bf920e46 7 bytes - win32k!HFDBASIS32::vSteadyState+1f
[ 78 08 d3 78 0c c2 04:00 00 00 00 00 01 00 ]
bf920e48-bf920e5f 24 bytes - win32k!HFDBASIS32::vHalveStepSize (+0x08)
[ 8b 51 0c 8b 41 08 56 8b:00 00 00 00 00 00 00 00 ]- 第一行:差異範圍的起點與終點、長度、對應的符號與位移;括號裡的
+0x08是和上一段差異相隔的位元組數 - 第二行:冒號左邊是原始檔的預期值,右邊是映像中的實際值;範圍超過 8 個位元組時,兩邊都只顯示前 8 個
想逐位元組比對時改用 -db,不同的位元組會以星號標示;差異很多時可加 -lo 40,只顯示前 40 行。要檢查的第三方驅動在符號伺服器上找不到時,先用 lmvm 模組名 查出記憶體中模組的時間戳記與版本資訊(相關標頭缺失或被分頁出去時,lmvm 不會顯示這些資訊;查不到時,改從原機上的檔案或向廠商確認版本),再從可信來源取得同一版本的原始檔放進一個資料夾,用 -p 指向它,例如 !chkimg -p C:\DriverOriginals -d 模組名。
步驟五:反組譯差異位址,追出改動來源
!chkimg 只說哪裡不一樣,要知道改動從哪裡來,得看被改成了什麼。用 u 反組譯差異的起點,看到的是記憶體中目前的指令;下面是官方範例的寫法,實際操作時換成你在 -d 輸出中看到的差異起點。
u win32k!HFDBASIS32::vHalveStepSize反組譯的結果決定下一步往哪裡查。
- 反組譯出跳轉或呼叫,目標位址落在別的模組:官方提到有些驅動會用 hook、重新導向改動核心。把目標位址交給
lm a 位址,WinDbg 只會列出包含這個位址的模組,它就是頭號嫌疑人。 - 一整段變成無意義的指令:官方範例中,原本的程式碼被 00 覆蓋,反組譯出一連串
add [eax],al,官方把這個例子歸為記憶體損毀。
想看被改之前的指令,可以在傾印檔副本上執行 !chkimg -f win32k,把原始檔內容覆寫回偵錯器看到的映像,再用 u 反組譯一次,就能和改動後的內容對照。官方範例用 -f 修正後,同一個位址反組譯出的就是原本的 mov、push、sar 等指令。
微軟在 0x109 的疑難排解建議中寫到,停止碼訊息若指出某個驅動,可以停用該驅動,或向製造商確認有沒有驅動更新。用 !chkimg 找到的嫌疑驅動,建議先把比對結果交給廠商或 IT 確認要更新還是停用;本文不示範停用驅動。
步驟六:驗證結果,排除假警報再下結論
差異數字要配合參照檔版本、區段類型與分布情形一起看,才能判斷是竄改、損毀還是誤判。
- 參照檔是不是同一版本:用
lmvm 模組名查看記憶體中模組的時間戳記與版本資訊;用了-p時,確認你提供的檔案是同一版本。版本不同,差異再多也沒有判讀價值。 - 差異落在哪一類區段:加了
-as或-nospec才冒出來的差異,可能來自執行期間本來就會寫入的區段,或 Hal.dll、Ntoskrnl.exe 載入時本來就會改變的位址,要和預設參數的結果對照。 - 差異集中還是分散:集中在單一模組、反組譯出指向其他模組的跳轉,較符合官方所說的驅動改動;若零散出現在多個不相干的模組、又看不出有意義的指令,就要把硬體一併考慮。0x109 的官方說明把硬體損毀列為成因之一,
!chkimg文件也建議用 Windows 記憶體診斷工具測試實體記憶體。
三項都確認過,再把結論和 !analyze -v 的停止碼說明對照;兩邊指向同一個模組時,判斷才算站得住。
🔎 讀懂 !chkimg 比對輸出:竄改、損毀還是誤判?
同樣是「位元組不同」,成因不同,下一步也完全不同;先對照下表判斷屬於哪一種。
| 你看到的結果 | 可能代表 | 下一步 |
|---|---|---|
| 0 個差異 | 預設範圍內一致 | 必要時加 -as 再跑 |
| 跳往其他模組的指令 | 可能有驅動 hook 或重新導向 | 用 lm a 查目標所屬模組 |
| 整段變成無意義內容 | 官方範例歸為記憶體損毀 | 測試實體記憶體 |
-p 比對後差異遍布整個模組 | 參照檔很可能版本不同 | 用 lmvm 對時間戳記 |
| 找不到原始檔、無法比對 | 符號路徑未設好或檔案不在伺服器上 | 重做符號設定,或改用 -p |
- 差異數字只是起點,判讀要靠反組譯結果與參照檔版本。
- 預設範圍一致,只代表被掃描的程式碼區段沒被改;可寫入區段預設不在範圍內,IAT 則是官方列出的不檢查範圍。
- 差異大量又遍布整個模組時,先懷疑參照檔版本,再懷疑竄改。
- 0x90(nop)與 0xF0(lock)互換的位元組預設視為相符;官方以 x86 為例說明由來:符號伺服器上同一份檔案可能同時對應單處理器與多處理器版本,多處理器版的 lock 指令在單處理器版是 nop。
🔬 底層機制:!chkimg 比的到底是哪兩份資料?
一邊是記憶體中的映像,另一邊是符號伺服器上同版本的原始檔。微軟的定義是:Windows 執行 .exe、.dll 或 .sys 之前,會先把檔案載入記憶體,記憶體中的這份副本稱為執行檔映像(image)。!chkimg 拿映像逐位元組對照原始檔,兩邊的程式碼不同,可能是載入之後有東西改動過它、那段記憶體本身出了問題,也可能是磁碟上的檔案在載入前就不是原版,或參照檔版本不符造成誤判。
Windows 自己也會抓核心被改。0x109 CRITICAL_STRUCTURE_CORRUPTION 的官方說明寫到,從 Windows Server 2003 SP1 起的 x64 版 Windows,除了微軟授權的熱修補(hot patch),不允許修補核心;偵測到關鍵核心程式碼或資料被改,就會以這個停止碼當機。官方列出三個成因:驅動有意或無意改動關鍵核心程式碼或資料、在開機時未連線的核心偵錯器設了一般中斷點,以及硬體損毀(例如存放核心程式碼的記憶體故障)。停止碼的 Parameter 4 會標示毀損區域的類型;改動落在模組映像的程式碼區段時,!chkimg 能事後把改在哪、改成什麼攤開來看,資料結構類的毀損則不在它的比對範圍內。
預設略過的範圍,有一部分是官方明講「本來就會變」的地方。Hal.dll 與 Ntoskrnl.exe 的特定位址在載入時就會改變,所以預設不檢查;0x90 與 0xF0 互換的位元組也預設視為相符(官方以 x86 的 lock 與 nop 說明由來)。至於原始檔怎麼找,SymStore 以映像的時間戳記與大小存放執行檔,偵錯器用這兩個值就能向符號伺服器取回同一版本;檔案不在符號伺服器上,就只能用 -p 自己提供。
🔙 萬一翻車:回退步驟
本文的分析操作大多只讀取傾印檔;會寫入的有三處:-f 改寫映像、-mmw 寫出記錄檔(選項含 o 時會覆寫同名舊檔),以及步驟一變更傾印類型設定。
情境一:比對結果不合理,差異多到看不懂
回到步驟二,用 .sympath 確認路徑裡有微軟符號伺服器,再執行一次 .reload。用了 -p 的話,用 lmvm 模組名 對照時間戳記,把參照檔換成同一版本後重跑。
情境二:在傾印檔上用了 -f,想回到原始內容
結束目前的偵錯工作階段,重新開啟事先保留的傾印檔原始副本,就能回到比對前的狀態。
情境三:即時核心偵錯時誤用了 -f(最壞情況)
-f 是把原始檔內容覆寫到記憶體中的映像;依微軟對映像的定義,被改寫的是記憶體中的副本,磁碟上的檔案不受影響。這時目標電腦的核心記憶體已被改寫,不要再把它當正式環境使用,讓它重新開機,驅動就會從磁碟重新載入。之後若還要在即時偵錯中使用 -f,依官方提醒先用 .dump /f 檔案路徑 建立完整記憶體傾印;即時核心偵錯時,這個指令會讓目標電腦產生傾印檔,但不會當機。
💡 總結:進階玩法與底層邏輯
!chkimg 回答的是「核心或驅動的程式碼有沒有被改、改成什麼」,最適合在拿到核心記憶體傾印之後使用。熟悉單一模組的流程後,還可以往兩個方向延伸。
- 一次檢查所有已載入模組:官方範例寫法是
!for_each_module !chkimg @#ModuleName,@#ModuleName會依序代入每個模組的名稱。 - 把差異存成記錄檔:例如
!chkimg -mmw C:\Temp\chkimg_nt.csv rSewo nt,每行一筆差異,欄位依序是相對位址、區段名稱、預期值與實際值,o代表覆寫同名舊檔;記錄檔建議寫完整路徑(相對路徑會以目前路徑為準),最多可同時建立 10 個。
和 Driver Verifier 是前後接棒的關係。Driver Verifier 在系統執行時即時監控核心模式驅動,抓出非法的函式呼叫與可能破壞系統的動作;官方警告它可能讓電腦當機,只該在測試或除錯用的電腦上執行。!chkimg 則是在傾印檔上事後比對,不需要讓系統冒險。比較穩的做法是先用 !chkimg 找出被改的位置與嫌疑驅動,若還要在執行期抓到違規動作,再依 Driver Verifier 完整使用教學在測試環境重現。
不適用的情況也要先知道。只有小型傾印檔、又等不到下一次當機時,!chkimg 能比對的內容很有限,0 個差異沒有參考價值。
本文依 Microsoft Learn 的 !chkimg 參考頁(頁面標示最後更新 2023-10-25)與 WinDbg、傾印檔、符號伺服器相關文件整理,2026-09-26 查證。
❓ 常見問題
Q:!chkimg 跟 Driver Verifier 差在哪?
兩者時機與做法不同。Driver Verifier 在系統執行時即時監控驅動,發現違規就觸發藍屏(通常是 0xC4),官方建議只在測試電腦上使用;!chkimg 在偵錯器裡事後比對傾印檔中的映像與原始檔,分析傾印檔時不會改動任何電腦。手上已有核心記憶體傾印時,先用 !chkimg;需要重現問題、抓到執行期的違規動作時,再用 Driver Verifier。
Q:怎麼知道驅動檔案是不是被改過?
!chkimg 檢查的是記憶體中的映像。懷疑磁碟上的 .sys 檔本身有問題時,從可信來源(例如廠商官方安裝包)取得同版本的檔案,用 -p 指定給 !chkimg 比對;程式碼區段出現差異,就代表記憶體中執行的程式碼和可信原檔不同,不論改動發生在磁碟上還是載入之後。
Q:!chkimg 是拿符號檔(PDB)比對嗎?
比對對象是執行檔本身。官方寫明 !chkimg 比對的是記憶體中的映像與符號庫上的檔案副本,微軟公用符號伺服器除了符號也提供執行檔;符號的作用是把差異位址換算成「函式名+位移」,讓輸出看得懂。
Q:跑出 0 個差異,就代表沒被竄改嗎?
不一定。預設掃描會略過可寫入、不可執行、名稱含 PAGE 與可捨棄的區段,IAT 也不在檢查範圍內;分析的若是小型傾印檔,結果更沒有參考價值。需要更完整的檢查時,改用核心記憶體傾印並加上 -as 重跑。
Q:可以用 !chkimg -f 把電腦修好嗎?
不行。-f 只把原始檔內容覆寫回記憶體中的映像:在傾印檔上改的是偵錯器看到的內容,在即時偵錯中改的是目標電腦的記憶體,磁碟上的檔案都不會變。改動核心的驅動或故障的硬體仍在,重新開機後問題可能再出現,根本解法是找出來源並處理。
Q:這個方法在舊版本也適用嗎?
!chkimg 官方標示適用於 Windows XP 以後的版本。分析用的電腦若低於 Windows 10 1607,不在目前 WinDbg 的支援清單內,改用 Debugging Tools for Windows 裡的 WinDbg (classic);傾印檔來源的 Windows 版本則不必和分析用的電腦相同。
🔗 延伸閱讀
- WinDbg lmvm 教學:一行指令看懂當機驅動模組與版本資訊
- WinDbg !analyze -v 完整教學:逐欄位讀懂當機分析報告,搞懂 STACK_TEXT 與 FAILURE_BUCKET_ID
- CRITICAL_STRUCTURE_CORRUPTION 0x109 藍屏怎麼修?讀懂 PatchGuard 與 Parameter 4,揪出偷改核心的兇手
- LiveKd 教學:不必真的當機,用 WinDbg 分析正在執行中的 Windows 核心
📎 參考資料來源
📖 第一級|廠商官方:
- !chkimg(Microsoft Learn) — 2026-09-26 查證
- !for_each_module(Microsoft Learn) — 2026-09-26 查證
- lm (List Loaded Modules)(Microsoft Learn) — 2026-09-26 查證
- u, ub, uu (Unassemble)(Microsoft Learn) — 2026-09-26 查證
- .reload (Reload Module)(Microsoft Learn) — 2026-09-26 查證
- .dump (Create Dump File)(Microsoft Learn) — 2026-09-26 查證
- Small Memory Dump(Microsoft Learn) — 2026-09-26 查證
- Kernel Memory Dump(Microsoft Learn) — 2026-09-26 查證
- Automatic Memory Dump(Microsoft Learn) — 2026-09-26 查證
- Setting Symbol and Executable Image Paths in WinDbg(Microsoft Learn) — 2026-09-26 查證
- Microsoft Public Symbol Server for Windows Debuggers(Microsoft Learn) — 2026-09-26 查證
- Using SymStore(Microsoft Learn) — 2026-09-26 查證
- Bug Check 0x109 CRITICAL_STRUCTURE_CORRUPTION(Microsoft Learn) — 2026-09-26 查證
- How to Use Driver Verifier for Driver Testing(Microsoft Learn) — 2026-09-26 查證
- Install WinDbg(Microsoft Learn) — 2026-09-26 查證
- Analyze a Kernel-Mode Dump File by Using WinDbg(Microsoft Learn) — 2026-09-26 查證
⚠️ 本文核心事實以第一級為準。
📅 本文查證戳記:2026-09-26 依據 Microsoft Learn 之 !chkimg 參考頁與 WinDbg、傾印檔、符號伺服器相關文件查證撰寫,內容整理自官方文件,未在實機上執行。
若你在後續版本遇到步驟失效,歡迎在留言區回報。