SYSTEM_SERVICE_EXCEPTION 0x3B 藍屏修復

文章屬性:疑難排除(cornerstone 深度除錯)
適用系統:Windows 10 / Windows 11(含 24H2、25H2)
難易度 / 耗時:中等 / 約 30–60 分鐘
核心結論:SYSTEM_SERVICE_EXCEPTION(0x3B)是程式碼在「使用者模式跨進核心模式」執行系統服務的那一刻丟出未處理例外,九成跟驅動(尤其顯示卡)有關;先讀藍屏鎖定模組,再用 WinDbg 對第三參數下 .cxr 跳到出事現場、讀 Arg1 例外碼確認真兇
適用對象:開遊戲、更新完驅動或用到一半跳 0x3B 藍屏,想自己揪出兇手驅動的人

📌 快速答案

一句話答案:SYSTEM_SERVICE_EXCEPTION(0x3B)代表某段程式碼在從使用者模式轉入核心模式執行系統服務時,丟出了沒人接住的例外,最常見兇手是顯示卡等驅動程式;先看藍屏「What failed」或事件檢視器鎖定出包模組,進安全模式回復或更新該驅動,再用 WinDbg 對第三個參數(context record)下 .cxr 跳到出事當下、配合 kb 與 Arg1 例外碼確認真兇。

🧰 開始前的準備

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

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

🔍 症狀描述與錯誤訊息

先給結論:看到 SYSTEM_SERVICE_EXCEPTION,先別急著重灌或換記憶體——這顆停止碼跟它的近親 0x7E 一樣,重點在「是哪一種例外、由哪支模組丟出來的」,而不是停止碼本身。

典型症狀有三種。第一種是開遊戲、跑繪圖/影音軟體的當下突然藍屏,這是 0x3B 最經典的情境,因為這類程式會頻繁呼叫顯示卡驅動,而顯示卡驅動正是 0x3B 的頭號常客。第二種是剛更新完驅動或剛升級大版本(例如 23H2 升 24H2)後開始發作,通常是新驅動與系統不相容。第三種是隨機發作、沒有明顯規律,這種比較可能牽涉記憶體、系統檔損毀或第三方防毒的核心攔截。

藍屏畫面會長這樣:

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

如果藍屏有列出「What failed」那一行,那就是你的第一條線索——常見的像 nvlddmkm.sys(NVIDIA 顯示卡)、atikmdag.sys(AMD 顯示卡)、dxgmms2.sys(DirectX 圖形核心)、win32kfull.sys(核心圖形子系統)。不過 0x3B 有時只給停止碼、不列模組,那就得靠後面的 WinDbg 上場。

🔎 問題根因

直接講白話:0x3B 的官方定義是「在一段從非特權(使用者模式)程式碼轉換到特權(核心模式)程式碼的例程執行途中,發生了例外」。翻成人話——你的程式呼叫了一個要進核心處理的系統服務,結果在核心那一側跑到一半踩雷、丟出例外,又沒有任何處理常式接住,系統只好觸發藍屏保護自己。

微軟官方說得很清楚:這通常是因為存取了一個 NULL 指標,或是碰到一個隨機的錯誤位址;而這又常常源於記憶體被過早釋放,或資料結構被寫壞。它本身不是根因,而是一個「有例外沒人接」的通報。

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

驅動程式問題(最常見):過舊、損毀、或與目前 Windows 版本不相容的驅動,尤其是顯示卡驅動。剛更新完驅動或剛升級大版本後才發作,九成是這類。
系統檔案損毀:Windows 核心元件或驅動快取被改壞,sfc/DISM 常能救。
第三方防毒/系統掛勾軟體:某些會掛進核心的防毒、磁碟工具、VPN 或螢幕錄製軟體,若相容性沒跟上,會在系統服務轉換點上出事(這屬於社群回報的常見案例,並非官方唯一定義)。
硬體與記憶體:記憶體不穩會讓例外碼落在 0xC0000005(存取違規)卻又抓不到特定驅動;超頻或 XMP/EXPO 開太猛也會誘發。

🔬 底層機制:0x3B 為什麼是「轉換點」的例外

這一段是這篇跟一般「跟著做就好」教學的分水嶺。你不用會寫驅動,但知道這顆停止碼的訊號怎麼來的,你才知道每個步驟在修什麼,也才知道它跟其他藍屏差在哪。

先講它獨特的地方:很多藍屏是「核心自己跑一跑出事」,但 0x3B 特別點名使用者模式與核心模式的「轉換點」。當你的應用程式呼叫一個系統服務(system service),CPU 會從非特權層切到特權層去執行核心程式碼;0x3B 就是在這個交界的核心側執行途中丟出例外。這也是為什麼它跟大量呼叫核心的顯示卡驅動這麼有緣——微軟官方甚至直接點出,過去這個錯誤常跟「使用者模式圖形驅動越界、把壞資料傳進核心程式碼」導致分頁集區(paged pool)被過度使用有關。

微軟官方文件列出 0x3B 的四個參數,這是 WinDbg 分析時最重要的線索,而且它跟 0x7E 的參數排列不一樣,別記混:

參數	意義
Arg1(Parameter 1)	造成當機的例外碼(exception code)
Arg2(Parameter 2)	造成當機的指令位址(faulting instruction)
Arg3(Parameter 3)	這個例外的 context record 位址(關鍵:可直接餵給 `.cxr`)
Arg4(Parameter 4)	0(未使用)

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

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

而 Arg3(context record 位址)是 0x3B 除錯的必殺技:因為它就是「例外發生當下的暫存器快照」,你可以在 WinDbg 直接下 .cxr 加上這個位址,把偵錯器的視角瞬間拉回出事那一刻的現場,再用 kb 看當時的呼叫堆疊。這比只看一句含糊的「Probably caused by」精準得多——這也是官方文件對 0x3B 明確建議的除錯路徑。

🛠️ 解決方案

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

方法一:鎖定並回復/更新那支驅動(成功率最高)

這是 0x3B 的標準解法,因為它最常見的根因就是驅動,尤其顯示卡。

先拿到兇手模組名。如果藍屏有列「What failed」就記下來;沒有的話,開事件檢視器 → Windows 記錄檔 → 系統,找當機時間點附近的 Error(來源常是 BugCheck),或看「可靠性監視器」的當機事件。要讓藍屏停得住看清楚,先做好記憶體傾印設定、關掉自動重新啟動——完整做法看站長這篇〈當機藍屏一閃就重開?先關自動重新啟動、設好記憶體傾印再抓兇手〉。
進安全模式。安全模式只載入最基本的驅動,能繞過出包的那支。Windows 11 路徑:設定 → 系統 → 復原 → 進階啟動 → 立即重新啟動,重開後選 疑難排解 → 進階選項 → 啟動設定 → 重新啟動,再按 4(安全模式)或 5(安全模式加網路)。若根本進不了系統,連續強制關機兩到三次,第三次會自動進入 WinRE 修復環境。
在安全模式裡處理那支驅動。開裝置管理員,找到對應裝置(顯示卡驅動就找「顯示卡」):

最近更新驅動後才壞 → 右鍵裝置 → 內容 → 「驅動程式」分頁 → 回復驅動程式(Roll Back Driver)。
驅動太舊 → 到廠商官網(NVIDIA/AMD/Intel/主機板廠)下載最新版乾淨安裝。顯示卡建議先用 DDU 完整移除舊驅動再裝。

💡 為什麼優先動顯示卡驅動? 微軟官方在 0x3B 的除錯說明裡直接點名:這個錯誤過去常跟使用者模式圖形驅動越界、把壞資料傳進核心有關。nvlddmkm.sys、atikmdag.sys、dxgmms2.sys 幾乎是 0x3B 的常客,先從這裡查準沒錯。

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

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

sfc /scannow

DISM /Online /Cleanup-Image /RestoreHealth

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

方法三:用 WinDbg 讀 dump,下 .cxr 跳到出事現場

前兩招無效、或你想一次確認兇手,就進 WinDbg。這是站長最推薦的做法,因為它是用證據辦案,而不是猜;而且 0x3B 有 Arg3 這個 context record,特別適合精準定位。

先確定有留下 minidump(位置在 C:\Windows\Minidump)。
WinDbg 開啟該 .dmp,跑 !analyze -v,先看官方 !analyze 會直接列出的 Arg1~Arg4:

SYSTEM_SERVICE_EXCEPTION (3b)
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff802...,       Address of the instruction which caused the bugcheck
Arg3: ffff9c0a...,       Address of the context record
Arg4: 0000000000000000,  zero

對 Arg3 下 .cxr,把視角切到例外發生當下,再看堆疊:

.cxr <Arg3 的位址>

kb

想直接問「是哪支驅動」,可以用官方提供的這個指令,它會讀出負責的驅動名:

dx KiBugCheckDriver

要把 Arg1 的例外碼翻成人看得懂的說明,用:

!error <Arg1 的例外碼>

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

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

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

Driver Verifier 的 pool 選項揪隱藏兇手:當 WinDbg 一直只給「ntoskrnl.exe」這種含糊答案、抓不到真兇時,官方建議針對「分頁集區被濫用」這個 0x3B 的常見成因,用 Driver Verifier 的記憶體集區選項對第三方驅動施壓,逼有問題的那支現形。這是強力工具但會故意讓有問題的驅動更快藍屏,設定與收尾要照規矩來——完整用法與關閉方式看〈Driver Verifier 完整實戰指南〉。
移除最近安裝的第三方核心軟體:若你最近裝了會掛進核心的防毒、磁碟/VPN/螢幕錄製工具,先在安全模式暫時移除或停用測試。這類軟體與新版 Windows 不相容時,常在系統服務轉換點上出事(社群案例常見,尚無法確認是否普遍)。
記憶體與硬體檢測:例外碼是 0xC0000005 又找不到特定驅動時,跑 Windows 記憶體診斷或 MemTest86 驗記憶體;若最近超頻或開了 XMP/EXPO,先關掉回預設值測試。最近有新增硬體也先移除或換掉試試。

✅ 驗證修復結果

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

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

🔙 萬一翻車:回退步驟

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

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

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

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

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

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

💡 總結:預防再次發生

站長我看太多人一跳 0x3B 就急著重灌,結果重灌完裝回同一支舊驅動,幾天後照當——因為根因從頭到尾沒被處理。這顆停止碼的價值,在於它把問題定位在一個很具體的地方:使用者模式跨進核心模式的那個轉換點。而它遞給你的證物,就是那四個參數。

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

從技術面看,0x3B 的官方定義穩定到值得記住:一顆發生在「使用者→核心轉換點」的未處理例外;四個參數裡 Arg1 是例外碼、Arg2 是指令位址、Arg3 是可以拿去 .cxr 的 context record。記住這三個,你就永遠知道下一步該往哪查。

❓ 常見問題

Q:SYSTEM_SERVICE_EXCEPTION 一定是驅動壞了嗎?

不是,但驅動(尤其顯示卡)是機率最高的嫌疑。其次是系統檔損毀、第三方核心軟體(防毒/VPN/磁碟工具)相容性,再來才是記憶體與硬體。先從藍屏或事件檢視器指向的模組查起,別一開始就拆機換零件。

Q:0x3B 跟 0x7E(SYSTEM_THREAD_EXCEPTION_NOT_HANDLED)有什麼不同?

兩者都是「有例外沒人接」的藍屏,排查方向也相近(讀例外碼→鎖定模組→處理驅動)。差別在於 0x3B 特別發生在「使用者模式轉入核心模式執行系統服務」的路徑上,而且參數排列不同:0x3B 的 Arg3 是 context record(可直接 .cxr)、Arg4 未使用。實務上照同一套流程處理即可。

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

有些情況只給停止代碼、沒列模組。這時走方法三:確認有 minidump,用 WinDbg 跑 !analyze -v,對 Arg3 下 .cxr 再 kb 看堆疊,或用 dx KiBugCheckDriver 讀出負責的驅動名。事件檢視器的系統記錄檔也常有補充線索。

Q:例外碼顯示 0xC0000005 代表什麼?

那是 STATUS_ACCESS_VIOLATION,記憶體存取違規,是 0x3B 最常見的例外碼。通常代表某支驅動存取了不該碰的記憶體,指向驅動或記憶體問題;若換驅動無效,就要驗記憶體。

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

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

🔗 延伸閱讀

📎 參考資料來源

📖 第一級|廠商官方:

Bug Check 0x3B: SYSTEM_SERVICE_EXCEPTION — Microsoft Learn — 2026-07-07 查證
.cxr (Display Context Record) — Microsoft Learn — 2026-07-07 查證
Analyzing a Kernel-Mode Dump File with WinDbg — Microsoft Learn — 2026-07-07 查證
Driver Verifier — Microsoft Learn — 2026-07-07 查證

⚠️ 本文核心事實(停止碼定義、四參數、例外碼、.cxr 除錯路徑)以第一級 Microsoft Learn 官方文件為準,無任何第一手實測宣稱。

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