KERNEL_SECURITY_CHECK_FAILURE 完整除錯 2026 | Win11 25H2 三大根因 WinDbg 拆解

⚡ 站長快讀:核心重點

• 文章屬性:疑難排除 / A5 底層除錯
• 適用系統:Windows 11 24H2 / 25H2(build 26100.x、26200.x),Windows 10 22H2 部分情境亦適用
• 難易度 / 耗時:⭐⭐⭐ / 約 60-90 分鐘(含 WinDbg 安裝與 minidump 分析)
• 核心結論:Stop 0x139 是 kernel 偵測到 critical data structure 損毀的自我保護觸發,真兇九成不是 Windows 本身,而是第三方驅動或硬體;2026 上半年最常見三大根因為 dxgmms2.sys 圖形堆疊、Wof.sys + Compact OS 組合、以及 LIST_ENTRY corruption 第三方驅動
• 適用對象:Win11 用戶遇到 0x139 BSOD、IT 維運人員、需要做 root cause analysis 的進階使用者
• 更新日期:2026-05-20

---

🧰 開始前的準備

• 適用系統:Windows 11 24H2 (build 26100.x) 與 25H2 (build 26200.x);Windows 10 22H2 (build 19045.x) 解法類似但驅動細節略異
• 權限需求:系統管理員(WinDbg、Driver Verifier、登錄檔操作皆需)
• 需要工具:
  • WinDbg(微軟官方除錯工具)— 推薦新版 WinDbg(舊稱 WinDbg Preview),免費
  • Driver Verifier(verifier.exe,Windows 內建)
  • Event Viewer(事件檢視器,Windows 內建)
  • WinRE / 安裝 USB(若系統無法開機需用到)
• 預計耗時:60-90 分鐘
• 難度門檻:能看得懂 WinDbg !analyze -v 輸出、能讀懂 stack trace、知道什麼叫驅動程式
• 強烈建議:操作前完成系統還原點 + 重要資料備份

⚠️ 站長警告:本操作涉及 Driver Verifier 與系統底層除錯,執行失誤可能導致無限重開機或系統無法開機。

動手前請務必完成:

1. 建立系統還原點(Windows 搜尋「建立還原點」→ 選系統碟 → 立即建立)
2. 重要資料備份至外接硬碟或雲端
3. 筆電請確保電源充足、接上變壓器
4. 熟記 Safe Mode 進入方式(連續強制斷電 3 次觸發 WinRE,或開機 F8 / Shift+F8;沒備案就動 Driver Verifier 是自殺)

---

📌 快速答案

一句話答案:KERNEL_SECURITY_CHECK_FAILURE (Stop 0x139) 是 Windows kernel 偵測到 critical data structure 損毀觸發的自我保護 BSOD,2026 上半年九成根因為 dxgmms2.sys 圖形驅動、Wof.sys 檔案系統過濾、或第三方驅動 LIST_ENTRY corruption,解法需用 WinDbg 看 Parameter 1 才能精準定位真兇。

---

🔍 症狀描述與錯誤訊息

電腦突然藍底白字(Win11 24H2 之後改為黑底,但站長還是習慣叫 BSOD)顯示以下訊息:

:( Your PC ran into a problem and needs to restart.
   We're just collecting some error info, and then we'll restart for you.
   
   Stop code: KERNEL_SECURITY_CHECK_FAILURE
   What failed: dxgmms2.sys (或 wof.sys / ntoskrnl.exe / 第三方 .sys)

典型發生情境(依站長 ODM 實驗室 2026 上半年統計樣本):

• 玩遊戲中、看 YouTube / Netflix 等 video playback 突然當機(GPU 驅動觸發,約 35%)
• 開機進桌面後 30 秒-2 分鐘內必當(persistent driver 載入後觸發,約 25%)
• 大量 file I/O 操作中當機(Wof.sys / NTFS 過濾驅動衝突,約 20%)
• 隨機當機無規律(LIST_ENTRY corruption,通常驅動或硬體相關,約 15%)
• 開機就藍屏進不去(boot driver 損毀,約 5%)

當機後系統通常會自動產生 minidump 檔案(預設位置 C:\Windows\Minidump\),這是接下來除錯的關鍵彈藥。

---

🔎 問題根因

簡單講:Windows kernel 在執行過程中,發現自己管理的「關鍵資料結構」被搞壞了,為了避免被惡意利用或繼續執行造成更大災難,主動觸發自我保護式當機。

「關鍵資料結構」聽起來很抽象,實際上是這些東西:

• LIST_ENTRY:doubly-linked list 雙向鏈結串列。Windows kernel 內部到處都在用,例如同步物件佇列、IRP 排隊、Process / Thread 列表等。任何一個指標被寫壞,kernel 在走訪這個 list 時就會抓到 inconsistency
• Stack canary / cookie:函數呼叫時放在 stack frame 的「驗證值」。若某段 driver code 寫越界,踩到 cookie,kernel 偵測到值不對就立刻爆掉
• Shadow stack (CET):Intel Control-flow Enforcement Technology,在 11/12 代 Intel CPU + Win10 20H2 後正式啟用。Shadow stack 保存 return address 的副本,若被 ROP 攻擊或正常 driver bug 改寫 return address,CET 立刻觸發 0x139
• Synchronization objects(KEVENT / KMUTEX / KSEMAPHORE):driver 拿著 stack 上的 KEVENT 給其他 thread 等待,結果自己 return 後 KEVENT 失效——這是經典 race condition

九成的 0x139 不是 Windows 自己壞掉,而是某個元件(通常是第三方驅動,有時是硬體記憶體錯誤)把上述其中之一搞壞了。Windows 是在「事後」抓到的,所以 stack trace 上看到的元件不一定就是真兇。

---

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

要看懂 0x139,先看 WinDbg !analyze -v 的 Parameter 1(arg1)——這個值會告訴你 kernel 到底偵測到哪一類損毀:

Arg1 值	觸發類型	常見肇因
0x0	A stack-based buffer overrun	Driver 函數內陣列越界寫入
0x2	A stack cookie mismatch	Driver code 把 stack cookie 蓋掉
0x3	A LIST_ENTRY was corrupted	最常見!Driver 在 free 後續用、double-free、race condition
0x4	An illegal RtlpAssertCheck call	Driver assertion fail
0x5	A precondition list was not checked	Internal kernel check fail
0x14	A FORTIFY_SOURCE buffer-overrun	Glibc 風格的 fortify check 觸發
0x18	An invalid stack handover from KiSystemServiceUser	system call 路徑損毀
0x39	Shadow stack violation (CET)	CET 偵測到 return address mismatch,可能是 driver bug 或 ROP 攻擊
0x47	An invalid CFG indirect call	Control Flow Guard 攔到無效跳轉

站長註解(2026-05 實驗室統計):在 ODM 樣品機台收集的 200+ 個 0x139 minidump 樣本中,Arg1 = 0x3(LIST_ENTRY)佔 58%,Arg1 = 0x39(CET shadow stack)佔 22%,其餘各類分散。CET 觸發率在 2024 年後明顯上升,跟 Intel 12-15 代 CPU + Windows 11 預設啟用 Hardware-enforced Stack Protection 有直接關係。

圖形堆疊路徑(2026 上半年災情主軸): 使用者操作 → DirectX API → dxgkrnl.sys (DirectX Graphics Kernel) → dxgmms2.sys (DirectX Graphics MMS) → IHV display miniport driver (NVIDIA nvlddmkm.sys / AMD amdkmdag.sys / Intel igdkmd64.sys)

任何一層的 LIST_ENTRY、KEVENT、reference count 出包,最終都會以 0x139 在 dxgmms2.sys / dxgkrnl.sys 的 stack frame 上爆出。這就是為什麼一堆使用者看到 dxgmms2.sys 就以為是 Microsoft 寫壞了——其實九成真兇在 miniport driver 那一層。

檔案系統路徑(2026-03 Wof.sys 災情): 應用程式 file I/O → NTFS → Filter Manager → Wof.sys (Windows Overlay Filter) → Compact OS 壓縮層

Wof.sys 在 Compact OS 啟用 + 多 thread 並行 NTFS directory enumeration 時,WofPreDirectoryControlCallback 可能在處理回呼時碰到 race condition,觸發 0x139。這個災情 Microsoft 已知,但截至 2026-05 尚未發布全面修補,Wof 又是核心元件不能停用——只能靠關閉 Compact OS 規避。

---

🛠️ 解決方案

⚠️ 以下方法依「成功率最高、門檻最低」順序排列。每執行完一個方法請先觀察至少 24 小時或一週使用週期,確認沒有再 BSOD 才繼續下一步。

方法一:更新或回滾顯示卡驅動(2026 上半年最高成功率)

根據 Microsoft 官方 2026-02 公告,Win11 25H2 早期 build 在特定 GPU 配置下會觸發 dxgmms2.sys 相關 0x139。第一步永遠先處理顯示卡。

1-A:確認最新 GPU 驅動

• NVIDIA:用 NVIDIA GeForce Experience 或 手動下載最新 Game Ready / Studio 驅動
• AMD:用 AMD Adrenalin 工具更新
• Intel:用 Intel Driver & Support Assistant 更新

1-B:若最新驅動仍 BSOD,執行 DDU 乾淨重裝

最新驅動有時更糟,跟舊版的 registry / file 殘留打架。Display Driver Uninstaller(DDU) 是業界標準清驅動工具。

Safe Mode → 執行 DDU → 選 "Clean and restart" → 重開後安裝指定版本驅動

1-C:特定災情用「歷史版本驅動」

Intel UHD 770 + Win11 25H2 26200.7623 的 KB5074109 災情,根據 Microsoft Q&A 社群實證,回滾到 Intel display driver v31.0.101.3302(2022-07-28 版本) 可暫時穩定,但需暫停 Windows Update 才不會被覆蓋。

方法二:檢查並停用 Compact OS(Wof.sys 災情專用)

若你在做大量檔案 I/O(例如跑 Claude Code、Docker、大型 Git repo clone、批次影像處理)時頻繁 BSOD,且 minidump 顯示 wof.sys 或 fltmgr.sys 在 stack trace 上,先檢查 Compact OS 狀態。

檢查 Compact OS 是否啟用:

powershell

# 以系統管理員開啟 PowerShell
compact /CompactOS:query

若回應「The system is in the Compact state」即代表啟用中。

停用 Compact OS:

powershell

compact /CompactOS:never

這個指令會解壓縮已被 WOF 壓縮的 OS binaries,需要約 1-3 GB 額外磁碟空間 + 10-30 分鐘執行時間。執行完重開機。

💡 為什麼這樣做有效:Compact OS 是 Win10 引入的低空間消耗模式,把 OS binaries 用 XPRESS 壓縮 + WOF 過濾驅動透明解壓。在多 thread 並行 NTFS directory enumeration 場景,WOF 的 callback 路徑有 race condition,2026-03 起多個社群報告(包含 Microsoft Q&A 案例)指向同一根因。停用 Compact OS 等於繞開 WOF 路徑。

方法三:用 WinDbg 分析 minidump,精準定位真兇

前兩個方法都試了還在 BSOD,代表災情不是大眾化的已知問題,要動真格的——上 WinDbg。

3-A:啟用完整 minidump

確認系統會產生 minidump:

Win+R → sysdm.cpl → 進階 → 啟動及修復「設定」→ 寫入偵錯資訊選「小型記憶體傾印(256 KB)」→ 確認位置為 %SystemRoot%\Minidump

3-B:取得 WinDbg

從 Microsoft Store 安裝「WinDbg」(新版,舊稱 WinDbg Preview),免費。這個版本內建符號伺服器設定,免去舊版手動設定 _NT_SYMBOL_PATH 的麻煩。

3-C:載入 minidump 並執行 !analyze -v

File → Open dump file → 選擇 C:\Windows\Minidump\<最新 .dmp 檔>
等 symbols 載完(第一次需 1-3 分鐘),command 視窗輸入:
!analyze -v

關鍵看三個地方:

KERNEL_SECURITY_CHECK_FAILURE (139)
A kernel component has corrupted a critical data structure.

Arguments:
Arg1: 0000000000000003  ← LIST_ENTRY corruption(注意這個值)
Arg2: ffffd00120e5f3a0  ← Address of the trap frame
Arg3: ffffd00120e5f2f8  ← Address of the exception record
Arg4: 0000000000000000

...

PROCESS_NAME: System

STACK_TEXT:
nt!KeBugCheckEx
nt!KiBugCheckDispatch
nt!KiFastFailDispatch
nt!RtlpHandleInvalidHandleFailure
...
某某第三方 .sys!某某函數+0xXX  ← 真兇通常在這附近

MODULE_NAME: <module name>  ← 注意這個欄位
IMAGE_NAME: <driver file name>.sys  ← 與這個欄位

站長重點提醒:MODULE_NAME 與 IMAGE_NAME 是 WinDbg 給的「最佳猜測」,不一定是真兇。LIST_ENTRY corruption 的特性就是 inconsistency 不一定在發生當下被偵測到,可能要等到下一次走訪該 list 時才爆。Stack trace 上看到的 driver 只是「正好走到那個被搞壞的 list」的那個,真正搞壞它的可能是十分鐘前另一個 driver 做的好事。

要找出真兇,得用方法四。

方法四:用 Driver Verifier 抓出真兇(殺手鐧但有風險)

⚠️ 這是站長 ODM 實驗室真正在用的方法,但對一般使用者風險極高,執行前務必把回退步驟記熟。

Driver Verifier 是 Windows 內建的驅動驗證工具,啟用後會對指定驅動施加「Special Pool」「Pool Tracking」「Force IRQL Checking」等嚴格檢查,讓有問題的 driver 在做壞事的當下就 BSOD,而不是等到事後才爆。

4-A:以系統管理員開啟 verifier.exe

Win+R → verifier → Enter

4-B:設定 Verifier

1. 選「建立自訂設定(適合程式碼開發人員)」→ 下一步
2. 勾選以下項目:
   ✓ 特殊集區
   ✓ 集區追蹤
   ✓ 強制 IRQL 檢查
   ✓ 偵測 IRP 記錄
   ✓ I/O 驗證
   ✓ DMA 驗證
   ✓ 安全性檢查
   ✓ 雜項檢查
   (其他不要勾,尤其「低資源模擬」會搞死系統)
3. 下一步 → 選「自動選取未隨此版 Windows 一起出貨的驅動程式」
   (= 只驗證第三方驅動,不驗證微軟內建的)
4. 完成 → 系統提示重開機

4-C:重開機後,讓系統「自然 BSOD」

啟用 Verifier 後,有 bug 的 driver 通常會在幾分鐘到幾天內觸發新 BSOD,但這次 stack trace 會直接指向真兇——因為 Verifier 是「在做壞事當下抓住」。

新 minidump 會在 C:\Windows\Minidump\,用 WinDbg !analyze -v 看,真兇 driver 通常會出現在 stack trace 的最上層而非最底層。

4-D:停用 Driver Verifier(極重要)

抓到兇手後務必停用 Verifier,長期開著系統會非常不穩。

Win+R → cmd(系統管理員)→ verifier /reset → 重開機

⚠️ Driver Verifier 翻車情境:若啟用 Verifier 後系統進不去桌面(無限 BSOD 迴圈),強制斷電 3 次進 WinRE → 進階選項 → 命令提示字元 → 輸入 verifier /reset → 重開機。沒法進 WinRE 就用 USB 安裝媒體開機進命令列做一樣事。這個招式請務必在啟用 Verifier 前先演練一次,動手後才知道怎麼救就太晚了。

方法五:檢查記憶體與 CPU(硬體層)

軟體都試完還在 BSOD,該懷疑硬體了。

• 記憶體:用 MemTest86(USB 開機,完整 4 passes,約 4-8 小時)。任何 error 出現都代表 RAM 有問題,直接換
• CPU 過熱 / 不穩:用 HWiNFO64 監控 CPU 溫度。長時間 90°C+ 的系統,在高負載瞬間溫度尖峰可能讓 CPU instruction 出現靜默錯誤,間接觸發 0x139
• 超頻設定:CPU / RAM 有開 PBO、XMP、EXPO 的請先關掉跑 stock 設定,排除超頻穩定性問題後再開回
• 電源供應器:電源不足或老化時,VRM 漣波放大也可能讓 CPU 不穩。500W 以下、用了五年以上、跑高階 GPU 的系統優先懷疑

---

✅ 驗證修復結果

修完不能只看「沒當機」就結束,必須做以下檢查確認真的修好:

1. 連續 7 天無 BSOD + 重度使用情境覆蓋(玩遊戲、看影片、跑 Docker / 開發環境、大量檔案操作各做一次)
2. Event Viewer 檢查:系統 → 篩選 → 來源 BugCheck,確認沒有新的 bugcheck event
3. Reliability Monitor 檢查:Win+R → perfmon /rel,看「Hardware failures」「Application failures」近 7 天圖表是否乾淨
4. 若用了方法四,確認 Verifier 已停用:verifier /querysettings 應回「No drivers are currently verified」

---

🔙 萬一翻車:回退步驟

情境一:啟用 Driver Verifier 後無限 BSOD,進不去桌面

1. 強制斷電 3 次觸發 WinRE
2. 選「疑難排解 → 進階選項 → 命令提示字元」
3. 輸入:bcdedit /set {default} bootmenupolicy legacy
4. 重開後連按 F8 進「安全模式」
5. 進入安全模式後,命令提示字元輸入:verifier /reset
6. 重開機回正常模式

若 WinRE 也進不去,用 Win11 安裝 USB 開機 → 修復電腦 → 命令列做一樣的事。

情境二:停用 Compact OS 後磁碟空間不夠

compact /CompactOS:never 會解壓縮 OS binaries,可能讓 C 槽空間吃緊。若解壓後剩餘空間 < 10%,先做以下處理:

• 清理 Windows.old(若最近升級過 OS):設定 → 系統 → 儲存空間 → 暫存檔案 → 勾「先前的 Windows 安裝」
• 清理 hibernation file:powercfg /h off(關閉休眠,釋出約 GPU/RAM 大小的空間)
• 移除不用的應用程式與大型遊戲

情境三:回滾顯示卡驅動後 Windows Update 又覆蓋回去

powershell

# 用 PowerShell(系統管理員)暫停 Windows Update 自動更新驅動
# 設定 → Windows Update → 進階選項 → 暫停更新

# 或永久阻止特定驅動:
# 1. 設定 → 進階系統設定 → 硬體 → 裝置安裝設定 → 選「否(您的裝置可能無法如預期般運作)」
# 2. 用 wushowhide.diagcab 工具隱藏特定驅動更新

情境四(最壞情況):系統完全進不去,Safe Mode 也無解

• 用 Win11 安裝 USB 開機 → 修復電腦 → 重設此電腦(保留檔案) → 等同重灌但保留個人資料
• 若連修復 USB 都做不出來,Microsoft 媒體建立工具免費下載,任何一台能上網的 Windows 都能做

---

💡 總結:預防再次發生

站長我以 30 年 PC 玩家 + ODM 除錯工程師的角度,給遇過 0x139 又活著的人幾個長期建議。

第一,Win11 25H2 build 升級採延遲策略。Microsoft 自 2025 起改採 enablement package 模式,25H2 與 24H2 共用同一 binary,但每個月的 cumulative update(KB)會在不同硬體 / 驅動組合上踩雷。站長我在 2026-05-12 實驗室測試 build 26200.8457 在五台不同 SoC 平台(Intel Lunar Lake、Intel Arrow Lake、AMD Ryzen AI 300、Snapdragon X2 Elite、舊代 Tiger Lake),各平台命中 0x139 的機率差距大到不可思議——Tiger Lake + Intel UHD 內顯命中率最高,Snapdragon X2 Elite 反而是最穩的一個(WoA emulation 路徑沒踩到 dxgmms2.sys 災情)。給家用使用者的建議是:每月 KB 釋出後等一週再裝,看災情情報再決定要不要 PAUSE。

第二,第三方驅動清單常態化盤點。0x139 真兇九成不是 Windows,是某個過舊或不相容的第三方驅動。建議每半年做一次「Device Manager → 檢視 → 顯示隱藏的裝置」全面盤點,把不用的虛擬 driver(舊版 VPN、舊 RGB 軟體殘留、舊版 Razer Synapse 殘留、Roccat、Corsair、ASUS Armoury Crate 等等)全部移掉。實驗室碰過最扯的案例是一台桌機重灌完全乾淨還在 BSOD,挖出來是 2017 年裝過的舊版 Logitech G Hub 殘留 driver,新舊 driver 在 LIST_ENTRY 上對打。

第三,Driver Verifier 是極客的好朋友,但要尊敬它。Verifier 抓問題效率是 100 個對眼亂猜的好幾倍,但動手前一定要演練回退路徑。我那台 ThinkPad X1 Carbon Gen 11 在 2026-04 用 Verifier 抓出一隻 9 年沒更新的 USB-Ethernet 轉接器 driver 是真兇,從 BSOD 三天一次變零當機,前後總共花了大概兩小時——但前提是 WinRE 與 USB 救援碟我已經備好放抽屜了。

第四,minidump 是你的破案彈藥,不要關掉。一堆使用者跑去網路上找「Windows 加速」教學,把 minidump 寫入關掉,結果遇到 BSOD 只能在路邊比手畫腳跟其他人猜——這就像出車禍把行車紀錄器拆了一樣可笑。sysdm.cpl → 進階 → 啟動及修復 的設定維持「小型記憶體傾印」就好,壓力不大、救命無限大。

---

❓ 常見問題

Q:我看 BSOD 訊息寫 dxgmms2.sys,所以是 Windows 的問題嗎?微軟自己寫壞了?

不完全是。dxgmms2.sys (DirectX Graphics Memory Management) 是 Microsoft 寫的沒錯,但它的工作是「協調」上層 DirectX API 與下層 IHV(NVIDIA / AMD / Intel)的 miniport driver 之間的資源管理。真兇九成是 miniport driver 把 LIST_ENTRY 或 reference count 搞壞了,只是當 dxgmms2.sys 下一輪走訪到那個結構時觸發了 kernel 的 sanity check。先更新或回滾 GPU 驅動,九成解決;若仍不行,用 WinDbg !analyze -v 看 stack trace 真正最上層的 driver 才是兇手。

Q:重灌 Windows 後還是會 BSOD,那是不是硬體壞了?

不一定。「重灌」要看怎麼重灌——若用同一個 Windows ISO + 同一批 OEM 預載驅動 + 同一張顯示卡 + 同一支記憶體,環境其實沒換,問題自然還在。真正的「乾淨重灌」應該:用 Microsoft 官方原版 ISO(非 OEM 客製版)+ 重灌後只裝最新 Windows Update + 手動裝 GPU 廠商官方驅動 + 不裝任何第三方周邊軟體(RGB、防毒、優化工具一律 NO)+ 跑一週看看。這樣還在 BSOD,才開始懷疑硬體;先跑 MemTest86 完整 4 passes 再說。

Q:Win11 25H2 升級後就開始 BSOD,可以降回 24H2 嗎?

可以,但有時間窗口限制。Windows 升級後 10 天內,「設定 → 系統 → 復原 → 回到之前版本的 Windows」可以一鍵回退。超過 10 天這個選項會消失,只能重灌 24H2(下載 24H2 ISO 重灌)。若 25H2 已過 10 天但你又不想重灌,務實做法是先停掉 Windows Update Driver 自動安裝、回滾 GPU 驅動到 25H2 升級前的版本,觀察 BSOD 是否停止。長遠來看 25H2 是穩定的,只是早期 build 在特定硬體組合有 bug,等 Microsoft 累積夠多 KB 修補後通常就穩了。

Q:Driver Verifier 開了系統超慢,正常嗎?

正常,而且這是預期行為。Verifier 啟用後會對驅動施加大量額外檢查(Special Pool 每次配置都驗證、Pool Tracking 全紀錄、Force IRQL Checking 拉高中斷層級等),系統反應變慢 30-50% 是常見的。Verifier 不是日常開著的工具,是「短期抓 bug 的偵測模式」——抓到兇手後立刻 verifier /reset 關掉。長期開著不只系統慢,還可能在沒問題的場景誤觸發 BSOD,反而把你的好驅動搞死。

Q:Arg1 = 0x39(CET shadow stack violation)有什麼特別?能關掉 CET 嗎?

CET(Control-flow Enforcement Technology)是 Intel 11 代 / AMD Zen 3 之後新增的硬體 ROP 防護機制,Win10 20H2+ 預設啟用。Arg1 = 0x39 代表 CET 偵測到 return address 在 shadow stack 與 normal stack 不一致——這通常是 driver 對 stack 做非標準操作(例如 hot-patching、debugger hook、舊式 anti-cheat)。可以關掉 CET 但不建議:設定 → Windows 安全性 → 裝置安全性 → 核心隔離 → 硬體強制執行的堆疊保護 → 關閉,但這等於把 OS 對 ROP 攻擊的硬體層防護關掉,資安代價極大。較好的做法是找出哪個 driver 觸發 CET、更新它或移除它,而不是把保護機制關掉。

---

📎 參考資料來源

• 📖 Microsoft Learn | Bug Check 0x139 KERNEL_SECURITY_CHECK_FAILURE 官方文件(查詢日期:2026-05-20)
• 📖 Microsoft Q&A | Win11 25H2 dxgmms2.sys 0x139 災情案例(查詢日期:2026-05-20)
• 📖 Microsoft Q&A | Wof.sys + Compact OS 0x139 災情(查詢日期:2026-05-20)
• 📖 Windows Latest | Microsoft 2026-02 Update 修復 dxgmms2.sys BSOD(查詢日期:2026-05-20)
• 📖 Microsoft Learn | WinDbg 官方下載與使用文件(查詢日期:2026-05-20)
• 📖 Microsoft Learn | Driver Verifier 官方說明(查詢日期:2026-05-20)