CRITICAL_STRUCTURE_CORRUPTION 0x109 藍屏|揪出改核心的兇手

文章屬性:疑難排除(A5 底層除錯)
適用系統:Windows 11 / Windows 10(64 位元;PatchGuard 為 x64 核心防護)
難易度 / 耗時:中高 / 約 30–90 分鐘
核心結論:CRITICAL_STRUCTURE_CORRUPTION 0x109 是核心完整性防護(PatchGuard)抓到核心關鍵程式碼或結構被改動;兇手多是會掛進核心的第三方驅動,少數才是記憶體壞掉。
適用對象:無預警跳 CRITICAL_STRUCTURE_CORRUPTION(0x109)藍屏,想自己判斷是驅動還是硬體的人。

📌 快速答案

一句話答案:遇到 CRITICAL_STRUCTURE_CORRUPTION 0x109,照三步走最快——先用 WinDbg 讀 Parameter 4 判斷被改的是哪一區,再更新或移除會掛進核心的第三方驅動(過時防毒、反作弊、超頻工具最常見),最後才用記憶體診斷排除壞掉的 RAM。

🧰 開始前的準備

適用系統:Windows 11 24H2 / 23H2、Windows 10 22H2 等現行 64 位元版本(PatchGuard／Kernel Patch Protection 為 x64 專屬機制)
權限需求:系統管理員(記憶體傾印設定、記憶體診斷、Driver Verifier 都需要)
需要工具:WinDbg(從 Microsoft Store 安裝)、事件檢視器、Windows 記憶體診斷(內建 mdsched.exe);先確認已設好記憶體傾印,藍屏時才有 dump 可查
預計耗時:約 30–90 分鐘(含 Driver Verifier 需重開機觀察一段時間)

🔍 症狀描述與錯誤訊息

電腦在使用中、開機後不久、或在跑某些特定軟體(防毒、遊戲反作弊、虛擬機、硬體監控/超頻工具)時無預警當機,畫面轉為藍色並顯示:

🙁 你的裝置發生問題,需要重新啟動⋯⋯
停止碼(Stop code):CRITICAL_STRUCTURE_CORRUPTION

有時畫面只顯示十六進位停止碼 0x00000109(簡寫 0x109)。重新開機後,到事件檢視器「Windows 記錄 → 系統」可以找到來源為 BugCheck、事件 ID 1001 的紀錄,裡面會帶出四個參數(Parameter 1~4)。

這個停止碼最容易被誤會成「電腦中毒」或「Windows 壞了」。其實它更像是核心的一道完整性防護主動把電腦煞停——因為它發現有人動了不該動的核心結構,寧可當機也不讓系統帶著被竄改的核心繼續跑。

🔎 問題根因

依微軟官方 Bug Check 0x109 文件,這個停止碼一般有三種成因:

某支驅動(有意或無意地)改動了核心的關鍵程式碼或資料。在 Windows Server 2003 SP1 之後的 x64 版本,核心不允許被修補(patch),除非是微軟授權的官方 hot patch;任何其他對核心的修改都會被視為破壞。
開發者用核心偵錯器設了不該設的中斷點——一般中斷點(bp)只能在開機時就掛好偵錯器才設得起來(處理器中斷點 ba 則可隨時設)。這是開發情境,一般使用者幾乎不會遇到。
硬體損壞,例如存放核心程式碼或資料的那段記憶體出錯、位元被寫花。

翻成白話:0x109 幾乎都是「有東西改到了核心的關鍵結構」——不是某支會掛進核心的第三方驅動或軟體(過時的防毒、反作弊、磁碟加密、虛擬化、硬體監控/超頻工具最常見),就是記憶體本身壞掉把那段內容寫花了。它和「某個程式當掉」不是同一層級的事,而是核心的自我保護機制在主動喊停。

CRITICAL_STRUCTURE_CORRUPTION 0x109 三種官方成因:驅動改到核心關鍵程式碼或結構(查第三方核心驅動)、核心偵錯器中斷點設定不當、硬體或記憶體損壞(測 RAM) — 來源:Microsoft Learn Bug Check 0x109 官方三大成因(2026-07-19 查證)

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

要看懂 0x109,得先認識一個關鍵角色:核心修補防護(Kernel Patch Protection,俗稱 PatchGuard)。64 位元的 Windows 核心會把一批「絕對不該被改」的東西保護起來——包括核心程式碼本身、系統服務分派相關結構、中斷描述表(IDT)、全域描述表(GDT)、關鍵的處理器暫存器(MSR)、以及核心的重要函式等。PatchGuard 會不定時巡邏這些受保護區,一旦發現內容跟原本對不上,就立刻觸發 Bug Check 0x109,並把「被改的是哪一類區域」寫進 Parameter 4。

官方 Parameter 4 的對照表很長,常見值例如:0x2 是中斷描述表(IDT)、0x3 是全域描述表(GDT)、0x7 是關鍵 MSR、0xA 是系統服務函式(也就是俗稱「SSDT hook」會踩到的地方)、0x102 是 win32k.sys 被改。你在 dump 裡讀到的 Arg4,就是判斷方向的第一線索。

為什麼「改核心」這麼嚴重?因為早年很多安全軟體、反作弊、甚至 rootkit 都靠「hook 核心」來攔截行為;微軟從 x64 起乾脆用 PatchGuard 把這條路封死——合法的核心擴充要走官方 API,不能偷改。所以當你看到 0x109,與其說是「系統壞了」,不如說是「核心防線抓到有人翻牆」。這也是它和一般驅動當機(例如 0x139 那種即時安全檢查)最大的差別,下一段細講。

🆚 和 0x139 KERNEL_SECURITY_CHECK_FAILURE 有什麼不同?

這兩支停止碼名字都跟「核心安全/結構」有關,常被混為一談,但偵測機制完全不同,分清楚才不會走錯方向:

面向	CRITICAL_STRUCTURE_CORRUPTION 0x109	KERNEL_SECURITY_CHECK_FAILURE 0x139
偵測者	PatchGuard 定期巡邏受保護的核心程式碼/結構	編譯器插入的即時安全檢查(如串列完整性)
抓到什麼	核心關鍵結構「被改動」	某資料結構在使用當下被發現不一致
關鍵參數	Parameter 4 = 被改的區域類型	Parameter 1 = 失敗的檢查類型(如 `0x3` = LIST_ENTRY 損毀)
常見兇手	會 hook / patch 核心的第三方軟體、壞 RAM	亂搞記憶體或連結串列的驅動、壞 RAM

一句話記法:0x109 是「有人動了核心」被巡邏抓到;0x139 是「某個結構壞了」在使用當下被安全檢查攔下。細節可參考站上的 0x139 KERNEL_SECURITY_CHECK_FAILURE 修復教學。兩者根因常有重疊(壞驅動、壞記憶體),但讀的參數不同、下手方向也不同,先分清是哪一支再處理。

🛠️ 解決方案

⚠️ 高風險警語:本文方法四會用到 Driver Verifier,官方明言「執行 Driver Verifier 可能導致電腦當機,只應在你用於測試與除錯的電腦上執行」;方法三涉及硬體與韌體。開始前務必:① 備份重要資料;② 確認能進入安全模式(見回退步驟);③ 若有 BitLocker,先備妥還原金鑰。不確定就先做方法一、二。

方法一:先讀 Parameter 4 與 dump 點名的模組(門檻最低)

先別急著重灌或亂換硬體。用 WinDbg 開啟 minidump 分析,在命令列輸入:

!analyze -v

微軟官方建議先看 !analyze 的輸出,再用堆疊回溯指令(k、kb 等)檢視當機當下的呼叫堆疊。輸出裡的 Arg4 就是 Parameter 4,對照官方表判斷被改的是哪一類區域;!analyze -v 也常在 MODULE_NAME / IMAGE_NAME 直接點名可疑的 .sys。若被點名的是某支第三方驅動,方向就是那支驅動;若指向記憶體或無明確模組,就把硬體列入嫌疑(方法三)。

方法二:更新或移除會掛進核心的第三方軟體

0x109 最常見的現實兇手,是會把驅動掛進核心層的第三方軟體:過時的防毒/資安套件、遊戲反作弊、磁碟加密、虛擬機、硬體監控與超頻工具。官方也指出,若 bug check 訊息點名了某個驅動,就停用它或找廠商要更新版。實務做法:

回想藍屏是不是從安裝或更新某套軟體之後才開始,優先移除該套測試。
到裝置管理員對可疑驅動選「更新驅動程式」或「回復驅動程式」,或到硬體廠商官網抓最新版。
用 Windows Update 把驅動與系統補到最新——官方 hot patch 走的是正規管道,補齊反而能避開衝突。

方法三:測記憶體並確認新硬體相容

官方三大成因之一是硬體/記憶體損壞。執行 mdsched.exe 跑 Windows 記憶體診斷,重開機後到事件檢視器看 MemoryDiagnostics-Results;要更嚴謹可另跑 MemTest86(見延伸閱讀)多輪。若你最近超頻或開了記憶體 XMP／EXPO,先回預設值試試——不穩的記憶體很容易把核心那段內容寫花。官方也建議確認任何新裝的硬體與目前 Windows 版本相容。

方法四:用 Driver Verifier 揪出偷改核心的驅動

當 dump 指不出明確模組、你又高度懷疑是某支驅動時,再上 Driver Verifier。它會即時監控驅動,一發現違規就故意觸發 bug check 把兇手抓包。詳細操作見 Driver Verifier 完整使用教學,重點:

以系統管理員開啟命令提示字元,輸入 verifier 開啟 Driver Verifier 管理員。
選「建立標準設定」→「從清單選擇驅動程式名稱」,只勾非微軟、或近期才更新/安裝的驅動,一次挑少量。
重新開機正常使用讓它跑;若某支驅動違規,系統會觸發 bug check 並在 dump 直接點名那支 .sys。

測完務必關掉:抓到兇手或想停手後,一定要執行 verifier /reset 再重開機,否則系統會一直帶著檢查跑、又慢又容易當。

終極手段:若以上都排除、仍反覆 0x109,才考慮更新主機板 BIOS/UEFI 韌體,或在備妥資料後重灌系統;但重灌前務必先確認不是硬體或那支驅動的問題,否則裝回去照樣當。

✅ 驗證修復結果

移除/更新可疑驅動、或關閉超頻並通過記憶體診斷後,連續正常使用數天不再跳 0x109。
到事件檢視器「系統」記錄,確認不再出現新的 BugCheck(事件 ID 1001)紀錄。
若曾開 Driver Verifier,確認已 verifier /reset 關閉;可再抓一次 dump 用 !analyze -v 確認 bugcheck 不再是 0x109。
若仍偶發,回方法一重讀 Parameter 4:同一個值代表同類問題仍在,換了值則可能是另一支驅動、或改由硬體引起。

🔙 萬一翻車:回退步驟

*(針對方法四 Driver Verifier 的高風險情境)*

情境:開了 Driver Verifier 後一直藍屏、甚至開不了機(boot loop)。

讓電腦在開機途中失敗 3 次,第 4 次會自動進入 Windows 修復環境(WinRE);或在登入畫面按住 Shift 再點「重新啟動」。
WinRE →「疑難排解」→「進階選項」→「啟動設定」→ 重新啟動 → 選「安全模式」。
進安全模式後,以系統管理員開啟命令提示字元,執行 verifier /reset,重新開機即回到沒有 Driver Verifier 的正常狀態。
若連安全模式都進不去:WinRE →「進階選項」→「系統還原」,還原到問題發生前的還原點。

停止條件(符合任一,請先別動方法三、四):不確定哪些是關鍵驅動或硬體型號、尚未完成備份、BitLocker 已啟用但手邊沒有還原金鑰、公司/學校控管設備且無 IT 授權、指令輸出與本文預期不符。

💡 總結:預防再次發生

CRITICAL_STRUCTURE_CORRUPTION 0x109 的本質是「核心防線抓到有人動了關鍵結構」,務實的預防重點就三個:

底層軟體只裝一套、且保持更新:防毒、反作弊、磁碟加密、虛擬機這類會掛進核心的工具,一次裝一套並更新到最新;老舊版本用過時手法碰核心,正是 0x109 的常客。
記憶體別長期硬超:XMP／EXPO 或手動超頻請確認穩定度,不穩的 RAM 會隨機把核心那段內容寫花,表現就是時好時壞的 0x109。
平常先設好記憶體傾印(見延伸閱讀),真的藍屏時才有 dump 可查,不必等它再當一次才後悔沒開。

站長的經驗法則是:0x109 這種「核心完整性」藍屏,先讀 Parameter 4 分清「被改的是哪一區」再動手,幾乎都能把範圍收斂到某支第三方核心驅動或某條記憶體;硬體排除乾淨前別急著重灌,否則把同一支驅動裝回去,照樣再當一次。(本文為官方文件整理,非第一手實測。)

❓ 常見問題

Q:0x109 藍屏是什麼原因造成的?

依微軟官方,三種:某支驅動改到核心關鍵程式碼/結構、核心偵錯器中斷點設定不當(開發情境)、或硬體/記憶體損壞。一般使用者最常見的是第一與第三種——會掛進核心的第三方軟體,或壞掉的記憶體。

Q:「SSDT 遭竄改」是什麼意思?會不會是中毒?

SSDT(系統服務分派表)是核心用來分派系統呼叫的關鍵結構。早年不少安全軟體與惡意程式都靠「hook SSDT」攔行為,x64 的 PatchGuard 把這條路封死——一旦這類系統服務函式被改(對應官方 Parameter 4 的 0xA),就觸發 0x109。它可能是惡意程式,但更多時候是用了老式手法的合法軟體;先照方法一讀 dump、方法二清可疑軟體,別急著斷定中毒。

Q:0x109 跟 0x139 有什麼不同?

0x109 是 PatchGuard 定期巡邏發現核心結構「被改動」;0x139 是編譯器的即時安全檢查在使用當下抓到某資料結構(如連結串列)不一致。前者讀 Parameter 4、後者讀 Parameter 1,下手方向不同。

Q:要怎麼用 Driver Verifier 揪出兇手?

以系統管理員執行 verifier,建立標準設定、只勾非微軟或近期更新的驅動,一次少量,重開機觀察;違規時系統會觸發 bug check 並在 dump 點名那支 .sys。務必先備份、測完用 verifier /reset 關閉。

🔗 延伸閱讀

📎 參考資料來源

📖 第一級|廠商官方:

Bug Check 0x109: CRITICAL_STRUCTURE_CORRUPTION — Microsoft Learn — 2026-07-19 查證
Bug Check 0x139: KERNEL_SECURITY_CHECK_FAILURE — Microsoft Learn — 2026-07-19 查證
Driver Verifier — Microsoft Learn — 2026-07-19 查證
Analyze Bug Check Blue Screen Data — Microsoft Learn — 2026-07-19 查證

⚠️ 本文核心事實以第一級官方文件為準;停止碼參數、成因、Driver Verifier 指令與風險警語均引自 Microsoft Learn。

📅 本文查證戳記:2026-07-19,依 Microsoft 官方文件(Bug Check 0x109、0x139、Driver Verifier、Analyze Bug Check Blue Screen Data)整理撰寫,非第一手實測。若你在後續 Windows 版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。