2026 年 Windows 藍框當機（BSOD）排查：錯誤代碼解讀與 Dump 分析
1-3 BSOD 的三種成因分類
所有藍屏，追根究柢可以分成三大類。分清楚類型，你才知道要往哪個方向查：
WHEA_UNCORRECTABLE_ERROR、MACHINE_CHECK_EXCEPTION、MEMORY_MANAGEMENT 等代碼。CRITICAL_PROCESS_DIED、INACCESSIBLE_BOOT_DEVICE。二、事前準備：讓下一次藍屏「有跡可循」
最怕的情況是：藍屏來了、重開了，但你手上什麼證據都沒有，只能憑感覺亂猜。這一節要做的，就是在下一次當機之前，先把「蒐證機制」架好。
2-1 設定記憶體傾印（Memory Dump）選項
Windows 預設只會寫入「小記憶體傾印」（約 256 KB～1 MB），資訊量偏少。建議手動調整：
Win + R 輸入 sysdm.cpl。切到「進階」分頁，點「啟動及修復」中的「設定」。
確認「傾印檔案」路徑為 %SystemRoot%\MEMORY.DMP。
取消勾選「自動重新啟動」，這樣藍屏畫面會停住，讓你有時間拍照記錄代碼與參數。
如果你有充足的磁碟空間，且想連使用者模式的資料一起保留，可以選擇「完整記憶體傾印」，代價是檔案可能與你的實體記憶體一樣大（32 GB 記憶體就會產生約 32 GB 的檔案）。一般排查用「自動記憶體傾印」已經非常足夠。
2-2 關閉「快速啟動」與「自動重新啟動」
「快速啟動」（Fast Startup）是混合式休眠，會讓驅動程式的初始化狀態被保存下來，某些驅動在這種狀態下特別容易出錯，也會讓「關機再開機」與「重新啟動」的行為不一致，增加排查難度。關閉方式：控制台 → 電源選項 → 選擇按下電源按鈕時的行為 → 變更目前無法使用的設定 → 取消勾選「開啟快速啟動」。
另外，如果你的電腦會在藍屏後直接重開、根本來不及看代碼，務必確認系統內容中的「自動重新啟動」已取消勾選。
2-3 事件檢視器與可靠性監視器：被忽略的免費線索庫
即使沒有 Dump 檔案，系統日誌也留下了大量線索。打開「事件檢視器」（eventvwr.msc），重點看這幾個位置：
41（Kernel-Power，代表非正常關機）、1001（BugCheck，會直接寫出錯誤代碼與參數）。2-4 備份、還原點與安全模式：排查前的保命符
在開始任何修復動作之前，請先做三件事：建立系統還原點、備份重要資料、確認你能進入安全模式（開機時按住 Shift 再選重新啟動，或連續中斷開機三次觸發修復環境）。特別是之後若要用 Driver Verifier 這類會強制讓系統變得不穩定的工具，沒有還原點等於在走鋼索。
三、錯誤代碼解讀：常見 BugCheck Code 與參數含義
藍屏畫面上那串看起來像天書的代碼，其實是微軟定義好的「BugCheck 代碼」。讀懂它，你就已經完成一半的診斷。
3-1 BugCheck 代碼的閱讀方式
傳統格式長這樣：
STOP: 0x0000000A (0x0000000000000008, 0x0000000000000002, 0x0000000000000000, 0xFFFFF80012345678)
其中 0x0000000A 是主要的 BugCheck 代碼（十六進位），後面的四個數字是「參數」，每個代碼的參數意義都不一樣。在 2026 年的 Windows 上，藍屏畫面通常還會附上一行失敗的模組名稱，例如 What failed: nvlddmkm.sys，這行資訊價值極高，幾乎等於直接點名。請務必先拍照或抄下這行。
3-2 常見 BugCheck 代碼總覽表
代碼（十六進位）
名稱
主要嫌疑
3-3 逐一解讀：最常見的八個代碼
0x0000000A / 0x000000D1（IRQL 系列）：這兩個是經典中的經典。參數一通常是被存取的位址，參數二與三是 IRQL 與讀寫型別，參數四則是執行該次存取的指令位址。在 WinDbg 中用 !analyze -v 搭配 lmvm 查出該位址屬於哪個模組，就能知道是哪個驅動惹的禍。實務上，網路卡驅動、無線網卡驅動、VPN 軟體與舊式防毒的過濾驅動是最大宗。
0x0000001A（MEMORY_MANAGEMENT）：記憶體管理員發現頁面表格或 PFN 資料庫不一致。這幾乎可以分成兩種情境：一是實體記憶體真的壞了，二是驅動程式偷偷改寫了不該動的記憶體。建議先跑 MemTest86 至少四輪完整測試，並關閉 XMP／EXPO 超頻設定再測一次。
0x0000003B（SYSTEM_SERVICE_EXCEPTION）：系統服務或驅動在執行時拋出例外。這個代碼的參數一會是例外代碼，例如 0xC0000005 代表存取違規。它非常常見於「防毒軟體 + Windows Update + 第三方驅動」三者衝突的場景。通常 Dump 會直接指出某個 .sys，例如 WdFilter.sys、eamonm.sys 等。
0x00000050（PAGE_FAULT_IN_NONPAGED_AREA）：系統試圖讀取一段「理論上一定在實體記憶體裡」的資料卻失敗。這個代碼對記憶體故障的指向性很強，但也不能忽略驅動撰寫錯誤的可能。若你最近加裝了記憶體、開啟了 XMP，請先關閉超頻再觀察。
0x000000EF（CRITICAL_PROCESS_DIED）：像是 csrss.exe、wininit.exe、services.exe 這類關鍵程序掛掉。通常是系統檔案損毀、磁碟讀寫錯誤，或某個惡意／劣質軟體強制終止了系統程序。請先執行 sfc /scannow 與 DISM /Online /Cleanup-Image /RestoreHealth，並檢查硬碟健康度。
0x00000133（DPC_WATCHDOG_VIOLATION）：系統要求某個延遲程序呼叫（DPC）在時限內完成，但它超時了。常見原因是儲存驅動（尤其是 NVMe 控制器驅動）、SSD 韌體過舊、或某些外接裝置反覆觸發中斷。2026 年不少案例來自特定型號 NVMe SSD 的電源管理瑕疵，更新韌體即可解決。
0x00000124（WHEA_UNCORRECTABLE_ERROR）：這是硬體等級的錯誤。WHEA 是 Windows 的硬體錯誤架構，它偵測到 CPU 快取、記憶體匯流排、PCIe 通道等發生不可修正的訊號錯誤時就會拋出此代碼。參數一通常指出錯誤來源（例如 0x1 為記憶體子系統、0x0 為 CPU 內部錯誤），參數二與三會指向處理器編號與相關位址。看到這個代碼，請優先懷疑硬體：關閉超頻、降頻測試、檢查散熱、確認電源供應器是否老化，並可查看 C:\Windows\LiveKernelReports\WHEA 目錄下的報告。
0x00000116（VIDEO_TDR_FAILURE）：TDR 是「逾時偵測與復原」機制，當 GPU 在 2 秒內沒有回應，驅動會被重啟；若重啟失敗，就演變成藍屏。原因可能是顯示卡驅動、GPU 過熱、供電不足、顯示卡本身老化，或瀏覽器與遊戲的硬體加速衝突。建議使用 DDU 徹底移除驅動後，重新安裝乾淨版本。
3-4 參數（Arguments）比代碼本身更重要
同一組 BugCheck 代碼，搭配不同參數，診斷方向可能完全不同。舉例來說，0x0000007E 的參數一若為 0xC0000005，代表存取違規；若為 0x80000003，則是中斷點例外，通常與驅動的除錯斷言有關。因此，拍照時一定要連參數一起拍下來，只記代碼是不夠的。
四、Dump 分析實戰：用 WinDbg 抓出元兇
有了 Dump 檔案，我們就可以像法醫一樣還原當機現場。這一節會帶你從零開始完成一次分析。
4-1 傾印檔案的類型與存放位置
C:\Windows\Minidump\，檔名如 030126-12345-01.dmp。體積小、數量多，適合快速比對。C:\Windows\MEMORY.DMP，包含核心模式記憶體，資訊完整，體積約數百 MB 至數 GB。C:\Windows\LiveKernelReports\，用於記錄那些「沒有觸發藍屏」的硬體異常，例如顯示卡 TDR、WHEA 事件，非常值得翻閱。4-2 WinDbg 安裝與符號設定
C:\Windows\Minidump 中最新的一個 .dmp。設定符號路徑：在命令列輸入
.sympath srv*C:\Symbols*https://msdl.microsoft.com/download/symbols
接著輸入 .reload /f 強制下載所有需要的符號檔。
C:\Symbols 快取目錄，之後重複利用。4-3 !analyze -v 輸出怎麼看
載入完成後，輸入最關鍵的一行指令：
!analyze -v
這個指令會輸出大量資訊，但你不必全部看懂。請依序關注以下幾個欄位：
chrome.exe 或 System。若顯示 System，代表是核心模式本身出錯。4-4 進階指令：把線索挖到最深
當 !analyze -v 給的答案模糊時，這些指令能幫你突破：
lmvm 驅動名稱：例如 lmvm nvlddmkm，可查出版本、時間戳記與檔案路徑，用來確認驅動是否過舊。kb：顯示目前執行緒的呼叫堆疊與參數。
!thread：檢視當前執行緒狀態，包含 IRQL 與等待原因。
!pool 位址：查詢某個記憶體位址屬於哪個集區（Pool），並顯示其 Pool Tag，可用來反推是哪個元件配置的。!pte 位址：檢視頁面表格項目，判斷該位址是否有效、是否被換出。
!drvobj 驅動名稱 7：列出驅動物件與其掛載的裝置物件。
!verifier：若已啟用 Driver Verifier，這裡會顯示捕獲到的違規細節。!sysinfo machineid：確認系統型號與 BIOS 版本，方便比對廠商已知問題。4-5 無法定位時：Driver Verifier 與 Pool Tag 追蹤
如果 Dump 只告訴你「記憶體被寫壞了」，卻沒指出兇手，可以啟用 Driver Verifier。它會對指定驅動施加嚴格檢查，讓原本不易重現的錯誤變成明確的藍屏。使用方式：執行 verifier，選擇「建立標準設定」，勾選「自動選取未簽署的驅動程式」或手動指定可疑驅動，重新開機後等待當機。分析完成後務必用 verifier /reset 關閉，否則系統會一直處於高負載驗證狀態。
搭配 !poolused 與 Pool Tag 查詢，有時可以找出是哪個廠商的驅動佔用了異常大量的集區，進一步縮小範圍。
4-6 輕量工具與 AI 輔助分析
不是每個人都想學 WinDbg。以下工具能提供快速結論：
!analyze -v 輸出，讓模型給出解釋。它們對「常見代碼 + 常見驅動」的判斷不錯，但遇到罕見 BugCheck 或客製化驅動時仍可能胡說八道。請把它當成翻譯機，而不是法官。五、對症下藥：依錯誤類型修復與驗證
找到嫌疑犯之後，接下來的動作才是真正解決問題的關鍵。
5-1 通用排查十步 SOP
記錄藍屏代碼、參數與失敗模組名稱。
確認最近是否有 Windows Update、驅動更新或新安裝的軟體。
sfc /scannow 與 DISM /Online /Cleanup-Image /RestoreHealth。chkdsk /f /r，並用廠商工具（如 Samsung Magician、Crucial Storage Executive）查看 SMART 數值。關閉超頻（XMP／EXPO／PBO）並以預設時脈測試。
使用 DDU 乾淨移除顯示驅動，再安裝官方穩定版。
執行 Windows 記憶體診斷，必要時用 MemTest86 做完整測試。
更新 BIOS／UEFI 與晶片組驅動。
執行 verifier 找出隱藏的問題驅動（做完記得重置）。
若以上皆無效，考慮系統還原、修復安裝，甚至乾淨重灌。
5-2 記憶體問題的確認方式
記憶體故障是最容易被忽略、也最容易被誤判為「驅動問題」的元兇。建議流程：先關閉 XMP／EXPO，用 MemTest86 跑至少四輪（每輪約 1～2 小時，視容量而定）。只要出現任何一個錯誤，就先判定硬體有問題。若只有單條記憶體出錯，可透過逐條測試找出故障模組。若你使用四條記憶體但主機板只建議兩條，請注意記憶體控制器負載，四條滿插在 2026 年的高頻 DDR5 平台上仍是常見的不穩定來源。
5-3 驅動問題的處理原則
驅動排查的黃金原則是「回退、隔離、替換」：先嘗試回退到上一個版本；若無法回退，用 DDU 或廠商移除工具徹底清除後重裝；若仍不穩，改用較舊但穩定的版本，或暫時停用該裝置觀察是否還會藍屏。對於防毒軟體，可以嘗試暫時移除而非只停用，因為過濾驅動往往在停用後仍部分載入。
5-4 系統檔案與更新的修復
若 BugCheck 指向系統檔損毀，可依序執行：DISM /Online /Cleanup-Image /CheckHealth、/ScanHealth、/RestoreHealth，再執行 sfc /scannow。若是某個累積更新後才開始藍屏，可至「設定 → Windows Update → 更新記錄」解除安裝該 KB，並使用「顯示或隱藏更新」工具暫停它。
5-5 硬體、散熱與電源的檢查
清理灰塵、確認風扇轉速、監測 CPU 與 GPU 溫度（可使用 HWiNFO64）。電源供應器若已使用五到七年，老化導致的電壓波動是 WHEA_UNCORRECTABLE_ERROR 與 CLOCK_WATCHDOG_TIMEOUT 的常見原因。此外，延長線與插座品質、電源線接觸不良，都可能造成間歇性藍屏。
5-6 三個實戰案例分享
案例一：某使用者每次玩遊戲約二十分鐘就出現 VIDEO_TDR_FAILURE。Dump 顯示 nvlddmkm.sys，但驅動已是最新。進一步檢查發現 GPU 熱點溫度達 105°C，風扇與散熱鰭片積滿灰塵。清理並更換散熱膏後問題消失。
案例二：某筆電在睡眠喚醒後經常出現 DRIVER_POWER_STATE_FAILURE。用 WinDbg 分析後，!analyze -v 指出某個 USB 音效驅動未正確回應電源請求。移除該廠商的音效管理軟體、改用 Windows 內建驅動後穩定。
案例三：某桌機隨機出現 MEMORY_MANAGEMENT 與 PAGE_FAULT_IN_NONPAGED_AREA。MemTest86 第一輪就報錯，逐一測試後確認其中一條記憶體模組故障，送修更換後再無藍屏。
六、結語與常見問答
6-1 重點回顧
藍屏排查的核心邏輯其實很單純：先蒐證，再解讀，最後對症下藥。蒐證靠的是正確的傾印設定與事件日誌；解讀靠的是 BugCheck 代碼、參數與 WinDbg 的 !analyze -v 輸出；下藥則要依照「硬體、驅動、系統檔」三大類分別處理。多數人卡住的原因，不是不會用工具，而是太急著「隨便找一個方法試試看」，反而讓問題更難重現。
最後提醒：如果你已經依照流程排查一輪仍無法解決，請把 Dump 檔案、!analyze -v 的完整輸出、以及事件檢視器中的 BugCheck 事件（識別碼 1001）整理好，再到論壇發問。附上完整資訊的求助文，往往能在幾小時內得到有價值的回覆；只寫「我電腦一直藍屏怎麼辦」的貼文，通常只能得到「重灌」兩個字。
6-2 常見問答
Q1：藍屏後我什麼都沒記錄，還救得回來嗎？
可以。請打開事件檢視器，篩選系統日誌中的事件識別碼 1001，裡面會保留 BugCheck 代碼與參數；同時 C:\Windows\Minidump 通常也會留下檔案。
Q2：Minidump 檔案很小，資訊夠用嗎？
對八成以上的驅動問題足夠，尤其能指出涉嫌的 .sys。若涉及記憶體損毀或複雜的核心錯誤，建議切換到核心記憶體傾印。
Q3：Dump 分析說「Probably caused by」某個系統檔，就是它壞了嗎？
不一定。系統檔本身出錯的機率低，更常見的是「它被其他驅動的錯誤資料害到」。請一併檢查呼叫堆疊與 Pool Tag。
Q4：Driver Verifier 會不會讓電腦開不了機？
有可能，因為它會刻意讓問題驅動當掉。請務必先建立還原點，並記住可在安全模式執行 verifier /reset 關閉。
Q5：2026 年的 Windows 有沒有自動上傳崩潰報告的功能？
有，但上傳後微軟只會用於統計與修正，不會主動回覆你個人。想取得分析結果，還是得自己動手。
Q6：重灌是不是最快的方法？
如果你的資料已備份、且時間成本高於學習成本，重灌確實能解決大部分軟體層問題。但若是硬體故障（如記憶體、電源），重灌一百次也沒用，藍屏依舊會回來。
本文由雅寶社區・頂客論壇 3C 科技教學版整理撰寫，轉載請註明出處。若你有實際的 Dump 分析需求，歡迎在論壇貼出你的 BugCheck 代碼與 !analyze -v 輸出，版上幾位熱心的偵錯老手會盡力協助你找出真兇。