WinDbg Preview 安裝與符號路徑設定完整教學:為什麼你的當機分析報告一堆問號

⚡ 站長快讀:核心重點

• 文章屬性:教學實戰(工具安裝與環境設定)
• 適用系統:Windows 11 全版本、Windows 10 1607 以上;架構限 x64 與 ARM64
• 難易度 / 耗時:⭐⭐ / 只有幾行指令,時間幾乎都花在等符號下載
• 核心結論:WinDbg Preview 符號路徑一行 .symfix 就會通;報告裡「一堆問號」不是一種病,而是四種病灶(沒符號檔 / 版本不符 / 還沒載 / 連不到伺服器)。
• 適用對象:想用 WinDbg 分析當機傾印檔,卻卡在「裝哪一個」「符號怎麼設」的人。

📌 快速答案

一句話答案:WinDbg Preview 符號路徑最快的設法是在指令列輸入 .symfix C:\Symbols 再執行 .reload,由微軟公用符號伺服器自動下載並快取符號檔;報告出現一堆問號,幾乎都是符號沒載到、載錯版本,或連不上伺服器。

🧰 開始前的準備

• 系統需求:Windows 11(所有版本)或 Windows 10 1607 以上;微軟官方頁面明列支援的處理器架構為 x64 與 ARM64,32 位元的 x86 不在支援清單內。
• 權限需求:官方安裝頁的「Requirements」段只列出作業系統與處理器架構,未載明安裝所需的權限層級,本文因此不對此做規格宣稱;若是公司或學校的受管控裝置,請先確認 IT 政策。
• 需要工具:WinDbg 官方安裝頁。三種安裝管道任選其一,下面步驟一會逐一說明差異。
• 需要網路:符號檔要從微軟公用符號伺服器下載,該伺服器的 https 連線只支援 TLS 1.2 以上——這一點在企業內網或老舊環境會直接決定你設不設得起來。
• 預計耗時:安裝與符號路徑設定都只是幾個步驟;耗時主要落在第一次 .reload 下載符號,時間長短視網路頻寬與 dump 涉及的模組數量而定,本文不給固定分鐘數(那會是沒有來源的自創數字)。
• 難度門檻:會複製貼上一行指令就能做。本文步驟不會改到系統設定,唯一會寫入的是一個使用者層級的環境變數,且附有回退方法。

🔍 為什麼你需要這個?

你大概是這樣卡住的:電腦藍屏了,查到要用 WinDbg 分析 dump 檔,結果第一關就先被名字絆倒——微軟商店裡叫「WinDbg Preview」、SDK 裡也有一個「WinDbg」,到底該裝哪個?好不容易裝好、開了 dump 檔,跑完分析卻看到滿螢幕的 nt+0x3f1234、[No function listed.],連兇手叫什麼名字都看不到。

問題不在你,在於中文圈的 WinDbg 教學絕大多數停在好幾年前的版本,而這幾年官方在三件事上都動過:名字改了、安裝管道多了、符號伺服器的連線要求也提高了。

這篇要補的就是這一段。相對於一般「複製這行貼上去就好」的教學,本文有三個具體差異:

1. 名字問題一次講清楚:微軟官方安裝頁上有一行 Note 明講,現在這個 WinDbg「先前是以 *WinDbg Preview* 之名在 Microsoft Store 發布的」,而它與 *WinDbg (classic)* 使用同一套底層引擎、支援完全相同的指令、擴充功能與工作流程。也就是說,你搜到的「WinDbg Preview 教學」內容多半還能用,但名字已經不是那個名字了。
2. .symfix 不帶參數時的快取位置,不是你以為的 C:\Symbols:官方文件明寫,省略本機符號快取位置時,會使用除錯器安裝目錄下的 sym 子目錄。大量中文教學直接寫「預設會放在 C:\Symbols」,那是自己指定之後的結果,不是預設值。
3. 「一堆問號」其實是四種完全不同的病:沒有符號檔、符號版本對不上、符號還沒載、連不上符號伺服器,官方各有各的訊號字串與縮寫代碼,處置方式也完全不同。把它們混為一談,才是排查繞遠路的主因。

🛠️ 實戰步驟

步驟一:先搞懂要裝哪一個,再開始裝

先給結論:如果你是要分析 Windows 10 / Windows 11 的當機傾印檔,裝現在這個 WinDbg 就對了,不需要去下載 SDK,也不需要找 WinDbg (classic)。

微軟官方對這三者的定位是這樣的:

值得注意的是,官方文件指出,在同時裝有 Visual Studio 與 WDK 的機器上共有六種除錯環境,而它們共用同一套除錯引擎(實作於 Dbgeng.dll),所以上表這幾個 Windows 除錯器之間,「換一個介面結果就不一樣」的事並不會發生——差別在操作體驗與周邊功能,不在分析結果。(官方同頁另有但書:Visual Studio 自帶的是它自己的除錯環境與引擎,合稱 Visual Studio 偵錯工具,不在這套共用引擎之列。)

裝法有三種,差別不只是麻煩程度,還包括之後怎麼更新:

管道一:直接下載安裝(官方安裝頁上的「Download WinDbg」按鈕)。安裝後會在背景定期檢查新版並自動更新。

管道二:Microsoft Store。同樣會自動更新,適合不想管版本的人。

管道三:Windows 套件管理員(winget)。安裝指令:

winget install Microsoft.WinDbg

⚠️ 這裡有個幾乎沒人提的差異:官方的更新說明分成兩段——直接安裝與 Microsoft Store 安裝的 WinDbg 會在背景定期檢查並自動更新;winget 安裝則要求你自行執行更新指令。更新時執行下面這行:

winget upgrade Microsoft.WinDbg

💡 為什麼要在意這個? 除錯器的版本落後,最常見的後果不是不能開檔,而是新的 bugcheck 代碼、新的擴充指令、新的傾印格式支援跟不上。如果你是 winget 派,建議把上面那行更新指令排進你自己的月度維護清單。

步驟二:用 .symfix 一行搞定符號路徑

WinDbg 開啟 dump 檔之後,在下方指令列輸入這一行:

.symfix C:\Symbols

再執行重新載入:

.reload

就這樣。要確認有沒有設對,執行 .sympath 查看目前設定,官方文件給的實際輸出長這樣:

0: kd> .symfix c:\MyCache
0: kd> .sympath
Symbol search path is: srv*
Expanded Symbol search path is: cache*c:\MyCache;SRV*https://msdl.microsoft.com/download/symbols

這段輸出值得拆開看,因為它同時揭露了兩件事:

• Symbol search path 顯示的是你設定的「原始字串」,只有短短一個 srv*。
• Expanded Symbol search path 才是展開後真正生效的路徑,包含本機快取目錄與微軟公用符號伺服器網址 https://msdl.microsoft.com/download/symbols。

很多人看到上面那行只有 srv* 就以為沒設好,其實要看的是下面那行。

另外兩個相關指令要分清楚:

• .symfix(不帶加號):取代原本的符號路徑。
• .symfix+:把微軟符號伺服器路徑附加到現有符號路徑後面。你如果有自己編譯的驅動符號檔要一起用,就該用這個。

.symfix 後面接的目錄若不存在,符號伺服器開始複製檔案時會自動建立,不必先手動建資料夾。而如果你完全省略這個參數,官方文件明寫:會使用除錯器安裝目錄底下的 sym 子目錄。這就是前面提到的第二個差異點——「預設是 C:\Symbols」是以訛傳訛。

步驟三:設定 _NT_SYMBOL_PATH,讓所有工具共用同一份符號

.symfix 是「這次除錯階段」的設定。如果你會反覆開 dump 檔,或者同時用到 KD、CDB 這類命令列除錯器,更省事的做法是設定 _NT_SYMBOL_PATH 環境變數——這是官方文件列出的五種控制符號路徑方式之一,而且是在啟動除錯器之前就生效。

官方給的字串格式是:

set _NT_SYMBOL_PATH=srv*DownstreamStore*https://msdl.microsoft.com/download/symbols

其中 DownstreamStore 要換成你本機或網路上的一個目錄,除錯器會把抓過的符號快取在那裡。官方對這個設計的說明很直白:大多數你從來沒存取過的符號,會一直留在微軟那邊,所以你的本機下游存放區(downstream store)可以維持得相對小,而且每個檔案只會下載一次。

在 Windows 上要讓它永久生效,用 PowerShell 寫入使用者層級環境變數:

[Environment]::SetEnvironmentVariable('_NT_SYMBOL_PATH','srv*C:\Symbols*https://msdl.microsoft.com/download/symbols','User')

設定完要重新開啟 WinDbg 才會讀到(環境變數在行程啟動時讀取)。

⚠️ 停止條件——符合下列任一項,先別往下做:①你不確定 C:\Symbols 這個路徑所在磁碟還有沒有空間(符號快取會持續長大);②這台是公司或學校的受管控設備,而你沒有 IT 授權去改環境變數;③你已經有一份自己維護的 _NT_SYMBOL_PATH,而你還沒把原值抄下來。第三點特別重要,回退步驟就靠它。

先備份原值再改。執行下面這行把目前的值印出來、貼進記事本存好:

[Environment]::GetEnvironmentVariable('_NT_SYMBOL_PATH','User')

還有一個容易踩的細節:官方文件說明,符號路徑是由 _NT_ALT_SYMBOL_PATH 在前、_NT_SYMBOL_PATH 接在後面組成的。也就是說,如果你曾經設過 _NT_ALT_SYMBOL_PATH(它的用途是在特殊情況下覆寫設定,例如你手上有共用符號檔的私有版本),它會排在前面先被搜尋。排查符號問題時,兩個變數都要看。另外,透過這兩個環境變數指定的無效目錄,除錯器會直接忽略——所以路徑打錯不會報錯,只會安靜地不生效。

步驟四:驗證符號真的載到了

設完不要直接開始分析,先花三十秒確認。官方在〈Verifying Symbols〉一文給的第一個動作就是列出已載入模組與符號資訊:

lml

在 WinDbg 圖形介面裡,對應的是 Debug → Modules 選單。

接著看每個模組後面的縮寫。這些縮寫是官方定義的符號狀態代碼,也是本文接下來排查的核心依據:

看到 PDB 就對了。看到 Export 或 #,問題就在下一節。

🔬 底層機制:符號路徑到底在解什麼問題?

這一段是理解後面所有排查的基礎,值得花三分鐘看完。

符號檔存的是「執行檔跑起來不需要、但除錯時很有用」的資料——變數名稱(區域與全域)、函式名稱、模組的進入點,以及符號類型、位址或暫存器等資訊。微軟出貨的 ntoskrnl.exe 屬於官方所稱「已移除除錯資訊」(stripped of debug information)的版本,裡面沒有這些完整資料,只剩匯出表(export table)這類有限的符號線索——這也正是符號狀態縮寫 Export 的由來。所以當機時堆疊上那個位址落在哪個函式裡,除錯器只能靠外部的 .pdb 檔來翻譯;沒有 .pdb,它就只能告訴你「這個位址在 nt 模組往後 0x3f1234 的地方」——這就是 nt+0x3f1234 的由來。

符號路徑是一串以分號分隔的目錄清單,例如 C:\Dir1;C:\Dir2\DirA。對清單中的每一個目錄,除錯器都會依序找三個地方(以找 DLL 的符號為例):

1. C:\Dir1\symbols\dll
2. C:\Dir1\dll
3. C:\Dir1

全部落空之後,最終還會退回目前目錄,以及目前目錄再往上接 ..\dll、..\exe 或 ..\sys(依被除錯的二進位檔類型而定)。

關鍵在於:除錯器不是找到同名檔案就用。 官方明講,符號檔帶有日期與時間戳記,除錯器一律會去找與正在除錯的二進位檔時間戳記相符的符號。所以你不必擔心它在搜尋順序中隨便抓一個錯的來用——時間戳記不符時,搜尋會繼續往下找。

但要注意這不等於「不符就一定不載」:官方的 noisy 範例裡,符號雖然被載入了,影像的時間戳記卻不相符(也就是符號是錯的);符號狀態縮寫 M 的定義也明講,兩者不符但因符號選項設定而照樣載入。這正是「明明抓到符號、函式名稱也出來了,結論卻不對」的結構性原因。

再來是延遲載入(lazy symbol loading)。 除錯器預設不會在開檔當下就把所有符號載完,而是需要時才載。當你用 .sympath 改了符號路徑,除錯器會延遲重新載入所有帶匯出符號的模組;若是已載入完整 PDB 符號的模組,則要新路徑不再包含原本載入該 PDB 的路徑時才會重新載入。這解釋了一個常見的困惑:改完路徑後畫面好像沒反應——因為它在等你真的用到。要強制載入,用 .reload 加上 /f 參數。

最後是符號伺服器的角色。srv* 開頭的路徑代表「這一段交給符號伺服器處理」,三種寫法的差別是:

• srv*:從預設符號存放區取符號,不快取在本機。
• srv*symbolstore:從指定的符號存放區取,不快取。
• srv*localcache*symbolstore:從指定存放區取,並快取到 localcache 目錄。

第三種才是你要的。這也是為什麼 .symfix C:\Symbols 展開後會變成 cache*C:\Symbols;SRV*https://... 的樣子。

🔎 報告一堆問號:四種病灶與對症處置

先講判斷順序:先看有沒有符號檔,再看版本對不對,再看是不是根本沒去載,最後才懷疑網路。順序顛倒是排查最常繞遠路的地方。

病灶一:根本沒有符號檔(最常見)

官方訊號:lml 該模組標示 Export(找不到符號檔,只好從匯出表擷取);堆疊上函式名稱變成 模組名+0x偏移 的形式;明確一點的話會直接吐出這一行:

*** ERROR: Symbols could not be loaded for glintmp.sys

官方文件給的堆疊範例非常直觀——沒有符號的那一行,後面會直接標註 [No function listed.]:

00000002 00000000 00000000 00000000 00000000 glintMP+0x1411 [No function listed.]

處置:這通常就是符號路徑沒設或設錯。先執行 .sympath 確認路徑,不對就用 .symfix 修好,再對該模組執行 .reload 模組名。

要特別說明的是:官方把這台伺服器界定為「提供 Windows 除錯符號的免費存取」,而在講核心模式除錯的需求時也寫明,你需要「你正在除錯的那個驅動的符號,以及 Windows 的公用符號」——兩者是分開講的。因此不能預期第三方驅動(顯示卡、音效卡、防毒、虛擬機工具)的 .pdb 會在上面。 第三方驅動顯示 Export,多半是這個結構性原因,而不是你設錯——這一點不釐清,很多人會在這裡反覆重設符號路徑好幾輪。

病灶二:有符號,但版本對不上

官方訊號:lml 標示 #(時間戳記或總和檢查碼不符)或 M(不符但因選項設定仍載入);訊息列出現:

*** WARNING: symbols checksum and timestamp is wrong 0x0036a4ea 0x00361a83 for ntkrnlmp.exe

官方對這行訊息的解釋沒有任何模糊空間——它的意思就是你的符號是錯的。

這種狀況最危險,因為除錯器還是會給你函式名稱,只是名字對不上實際的程式碼,於是你會拿到一份看起來很專業、但指錯人的堆疊。官方文件裡有一組很經典的對照:同一次當機,載到錯的符號時堆疊看起來像是 win32k.sys 在畫矩形時出事;換成正確符號之後,win32k.sys 的矩形錯誤完全消失,官方明確指出真正的問題出在 AGP440.sys。

官方列出這類問題最常見的三個成因:①指向了錯誤組建版本的符號;②使用了私自編譯的二進位檔卻沒有對應的符號;③在多處理器機器上用了單處理器版本的 HAL 與核心符號。

處置:先用 vertarget 確認目標機器的 Windows 組建版本,再確認你的符號來源與它相符;走公用符號伺服器的話,直接 .reload /f 讓它照時間戳記重抓即可。

病灶三:只是還沒載(這不是錯誤)

官方訊號:lml 標示 deferred。

如同前一節所說,這代表模組已載入、但除錯器還沒去碰它的符號,需要時才會載。這是預設行為,不是故障。

處置:如果你就是現在想看,執行 .reload 加 /f 強制載入。另外 X *! 可以列出目前已載入符號的模組,拿來確認很方便。

病灶四:連不到符號伺服器

官方訊號:.symfix 設定看起來正確、.sympath 展開後也含符號伺服器網址,但符號就是抓不下來。

這裡要先把一個常被誤用的細節講清楚:官方〈Verifying Symbols〉確實列了 0xB ERROR_BAD_FORMAT、0x3 ERROR_PATH_NOT_FOUND、0x35 ERROR_BAD_NETPATH 三個錯誤碼,但那是.dbg 符號檔的載入錯誤碼(取自 winerror.h),而同一頁也明寫 Windows XP 及後續版本的 Windows 已不使用任何 .dbg 符號檔。所以在 Windows 10 / 11 的情境下,你幾乎不會看到它們——把這三個碼當成「連不上符號伺服器」的判準是搞錯對象。

這一節真正該記住的官方規格只有一條:微軟公用符號伺服器的 https 連線只支援 TLS 1.2 以上。老舊環境、被鎖版本的企業代理伺服器、或刻意停用新版 TLS 的網路,都會在這裡卡死,而症狀看起來就只是「符號載不下來」,很難聯想到 TLS。官方在該頁的疑難排解段給的建議也正是同一句:確認你的網路支援 TLS 1.2 以上,並檢查防火牆設定。

處置:先開詳細模式看它到底在做什麼——執行 !sym noisy,再 .reload 一次目標模組。開了之後,除錯器會逐行印出它去哪些路徑找了哪些檔案、找到沒有、時間戳記合不合,官方文件裡的範例輸出把 FindExecutableImageEx、FindDebugInfoFileEx、LocatePDB 的搜尋過程整條攤開來,是排查符號問題最有力的工具。確認連線面沒問題之後,再回頭檢查 TLS 與防火牆。另外,若你的符號是放在網路上另一台機器、而載入時出現 ERROR_BAD_FORMAT 或 ERROR_BAD_NETPATH,官方的建議是把符號檔複製到本機,再把本機路徑加進符號路徑重試。

⚠️ 五個會讓你白忙一場的設定錯誤

這五條全部出自官方文件,但散落在不同頁面,實務上踩到的人不少。

1. 做核心除錯時,不要把本機的 %WINDIR% 放進符號路徑。 官方在〈Verifying Symbols〉裡直接列出這一條。原因不難想:你本機的 Windows 版本跟被除錯的目標很可能不同,一旦讓它先撈到本機檔案,就直接掉進病灶二。
2. 不要把「手動放符號的目錄」拿來當符號伺服器的快取目錄。 官方明確建議分成兩個目錄——例如手動符號放 C:\MyRegularSymbols,伺服器快取用 C:\MyServerSymbols。混用會讓你分不清哪些檔案是自己放的、哪些是抓下來的,清理時很容易誤刪。
3. 同名的 .dll 與 .sys 會讓除錯器混淆。 官方點名這個情況(例如 mga64.sys 與 mga64.dll),解法是把它們分放到符號樹中正確的目錄。
4. 環境變數路徑打錯不會有錯誤訊息。 前面提過:透過 _NT_SYMBOL_PATH 加入的無效目錄會被除錯器直接忽略。所以設完務必用 .sympath 回頭確認展開後的路徑。
5. 符號快取會無限長大。 官方提供 AgeStore 工具,可以刪掉早於指定日期的快取檔,或刪到快取總量低於指定大小為止。下游存放區變得太大時就該跑它,而不是整個資料夾砍掉重來。

🔙 萬一翻車:回退步驟

本文唯一會留下痕跡的動作是步驟三的環境變數。

情境一:設完之後 WinDbg 反而抓不到符號

先不要動環境變數,回到 WinDbg 裡執行 .symfix C:\Symbols 再 .reload——工作階段內的設定會蓋過環境變數,可以先確認是變數的問題還是別的問題。

情境二:要把 _NT_SYMBOL_PATH 改回原狀

用步驟三備份下來的原值寫回去(把 原本的值 換成你抄下來的字串):

[Environment]::SetEnvironmentVariable('_NT_SYMBOL_PATH','原本的值','User')

如果原本根本沒有這個變數(備份時印出來是空白),就把它移除,做法是設成空值:

[Environment]::SetEnvironmentVariable('_NT_SYMBOL_PATH',$null,'User')

改完一樣要重開 WinDbg 才會生效。

情境三:符號快取佔掉太多空間

用官方的 AgeStore 工具依日期或依總量清理,不要直接刪整個資料夾——直接刪掉的話,下次分析等於全部重抓。

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

站長我把這篇的重點壓成三句話:裝現在這個 WinDbg 就對了、符號路徑一行 .symfix 就會通、看到問號先跑 lml 看縮寫再決定怎麼修。

必須誠實說明的是,本文屬於官方文件交叉查證的整理,不是實測數據報告——所有指令語法、參數行為、錯誤字串與縮寫定義,都逐項對回 Microsoft Learn 的原文,可驗證的具體錨點包括:符號路徑文件的 2025-11-04 版、公用符號伺服器文件的 2025-11-05 版、安裝頁的 2025-04-04 版,以及其中三個硬性數字——Windows 10 最低支援版本 1607、支援架構僅 x64 與 ARM64、公用符號伺服器僅支援 TLS 1.2 以上。這三個數字你可以直接拿去對文末的來源連結。

再往前走的兩個方向。第一,把符號設定當成分析流程的第零步。 符號沒設好時,WinDbg 藍畫面 minidump 分析教學裡教的整套動線都會失準——不是流程錯,是輸入資料就已經是壞的。第二,符號正確之後,報告才值得逐欄細讀。 這一步請接WinDbg !analyze -v 完整教學,那篇把報告拆成四段逐欄位講,包括 STACK_TEXT 怎麼切、FAILURE_BUCKET_ID 該怎麼用。如果讀完報告仍然指不出兇手,下一張牌是 Driver Verifier 完整教學,用主動壓力測試把有問題的驅動逼出來。

最後補一個判讀原則:官方在〈Verifying Symbols〉的問答段落講得很坦白——「符號不完全相符時,除錯器有時候還是能用」,例如前一個 Windows 組建的符號在某些情況下確實能正常運作,但沒有任何規則能告訴你什麼時候會成功、什麼時候不會。所以請養成習慣:每次分析之前先確認符號狀態,不要等到結論很怪了才回頭懷疑。

❓ 常見問題

Q:我到底該裝「WinDbg」還是「WinDbg Preview」?

同一個東西。微軟官方安裝頁的 Note 明講,現行的 WinDbg 先前是以 *WinDbg Preview* 之名在 Microsoft Store 發布,它與 *WinDbg (classic)* 使用相同的底層引擎,並支援完全相同的指令、擴充功能與工作流程。你在中文網頁上看到的「WinDbg Preview 教學」,操作內容多半仍然適用。

Q:.symfix 和 .sympath 差在哪?

.symfix 是懶人包,它自動幫你把符號路徑設成指向微軟公用符號存放區;.sympath 則是通用指令,可以顯示、設定、變更或附加符號路徑。日常用 .symfix 就夠,.sympath 用來檢查與做客製化設定。

Q:符號快取一定要放 C:\Symbols 嗎?

不用,任何本機或網路上的目錄都可以。要留意的是:省略不寫的時候不是預設 C:\Symbols,官方文件寫的是「使用除錯器安裝目錄底下的 sym 子目錄」。建議還是明確指定一個你管得到的路徑。

Q:為什麼有些驅動不管怎麼設都顯示 Export?

因為微軟公用符號伺服器提供的是 Windows 的公用符號,第三方廠商的私有驅動符號本來就不在上面。這種情況要跟廠商拿符號檔,或者接受用 模組名+偏移量 的形式繼續分析。

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

現行 WinDbg 支援的作業系統為 Windows 11 全版本與 Windows 10 1607 以上。要除錯更舊版本的 Windows,官方指引是改用 WinDbg (classic),它隨 Debugging Tools for Windows 提供;若要對應更早期的 Windows,則需從 Windows SDK 封存頁下載對應版本的 SDK,安裝時只勾選 Debugging Tools for Windows。至於符號路徑的語法本身(.symfix、.sympath、srv*),新舊版本是共通的。

📎 參考資料來源

📖 第一級|廠商官方:

• Install the Windows debugger(WinDbg 安裝頁) — 2026-08-09 查證
• Symbol path for Windows debuggers — 2026-08-09 查證
• Microsoft public symbol server — 2026-08-09 查證
• .symfix (Set Symbol Store Path) — 2026-08-09 查證
• Verifying Symbols — 2026-08-09 查證
• Symbol Status Abbreviations — 2026-08-09 查證
• Symbols for Windows debugging — 2026-08-09 查證
• Debugging Tools for Windows SDK and WDK — 2026-08-09 查證

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

📅 本文查證戳記:2026-08-09 依據 Microsoft Learn 官方文件撰寫,對應版本日期見上方各連結頁面標示。

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

🔗 延伸閱讀

• IRQL_NOT_LESS_OR_EQUAL 0x0A 藍屏修復|WinDbg 揪真兇
• PAGE_FAULT_IN_NONPAGED_AREA(0x50)藍屏完整解析
• KERNEL_SECURITY_CHECK_FAILURE(0x139)藍屏排錯
• MACHINE_CHECK_EXCEPTION(0x9C)藍屏排錯
• INTERRUPT_EXCEPTION_NOT_HANDLED(0x3D)藍屏排錯