快訊
2026-07-11
電腦疑難雜症

藍屏跳 SYSTEM_THREAD_EXCEPTION_NOT_HANDLED(0x7E)?先讀「What failed」揪出兇手驅動

約 11 分鐘閱讀

⚡ 站長快讀:核心重點

  • 文章屬性:疑難排除(cornerstone 深度除錯)
  • 適用系統:Windows 10 / Windows 11(含 24H2、25H2)
  • 難易度 / 耗時:中等 / 約 30–60 分鐘
  • 核心結論:SYSTEM_THREAD_EXCEPTION_NOT_HANDLED(0x7E)是系統執行緒丟出未被接住的例外,九成是驅動程式,先讀「What failed」再動手
  • 適用對象:開機或用到一半跳 0x7E 藍屏、想自己揪出兇手驅動的人

📌 快速答案

一句話答案:SYSTEM_THREAD_EXCEPTION_NOT_HANDLED(0x7E)代表某支系統執行緒丟出、卻沒被錯誤處理常式接住的例外,最常見兇手是顯示卡等驅動程式;先讀藍屏「What failed」欄位或事件檢視器鎖定模組,進安全模式回復或更新該驅動,再用 WinDbg 讀 dump 確認例外位址。

廣告

🧰 開始前的準備

  • 適用系統:Windows 10 與 Windows 11 全版本(這顆停止碼從舊版一路沿用到 24H2、25H2,官方定義沒變)
  • 權限需求:系統管理員(進安全模式、回復驅動、跑 sfc/DISM、動 Driver Verifier 都需要)
  • 需要工具:事件檢視器(內建)、WinDbg(Microsoft Store 免費)、必要時一支能開機的隨身碟做 WinRE 救援
  • 預計耗時:讀 What failed + 回復驅動約 15 分鐘;動用 WinDbg 分析 dump 約 30–60 分鐘
  • 難度門檻:會進安全模式、會開裝置管理員就能做完前兩個方法;WinDbg 那段需要看得懂停止碼參數

⚠️ 先備份再動手:如果你的電腦還進得了系統,先把重要檔案複製到外接碟。本文後段的 Driver Verifier 與 BIOS 更新屬於高風險操作,萬一設定錯誤可能開不了機,務必先看完「萬一翻車:回退步驟」再執行。


🔍 症狀描述與錯誤訊息

先給結論:看到 SYSTEM_THREAD_EXCEPTION_NOT_HANDLED,不要第一時間就想重灌或換記憶體——這顆停止碼幾乎都在「指名道姓」告訴你哪支驅動出包,重點是你有沒有把那行字讀出來。

典型症狀有三種。第一種是開機到一半就藍屏重開,甚至卡在開機循環(boot loop),常見於剛更新完顯示卡驅動或剛升級大版本(例如 23H2 升 24H2)之後。第二種是用到一半突然當機,尤其在開遊戲、跑繪圖軟體、接上某個 USB 裝置的當下。第三種是隨機發作,沒有明顯規律,這種通常跟硬體或記憶體有關,最難查。

藍屏畫面會長這樣:

你的電腦發生問題,需要重新啟動。(Your PC ran into a problem and needs to restart.)
停止代碼(Stop code):SYSTEM_THREAD_EXCEPTION_NOT_HANDLED
失敗的項目(What failed):xxxxx.sys

最關鍵的就是「What failed」那一行。Windows 10 之後的藍屏,對這顆停止碼通常會直接列出出問題的模組檔名——例如 nvlddmkm.sys(NVIDIA 顯示卡)、atikmdag.sys(AMD 顯示卡)、FLTMGR.SYS(檔案系統篩選)、某支網卡或音效卡驅動。這行字就是你的第一條線索。可惜很多人被藍屏嚇到,直接按重開,連看都沒看。


🔎 問題根因

直接講白話:0x7E 的意思是「有一條系統執行緒(system thread)在核心模式跑的時候丟出了一個例外,但沒有任何錯誤處理常式把它接住」,於是 Windows 判定情況不可收拾,主動觸發藍屏保護系統。

微軟官方對這顆停止碼的定義很明確——它本身不是根因,而是一個「有例外沒人接」的通報。真正的根因藏在「是哪一種例外、由哪支模組丟出來的」。這也是為什麼同樣一顆 0x7E,有人是換驅動就好、有人卻要更新 BIOS,因為底層丟例外的東西根本不一樣。

廣告

常見根因照發生機率排序:

  • 驅動程式問題(最常見):過舊、損毀、或與目前 Windows 版本不相容的驅動,尤其是顯示卡驅動。剛更新完驅動或剛升級大版本後才發作,九成是這類。
  • 系統檔案損毀:Windows 元件或驅動快取被改壞,sfc/DISM 常能救。
  • 硬體與韌體:記憶體不穩、BIOS/UEFI 韌體與新版 Windows 不相容、裝置 IRQ 衝突。微軟官方在疑難排解建議裡明確點名「硬體不相容、記憶體衝突、IRQ 衝突」都會產生這顆停止碼。
  • 超頻或記憶體時序:XMP/EXPO 開太猛、CPU 超頻不穩,也會讓系統執行緒踩到不該碰的記憶體。

🔬 底層機制:這個錯誤訊號從哪裡來?

這一段是這篇跟一般「跟著做就好」教學的分水嶺。你不需要會寫驅動,但知道訊號怎麼來的,你才知道每個步驟在修什麼。

在核心模式裡,系統執行緒執行的程式碼如果踩到非法操作(例如存取一塊已經被釋放的記憶體),CPU 會產生一個例外(exception)。正常情況下,寫得好的驅動會用 __try/__except 這類結構化例外處理把它接住、優雅收場。問題是:如果沒人接,這個例外會一路往上冒,最後撞到系統的預設處理器,系統只能呼叫 KeBugCheckEx 觸發藍屏,停止代碼就是 0x7E。

微軟官方文件列出 0x7E 的四個參數,這是 WinDbg 分析時最重要的線索:

參數意義
Parameter 1沒被處理的例外碼(exception code)
Parameter 2例外發生的位址(通常直接指向兇手模組)
Parameter 3exception record 的位址
Parameter 4context record 的位址

其中 Parameter 1 的例外碼 決定了問題性質,官方列出的常見值:

  • 0xC0000005(STATUS_ACCESS_VIOLATION):記憶體存取違規——最常見,通常是驅動存取了不該碰的記憶體,多半指向驅動或記憶體問題。
  • 0x80000003(STATUS_BREAKPOINT):在沒接核心偵錯器的情況下踩到硬編碼中斷點或 ASSERT,正常機器很少見。
  • 0x80000002(STATUS_DATATYPE_MISALIGNMENT):資料未對齊存取。

Parameter 2(例外位址) 是重點:官方明講,只要你打算除錯,這個位址就會指向「造成問題的驅動或函式」。這正是後面用 WinDbg 的目的——把這個位址翻譯成人看得懂的模組名。當 WinDbg 只給你「Probably caused by : ntkrnlmp.exe」這種含糊答案時,官方建議改用 !thread 搭配 dds/dps/dqs 進一步挖。

廣告

🛠️ 解決方案

依「成功率高、風險低」的順序來。大部分人做完方法一、方法二就解決了,真的不用一開始就跳到 WinDbg 或重灌。

方法一:讀 What failed,回復或更新那支驅動(成功率最高)

這是 0x7E 的標準解法,因為它最常見的根因就是驅動。

  1. 記下藍屏的「What failed」檔名。如果藍屏一閃就重開來不及看,先做好記憶體傾印設定、關掉自動重新啟動,下次藍屏就停得住——完整做法看站長這篇〈當機藍屏一閃就重開?先關自動重新啟動、設好記憶體傾印再抓兇手〉。
  2. 進安全模式。安全模式只載入最基本的驅動,能繞過出包的那支。Windows 11 路徑:設定 → 系統 → 復原 → 進階啟動 → 立即重新啟動,重開後選 疑難排解 → 進階選項 → 啟動設定 → 重新啟動,再按 4(安全模式)或 5(安全模式加網路)。若根本進不了系統,連續強制關機兩到三次,第三次會自動進入 WinRE 修復環境。
  3. 在安全模式裡處理那支驅動。開裝置管理員,找到 What failed 對應的裝置(顯示卡驅動就找「顯示卡」):
  • 如果是最近更新驅動後才壞 → 右鍵裝置 → 內容 → 「驅動程式」分頁 → 回復驅動程式(Roll Back Driver)
  • 如果是驅動太舊 → 到廠商官網(NVIDIA/AMD/Intel/主機板廠)下載最新版乾淨安裝。顯示卡建議先用 DDU 完整移除舊驅動再裝。

💡 為什麼優先動顯示卡驅動? 微軟與各大廠的除錯經驗都指向:顯示卡驅動是 0x7E 最常見的兇手,因為它跑在核心模式、又頻繁存取大量記憶體,踩雷機率最高。nvlddmkm.sysatikmdag.sys 幾乎是 0x7E 的常客。

方法二:修系統檔(sfc + DISM)

如果驅動處理完還是跳,或 What failed 指向系統元件(像 FLTMGR.SYS),多半是系統檔案損毀。以系統管理員開啟終端機或命令提示字元,依序執行(一行一個指令,不要合併):

sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth

sfc /scannow 會掃描並修復受保護的系統檔;DISM 則從 Windows Update 拉乾淨的元件映像來修復系統映像本身。兩個都跑完再重開機。

方法三:用 WinDbg 讀 dump,揪出真正的例外位址

前兩招無效、或你想一次確認兇手,就進 WinDbg。這是站長最推薦的做法,因為它是用證據辦案,而不是猜。

  1. 先確定有留下 minidump(位置在 C:\Windows\Minidump)。
  2. WinDbg 開啟該 .dmp,跑 !analyze -v
  3. 看輸出裡的 Arg1(例外碼)Arg2(例外位址),以及最下面的「Probably caused by」與 faulting module 名稱。

完整的 WinDbg 安裝、載入符號、!analyze -v 三行找兇手的步驟,站長寫過一篇專門的教學:〈WinDbg 藍畫面 minidump 分析教學:三行輸出找出真兇〉,這裡不重複。重點是把 Parameter 2 翻譯成模組名後,回到方法一去處理那支驅動。

廣告

方法四:進階與終極手段(高風險,請先看回退)

⚠️ ⭐⭐⭐ 高風險操作警語:以下步驟改動系統底層或韌體,執行錯誤可能導致無法開機。動手前務必確認已備份、有 WinRE 救援管道,並讀完下一節的回退步驟。

  • Driver Verifier 揪隱藏兇手:當 WinDbg 一直只給「ntkrnlmp.exe」這種含糊答案、抓不到真兇時,用 Driver Verifier 對第三方驅動施壓,逼有問題的那支現形。這是強力工具但會故意讓有問題的驅動更快藍屏,設定與收尾要照規矩來——完整用法與關閉方式看〈Driver Verifier 完整實戰指南〉。
  • 更新 BIOS / UEFI 韌體:如果 What failed 指向 ACPI.sys 這類與韌體高度相關的模組,或是換了新硬體後才發作,主機板廠新版 BIOS 常能解掉相容性問題。更新 BIOS 有一定風險(過程斷電可能變磚),務必用官方工具、接上不斷電。
  • 記憶體與硬體檢測:例外碼是 0xC0000005 又找不到特定驅動時,跑 Windows 記憶體診斷或 MemTest86 驗記憶體;若最近超頻或開了 XMP/EXPO,先關掉回預設值測試。

✅ 驗證修復結果

改完不要馬上宣稱「修好了」,0x7E 最擾人的地方就是它可能只是暫時沒發作。建議這樣確認:

  • 回到原本會觸發的情境:如果原本是開某個遊戲/軟體才當,就去重現那個操作,連續用幾天。
  • 看事件檢視器有沒有再冒錯誤:用事件檢視器追「系統」記錄檔的 Error 與當機前兆,確認沒有新的相關錯誤再冒出來。
  • 確認 Minidump 沒有再新增:C:\Windows\Minidump 沒有新的 dump 檔,才代表真的穩了。

🔙 萬一翻車:回退步驟

情境一:回復/更新驅動後畫面異常或更不穩

進安全模式,回到裝置管理員把驅動再回復一次;或用系統還原點退回動手前的狀態(控制台 → 復原 → 開啟系統還原)。

情境二:動了 Driver Verifier 後一開機就藍屏

這是 Driver Verifier 的預期行為(它抓到兇手了)。進安全模式,以系統管理員執行 verifier /reset 關閉所有驗證,重開即恢復。切記別在正常桌面長時間掛著 Verifier。

情境三:系統完全無法開機(最壞情況)

連續強制關機兩到三次進入 WinRE,依序試:啟動修復系統還原(退回還原點)→ 用「命令提示字元」跑 sfc/DISM 離線修復。若是剛更新造成,WinRE 的「解除安裝更新」可移除最近的品質更新。手上有安裝隨身碟會更保險。


💡 總結:預防再次發生

站長我看太多人一跳 0x7E 就急著重灌,結果重灌完裝回同一支舊驅動,幾天後照當——因為根因從頭到尾沒被處理。這顆停止碼的價值,恰恰在於它比大多數藍屏都更願意「指名道姓」:那行 What failed,就是 Windows 遞到你手上的證物。

要少見到它,養成三個習慣就夠:第一,驅動更新採「穩定優先」而非「最新優先」,尤其顯示卡,新版剛出先觀望幾天,出事就回復;第二,大版本升級前先備份、升級後留意頭幾天的穩定度,0x7E 很常在 23H2→24H2 這類跨版本升級後冒出來;第三,把記憶體傾印設定好、關掉自動重新啟動,這樣萬一發作,你手上永遠有 dump 可以辦案,而不是只剩一句「它又當了」。

從技術面看,0x7E 的官方定義穩定到值得記住:一顆「有例外、沒人接」的通報,四個參數裡 Parameter 1 是例外碼、Parameter 2 直指兇手位址。記住這兩個,你就永遠知道下一步該往哪查——這也是它能當作學習藍屏除錯入門磚的原因。


❓ 常見問題

Q:SYSTEM_THREAD_EXCEPTION_NOT_HANDLED 一定是硬體壞了嗎?

不是。它最常見的根因是驅動程式(尤其顯示卡),其次才是系統檔損毀與硬體/韌體。硬體(記憶體、BIOS 相容性)是比較後面的嫌疑。先從 What failed 指向的驅動查起,別一開始就拆機換零件。

Q:藍屏沒有顯示「What failed」檔名怎麼辦?

有些情況只給停止代碼、沒列模組。這時走方法三:確認有 minidump,用 WinDbg 跑 !analyze -v,從 Parameter 2 的例外位址與「Probably caused by」找出 faulting module。事件檢視器的系統記錄檔也常有補充線索。

Q:0x7E 跟結尾 M 的 0x1000007E 一樣嗎?

本質相同(都是系統執行緒未處理例外),排查方向一致。差別在停止碼前綴,實務上照同一套流程(讀例外碼→鎖定模組→處理驅動)處理即可。

Q:進不了安全模式也用不了桌面,還有救嗎?

有。連續強制關機兩到三次會進入 WinRE 修復環境,可做啟動修復、系統還原、解除安裝最近更新,或用命令提示字元離線跑 sfc/DISM。備一支 Windows 安裝隨身碟會更保險。


🔗 延伸閱讀

📎 參考資料來源

📖 第一級|廠商官方:

📖 第二級|權威技術媒體:

⚠️ 本文核心事實以第一級為準,第二級為補充。

📅 本文查證戳記:2026-07-06 依據 Windows 10 / 11 官方停止碼文件撰寫。
若你在後續版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。

廣告