0x139 KERNEL_SECURITY_CHECK_FAILURE BSOD 修復|WinDbg 抓真兇 driver 1

0x139 KERNEL_SECURITY_CHECK_FAILURE BSOD 修復|WinDbg 抓真兇 driver

約 13 分鐘閱讀
作者:
內容目錄 顯示

⚡ 站長快讀:核心重點

  • 文章屬性:疑難排除(Windows 底層除錯,A5)
  • 適用系統:Windows 11 25H2 / 24H2,部分情境含 Windows 10
  • 難易度 / 耗時:⭐⭐⭐ / 約 30–60 分鐘
  • 核心結論:0x139 是核心抓到關鍵資料結構被破壞,真兇九成是某支驅動程式,而不是記憶體壞掉
  • 適用對象:反覆跳 KERNEL_SECURITY_CHECK_FAILURE、重灌跟換 RAM 都沒解決的人

🧰 開始前的準備

  • 適用系統:Windows 11 25H2 build 26200.8457 / 24H2 build 26100.8457(舊版邏輯相同)
  • 權限需求:系統管理員
  • 需要工具:WinDbg(Microsoft Store 可裝)、系統內建的 Driver Verifier(verifier)
  • 預計耗時:約 30–60 分鐘,含等崩潰重現的時間

📌 快速答案

一句話答案:KERNEL_SECURITY_CHECK_FAILURE(0x139)是 Windows 核心偵測到關鍵資料結構被破壞而觸發的當機,最常見原因是驅動程式造成 LIST_ENTRY 損毀,真兇通常不是記憶體而是某支驅動程式。

🔍 症狀描述與錯誤訊息

你有沒有遇過這種狀況:電腦用得好好的,某天開始三不五時跳藍色畫面,上面寫著一行讓人一頭霧水的英文。

🙁 你的裝置發生問題,需要重新開機。 停止碼:KERNEL_SECURITY_CHECK_FAILURE

0x139 KERNEL_SECURITY_CHECK_FAILURE BSOD 修復|WinDbg 抓真兇 driver 3

更氣人的是它沒規律。有人是一玩遊戲就當,有人是開機跑個三十秒就當,還有人乾脆卡在開機畫面、連安全模式都進不去。最讓人崩潰的是——很多人照著網路上「跑 SFC、換一條新記憶體」的標準答案做完,問題照樣復發。

這支錯誤碼的數值是 0x00000139。它跟 0x124(WHEA_UNCORRECTABLE_ERROR)那種「硬體遺書」不一樣:0x139 多半不是你的零件壞了,而是某段程式碼把核心裡一塊很重要的資料結構踩壞了,被 Windows 當場抓包。

🔎 問題根因

0x139 的英文全名是 KERNEL_SECURITY_CHECK_FAILURE。照 Microsoft Learn 的 Bug Check 0x139 文件的定義,它代表「核心偵測到某個關鍵資料結構被破壞」。注意關鍵字是「偵測到」——不是核心自己壞掉,是核心發現有人動了不該動的東西,為了不讓這個破口被惡意程式利用,乾脆直接拉閘當機。

判斷真兇的第一把鑰匙,是這支 bugcheck 的 Parameter 1(第一個參數)。它會告訴你「到底是哪一種損毀」。以下整理最常見的幾個值(完整約 30 種對照表在上面那份 Microsoft Learn 文件裡):

Parameter 1 值代表的損毀類型
0 / 2堆疊緩衝區溢位(/GS 堆疊 cookie 被踩爆)
1VTGuard 抓到非法的虛擬函式表(C++ 物件被汙染)
3LIST_ENTRY 雙向鏈結串列損毀(最常見,例如同一節點被移除兩次)
5把致命的無效參數丟給了核心函式
6載入器沒正確初始化堆疊 cookie(常見於老舊 driver 上錯系統)
10間接呼叫防護(CFG)抓到非法的控制流轉移
11寫入防護抓到非法的記憶體寫入
14某個物件的參考計數(reference count)不合法
21偵測到無效的例外鏈(exception chain)
29RTL_BALANCED_NODE 紅黑樹節點損毀

實務上最常碰到的是 Parameter 1 = 3,也就是 LIST_ENTRY 損毀。白話講,Windows 核心內部用大量「雙向鏈結串列」管理各種物件,每個節點同時記著「前一個」跟「後一個」的位址。只要有支 driver 沒同步好,把同一個節點移除兩次、或是釋放了還掛在串列上的記憶體,串列的前後指標就會對不起來。核心在下次走訪這串列時一發現不一致,立刻 0x139 伺候。

這也解釋了為什麼換記憶體常常沒用:LIST_ENTRY 損毀是「程式邏輯」造成的,不是 RAM 的位元翻轉。當然,Parameter 1 = 0 / 2(堆疊溢位)這類偶爾真的跟超頻不穩或記憶體有關,所以先看 Parameter 1 再決定方向,才不會白花錢。

🧪 硬體測試基準(Testbed Baseline)

項目規格
CPUIntel Core i7-14700K(stock,未超頻)
主機板ASUS ROG STRIX B760-G Gaming WiFi(BIOS 1801)
記憶體G.SKILL Trident Z5 DDR5-6000 32GB(2×16GB,XMP 啟用)
顯示卡NVIDIA GeForce RTX 4070(驅動程式 580.xx 分支)
儲存Samsung 990 Pro 1TB NVMe(韌體 4B2QJXD7)
作業系統Windows 11 25H2 build 26200.8457(2026-05-12 KB5089549)
環境條件室溫 25°C(實驗室空調控制)
量測工具WinDbg(Store 版)、Driver Verifier、HWiNFO64 v8.x

🔬 底層機制:0x139 這個訊號到底從哪一層冒出來?

這一段是這篇跟一般「跑個 SFC 就好」教學最不一樣的地方。搞懂訊號來源,你才知道為什麼有些方法注定無效。

0x139 不是某個硬體中斷送出來的,而是**編譯器跟核心事先埋好的「自爆裝置」**觸發的。Windows 核心在編譯時被插入了一整套完整性檢查:堆疊 cookie(/GS,防堆疊溢位)、控制流防護(CFG,防被劫持跳到惡意位址)、LIST_ENTRY 一致性檢查,以及新版加上的 CET 硬體強制堆疊保護(Hardware-enforced Stack Protection)。這些檢查一旦發現「資料被動過」,不會試著修、也不會回報就算了,而是立刻呼叫一個叫 __fastfail 的機制,把處理器丟進一個不可恢復的陷阱,最後落到 KeBugCheckEx(0x139, …)——也就是你看到的藍屏。

換句話說,0x139 是核心的「寧可死、不可被駭」設計。它把那塊被破壞的資料當成「可能讓攻擊者拿到機器控制權」的破口,所以選擇當場死給你看,而不是帶著一塊被汙染的結構繼續跑。

理解這點之後,LIST_ENTRY 損毀最麻煩的特性就好懂了:損毀的當下不一定會被偵測到。Microsoft Learn 的 Cause 段落講得很清楚——某支 driver 可能在凌晨踩壞了串列,系統卻要等到幾個小時後、下次走訪那串列時才爆炸。等你看到藍屏,真兇早就逃離現場,呼叫堆疊上常常只剩無辜的 nt!Ke*、nt!Ki* 函式在頂罪。這就是為什麼很多人用 WhoCrashed 之類的工具看半天,結論都是「ntoskrnl.exe」——那不是答案,那是替死鬼。

實驗室裡我處理這種「延遲型」LIST_ENTRY 損毀的標準做法,是對嫌疑 driver 開 Driver Verifier 的 Special Pool:它會把每一塊配置夾在防護頁(guard page)中間,只要 driver 寫出界一個 byte,系統會在「出錯的那一行指令、那一瞬間」就立刻當機,而不是放任它默默踩壞隔壁鄰居、拖到幾天後才引爆。對除錯來說,這等於把「偵測延遲從數天壓到零」——!analyze -v 會直接點名那支 driver,而不是丟給你一坨 nt!Ke 的呼叫堆疊。代價是開了 Verifier 之後系統會變慢、而且問題 driver 會更頻繁地當機(這是預期行為,等等回退區塊會教你關掉)。

🛠️ 解決方案

⚠️ 站長警告:本操作涉及系統底層,執行失誤可能導致資料遺失或系統無法開機。 動手前請務必完成:

  1. 建立系統還原點或完整備份
  2. 備份重要資料至外接硬碟或雲端
  3. 筆電 / 手機請確保電源充足

下面按「成功率高、門檻低」的順序排。先把簡單的做完,真的不行再進 Driver Verifier 這種重砲。

方法一:鎖定「最近改了什麼」並回退驅動程式

0x139 絕大多數是「最近裝了某支 driver 或某個軟體」之後才開始的。先回想:最近更新過顯示卡驅動程式嗎?裝了帶 kernel 反作弊的遊戲嗎?上了什麼 RGB 燈控、超頻、螢幕錄影類的常駐工具嗎?根據 Microsoft Q&A 的處理建議,這類工具的核心模式 driver 是 0x139 的常客。

做法:打開裝置管理員 → 找出最近更新的裝置 → 內容 → 驅動程式 → 復原驅動程式。顯示卡驅動程式建議直接到 NVIDIA / AMD / Intel 官網下載「乾淨安裝」舊一個穩定分支。RGB、超頻、反作弊類工具則先整個移除測試。

方法二:用 Event Viewer 對時間 + 跑記憶體與磁碟健檢

打開事件檢視器 → Windows 記錄 → 系統,把時間軸拉到當機的那一刻,找紅色的「重大」或「錯誤」事件,看有沒有哪支 driver 或服務在當機前反覆報錯。

接著排除硬體變因:按 Win 鍵打「記憶體診斷」跑 Windows 記憶體診斷工具;在系統管理員命令提示字元跑這兩行修系統檔:

cmd

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

如果你有超頻或開 XMP / EXPO,先暫時關掉跑預設值測試——Parameter 1 = 0 / 2 的堆疊溢位類有時候真的是記憶體在高頻下不穩。

方法三:抓 minidump,用 WinDbg 跑 !analyze -v

前面兩招無效,就得讓崩潰自己「招供」。先確認系統有在產生小型傾印檔:設定 → 系統 → 系統資訊 → 進階系統設定 → 啟動及修復,把「偵錯資訊寫入」設成「自動記憶體傾印」或「小型記憶體傾印」。崩潰檔預設在 C:\Windows\Minidump\。

裝好 WinDbg 後,把 .dmp 檔拖進去,在命令列打:

!analyze -v

等它跑完,重點看三個東西:BugCheck 後面的四個參數(確認 Parameter 1 是不是 3)、MODULE_NAME / IMAGE_NAME(嫌疑模組),以及 STACK_TEXT(呼叫堆疊)。如果堆疊裡看得到某支第三方 driver 的名字(例如 dxgmms2.sys、nvlddmkm.sys、各家反作弊的 .sys),那就是頭號嫌疑犯。

確認是 LIST_ENTRY(Parameter 1 = 3)時,可以手動把串列往前跟往後各走一遍,比對哪裡對不起來:

dl <鏈結串列位址>
dlb <鏈結串列位址>

dl 往前走、dlb 往後走,兩邊兜不攏的那個節點附近,通常就是損毀點。記得連它的左右鄰居一起看——鏈結串列的更新會動到鄰居的指標,真兇有時候是隔壁。

方法四:Driver Verifier Special Pool 強制定位真兇

如果 !analyze -v 永遠只指向 ntoskrnl、抓不到真兇(延遲型損毀的典型症狀),就出動 Driver Verifier。它會給可疑 driver 套上嚴格的執行期檢查,逼出界存取在第一時間爆炸。

以系統管理員開命令提示字元,啟動標準檢查 + Special Pool,只針對非微軟的 driver(避免拖垮整台):

cmd

verifier /standard /driver suspect1.sys suspect2.sys

或用 GUI:打 verifier → 建立自訂設定 → 勾「特殊集區(Special Pool)」「強制處理擱置的 I/O 要求」→ 自動選取「未經數位簽署」或手動指定可疑 driver。設好後重新開機,正常操作直到再次當機。這次的 minidump 用 !analyze -v 跑,通常會直接點名真兇:

!verifier 3 suspect1.sys

💡 為什麼要這樣做? Special Pool 把配置夾在防護頁中間,出界一個 byte 就立刻在出錯指令當機,而不是默默踩壞鄰居拖到幾天後在無辜模組上引爆。這是把「偵測延遲壓到零」、讓真兇現形的關鍵。切記:Verifier 開了之後系統會變慢、嫌疑 driver 會更常當,這是正常的,測完務必關掉(見回退區塊)。

✅ 驗證修復結果

修完別急著宣布勝利,0x139 最賤的就是「以為好了結果過幾天又來」。

確認步驟:第一,如果是回退/移除某支 driver,維持原本會觸發當機的操作(玩同一款遊戲、跑同樣的負載)至少幾天,確認不再藍屏。第二,回事件檢視器看系統記錄,確認沒有新的同類重大錯誤。第三,如果你開過 Driver Verifier,先確認 Verifier 已關閉(下一節),再觀察——因為 Verifier 本身會放大當機,沒關掉的話你分不清是修好了還是 Verifier 在搗亂。

真正算「解決」,是回到平常的使用強度、連續穩定運作數天都沒再跳 0x139。

🔙 萬一翻車:回退步驟

⭐⭐⭐ 操作一定要會收尾。這節救你兩種狀況:Driver Verifier 開了關不掉、以及系統開機直接卡 0x139 進不去。

情境一:開了 Driver Verifier 之後系統一直當/變超慢

這是預期行為,不是壞掉。能進桌面的話,以系統管理員開命令提示字元打:

cmd

verifier /reset

然後重新開機。這行會把所有 Verifier 設定清空,系統就恢復正常速度了。

情境二:Verifier 設太兇,開機就藍屏進不了桌面

連桌面都進不去時,從 WinRE 救:開機連續強制關機三次會自動進「自動修復」,選疑難排解 → 進階選項 → 命令提示字元,然後打:

cmd

verifier /reset

或先進安全模式(進階選項 → 啟動設定 → 重新開機 → 按 4),安全模式不載入第三方 driver,通常能順利開機,再跑 verifier /reset。

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

如果是卡在開機就 0x139、連安全模式都進不去(社群在 Windows 11 論壇上回報過這種 boot loop),從 WinRE 的命令提示字元試「上次的良好設定」路線:用系統還原點回到當機前(進階選項 → 系統還原),或停用最後安裝的 driver。手上有官方修復媒體的話,可以參考 Microsoft 的藍屏疑難排解指引做進一步修復。資料無價,動手前能備份就先備份。

💡 總結:預防再次發生

講真的,我看過太多人栽在 0x139 的同一個地方:把它當成「記憶體壞了」,跑去買新 RAM、甚至重灌系統,結果一裝回那支闖禍的驅動程式,藍屏立刻回歸。0x139 的本質是程式邏輯把核心資料結構踩壞,Parameter 1 = 3(LIST_ENTRY)更是九成跟某支 driver 脫不了關係,所以方向錯了,錢跟時間都白花。

在 Windows 11 25H2(build 26200.8457)這個版本上,這整套流程依然成立,連抓崩潰的指令都沒變。我自己歸納的預防原則就三條,中性講就是長期實驗室除錯累積下來的習慣:第一,顯示卡驅動程式別追最新、追最穩,新分支出來先讓別人當白老鼠,過一兩週沒災情再上;第二,RGB 燈控、超頻面板、螢幕錄影、反作弊這類核心模式工具能少裝就少裝,它們塞進核心的 driver 是 0x139 的高發地帶;第三,保留一個可用的系統還原點,真出事至少有退路。

最後補一個橫向觀察:近期社群在 Windows 11 25H2 上回報顯卡路徑(dxgmms2.sys / dxgkrnl.sys)反覆觸發 0x139,雖然微軟官方還沒把這列為正式的已知問題,但 0x139 文件本身就建議圖形堆疊崩潰要優先懷疑 GPU 驅動程式與 DirectX 元件。如果你剛好是這個組合又一直跳,先從乾淨重裝顯卡驅動程式下手,通常比亂槍打鳥有效得多。搞定這些,你的機器就不會三天兩頭給你看那張哭臉了。

❓ 常見問題

Q:KERNEL_SECURITY_CHECK_FAILURE 是不是我的記憶體壞掉了?

多數情況不是。0x139 是核心抓到資料結構被破壞,最常見的 Parameter 1 = 3(LIST_ENTRY 損毀)是驅動程式邏輯造成的,跟記憶體位元錯誤沒關係。只有 Parameter 1 = 0 / 2(堆疊溢位)這類,才比較值得跑記憶體診斷或檢查超頻穩定度。先看 Parameter 1 再決定要不要換 RAM,不要一藍屏就先怪記憶體。

Q:我重灌系統了還是一直跳 0x139,怎麼辦?

重灌沒用,代表問題會跟著「你重新裝回去的東西」回來——通常是某支驅動程式或核心模式工具。重灌後請刻意保持乾淨:先別裝任何第三方 RGB / 超頻 / 反作弊工具,顯示卡驅動程式裝官方穩定版,觀察幾天。如果乾淨狀態不當、一裝某樣東西就當,那樣東西就是真兇。

Q:為什麼只有玩遊戲的時候才跳藍屏?

通常是兩個原因:一是遊戲帶的核心模式反作弊 driver 跟你的系統或其他 driver 打架;二是遊戲把顯示卡操到滿載,逼出 GPU 驅動程式裡的 bug(呼叫堆疊常出現 dxgmms2.sys 或 nvlddmkm.sys)。先乾淨重裝顯卡驅動程式,再看是不是特定那款遊戲的反作弊在搞,必要時找遊戲官方的相容性公告。

Q:WhoCrashed / BlueScreenView 都說是 ntoskrnl.exe,是不是 Windows 本身壞了?

幾乎不是。ntoskrnl.exe 是核心本體,它出現在堆疊上多半是「替死鬼」——真兇(某支 driver)早就把資料結構踩壞、自己跑掉了,核心只是在走訪時當場爆炸。要抓真兇得用 WinDbg 跑 !analyze -v 看 Parameter 1 跟更深的堆疊,延遲型的就得開 Driver Verifier Special Pool 逼它現形。

Q:Driver Verifier 開了之後一直藍屏,正常嗎?要怎麼關?

正常。Verifier 的工作就是放大問題、逼 driver 在出錯瞬間當機。測完(或開到進不了桌面)就關掉:能進系統打 verifier /reset 再重開機;進不去就用安全模式或 WinRE 命令提示字元打同一行。千萬別讓 Verifier 一直開著當日常使用。

📎 參考資料來源

📖 第一級|廠商官方:

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