CRITICAL_OBJECT_TERMINATION 0xF4 藍屏怎麼修

文章屬性:疑難排除(A5 底層除錯)
適用系統:Windows 11 / Windows 10(停止碼機制與參數判讀在現行版本一致)
難易度 / 耗時:中高 / 約 30–90 分鐘
核心結論:CRITICAL_OBJECT_TERMINATION 0xF4 代表關鍵系統程序或執行緒意外死掉、系統當機自保;真正死因寫在參數與 ExitStatus,實務上常追到磁碟連線,而非換 RAM 能解決。
適用對象:無預警跳 0x000000F4 藍屏,想自己判斷是磁碟、驅動還是資源問題的人。

📌 快速答案

一句話答案:CRITICAL_OBJECT_TERMINATION 0xF4 是關鍵系統程序(如 csrss.exe)意外終止觸發的藍屏;先讀 Bug Check 四個參數認出死掉的程序,再查 ExitStatus 與例外碼判死因,方向多半落在磁碟連線、儲存驅動或系統資源耗盡。

🧰 開始前的準備

適用系統:Windows 11 24H2 / 23H2、Windows 10 22H2(停止碼與 WinDbg 判讀方式一致)
權限需求:系統管理員(記憶體傾印設定、chkdsk、驅動更新都需要)
需要工具:事件檢視器(內建)、WinDbg(從 Microsoft Store 安裝)、chkdsk;先確認已設定好記憶體傾印,藍屏時才有 dump 可查
預計耗時:約 30–90 分鐘(視要不要做磁碟檢測而定)

🔍 症狀描述與錯誤訊息

電腦在使用中、或開機登入前後無預警當機,畫面轉藍並顯示:

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

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

這種藍屏的特徵是「來得很突然、常常在開機或高負載時發生」,而且很容易被誤判成記憶體壞掉。但 0xF4 的本質是某個關鍵程序被判定死亡,系統為了保護自己才主動當機——要知道方向,得先讀懂它到底是誰死了、為什麼死。

🔎 問題根因

依微軟官方 Bug Check 0xF4 文件,CRITICAL_OBJECT_TERMINATION 的定義是:一個對系統運作至關重要的程序或執行緒,意外退出或被終止。官方講得很直白——系統有好幾個非它不可的程序與執行緒,只要其中一個因為任何原因被終止,系統就無法再運作下去,於是觸發這個 bug check。

換句話說,0xF4 本身不是「哪個硬體壞了」的直接指控,而是「守門員倒了」的結果通報。真正要追的是:是誰倒了(哪個程序),以及為什麼倒(ExitStatus / 例外碼)。這兩個答案,官方都放在停止碼的四個參數裡。

要注意的是,官方文件本身只定義「關鍵程序死了」,並未對成因做頻率排名。但依站長經驗與社群、微軟問答的普遍回報,關鍵程序突然死亡最常被追到的一條線是磁碟 I/O:當系統要從硬碟把關鍵程序的程式碼或資料頁換入記憶體時,如果讀取失敗(硬碟壞軌、SATA/NVMe 連線鬆脫、儲存控制器或驅動異常),這個程序就會因為拿不到自己需要的頁面而崩潰,連帶把系統拖下水。這也是為什麼實務上 0xF4 常常最後查到的是磁碟或排線問題,而不必然是 RAM——但這是經驗歸納,不是微軟官方對成因的排序,實際仍要靠參數與 ExitStatus 判定。

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

先把官方的四個參數攤開來看(依 Microsoft Learn Bug Check 0xF4):

參數	意義
Parameter 1	終止的物件型別:0x3 = 程序(Process)、0x6 = 執行緒(Thread)
Parameter 2	終止的物件本身(程序時,是指向 `_EPROCESS` 結構的指標)
Parameter 3	該程序的映像檔名(process image file name)
Parameter 4	指向一段 ASCII 說明訊息的指標

這四個參數就是整個排錯的地圖。Parameter 1 先告訴你死的是「程序」還是「執行緒」;Parameter 3 直接點名是誰(在真實案例裡常常是 csrss.exe 這類關鍵子系統程序);而 Parameter 2 指向的 _EPROCESS 結構裡,藏著最關鍵的一個欄位:ExitStatus——這個 NTSTATUS 值就是「這個程序臨死前拿到的錯誤碼」,是判死因的核心線索。

微軟官方 NtDebugging 團隊有一篇經典的 0xF4 除錯實例可以說明這條路徑:工程師用 !analyze -v 看到死掉的是 csrss.exe,再從例外記錄(exception record)讀到例外碼 0xC0000006(In-page I/O error,換頁 I/O 錯誤),進一步用 !error 解出底層 NTSTATUS 是 0xC000009A(系統資源不足)。也就是說,那台機器是因為非分頁集區(non-paged pool)被耗盡,導致 csrss.exe 的一次 I/O 操作失敗而死。這個例子很好地示範了 0xF4 的判讀邏輯:停止碼只說「關鍵程序死了」,而參數與例外碼才說「怎麼死的」。

這也是 0xF4 和它的近親 CRITICAL_PROCESS_DIED 0xEF 的關係:兩者都是「關鍵程序死亡」觸發的藍屏,成因也高度重疊(硬碟與記憶體問題最常見),差別在於 0xF4(CRITICAL_OBJECT_TERMINATION)涵蓋程序與執行緒、並在參數裡直接給你 _EPROCESS 與 ExitStatus 這條除錯入口;0xEF 則專指關鍵「程序」終止。遇到其中一個,判讀思路可以互相參照。

🛠️ 解決方案

⚠️ 高風險警語:本文方法二、方法三會動到磁碟檢測與硬體排線。動手前務必:① 先備份重要資料(磁碟連線異常本身就代表資料有風險,別在這時候還去做寫入密集的操作);② 拆機重插排線前完全斷電並拔除電源;③ 若磁碟已啟用 BitLocker,先備妥還原金鑰再動。不確定就先只做方法一的讀取判讀。

方法一:讀 Bug Check 四參數與 ExitStatus(門檻最低,先做)

先別急著拆機或重灌。用 WinDbg 開啟 minidump 分析,在命令列輸入:

!analyze -v

輸出裡的 Arg1 是 Parameter 1(0x3 程序 / 0x6 執行緒),PROCESS_NAME 或 Arg3 會直接點名死掉的程序。接著讀最關鍵的死因——用 Parameter 2(那個 _EPROCESS 指標)查 ExitStatus:

dt _EPROCESS <Arg2的位址> ExitStatus

拿到 ExitStatus(一個 NTSTATUS 碼)後,用 !error 把它翻成白話:

!error <ExitStatus值>

如果 !analyze -v 有附例外記錄,也可以用 .exr 讀出例外碼再 !error 解碼。看到 In-page I/O error(0xC0000006) 這類與換頁/磁碟 I/O 有關的碼,方向就指向磁碟(方法二);看到資源不足(如 0xC000009A),方向是系統資源耗盡(通常牽涉某支吃記憶體的驅動)。

方法二:排除磁碟與連線問題(0xF4 最常見的一條線)

當 ExitStatus / 例外碼指向 I/O,或你手邊沒有 dump 可查時,先從最常見、也最好驗的磁碟連線查起:

重插儲存排線:完全斷電後,把 SATA 資料線與電源線兩端重插;NVMe SSD 則重新插拔 M.2 插槽。老化或鬆脫的排線是 0xF4 的常見元兇,尤其是最近搬過機、清過灰的機器。
跑磁碟檢測:以系統管理員開啟命令提示字元,對系統碟執行 chkdsk C: /f /r(會要求下次開機時掃描,過程較久)。這一步能揪出壞軌與檔案系統損毀。
看 SMART 健康度:用硬碟廠商工具或 CrystalDiskInfo 之類看 SSD/HDD 的 SMART 值,若出現重新配置磁區、待處理磁區等警告,代表磁碟本身開始退化。

如果 0xF4 是開機階段就跳、甚至進不了系統,判讀方向會和 INACCESSIBLE_BOOT_DEVICE 0x7B 高度重疊——兩者都可能是系統碟連線或儲存驅動出問題,排查手法可以互相參照。

CRITICAL_OBJECT_TERMINATION 0xF4 排錯分流:Arg1 認程序或執行緒、Arg3 認程序名、Arg2 的 _EPROCESS 讀 ExitStatus,例外碼為 In-page I/O 指向磁碟連線、資源不足指向 non-paged pool

方法三:更新儲存/晶片組驅動並修復系統檔

排除實體連線後,回頭處理軟體層:

到主機板或 SSD 廠商官網,更新儲存控制器 / 晶片組驅動(特別是 Intel RST、AMD 或 NVMe 驅動);近期才更新過某支底層驅動後才開始跳 0xF4,就先回復(rollback)到舊版測試。
以系統管理員執行系統檔修復:先 sfc /scannow,再用 DISM /Online /Cleanup-Image /RestoreHealth 修復元件存放區。關鍵程序的映像若損毀,也會導致它啟動即死。
若最近安裝過會掛在系統底層的第三方軟體(防毒、磁碟加密、備份工具、虛擬機),先移除測試——這類軟體的核心驅動偶爾會拖垮關鍵程序。

✅ 驗證修復結果

重插排線 / 更新驅動 / 修復系統檔後,連續正常使用數天不再跳 0xF4。
到事件檢視器「系統」記錄確認不再出現新的 BugCheck(事件 ID 1001)紀錄。
若做過 chkdsk /r,回事件檢視器看來源 Chkdsk(或 Wininit)的結果,確認壞軌已處理、沒有持續增加。
若仍偶發,回方法一重讀新的 dump:比對 Parameter 3(死掉的程序)與 ExitStatus 有沒有變——值一樣代表同一條線還沒斷,值變了則可能是另一個死因。

🔙 萬一翻車:回退步驟

*(針對方法二 / 方法三動到磁碟與驅動的情境)*

情境一:更新驅動後反而更不穩或開不了機。

開機途中連續失敗 3 次,第 4 次會自動進入 Windows 修復環境(WinRE);或在登入畫面按住 Shift 再點「重新啟動」。
WinRE →「疑難排解」→「進階選項」→「啟動設定」→ 重新啟動 → 選「安全模式」。
進安全模式後,到裝置管理員對剛更新的驅動選「回復驅動程式」,或用「系統還原」還原到更新前的還原點。

情境二:chkdsk /r 跑到一半卡住或磁碟狀況更差。

這通常代表磁碟已經在物理退化邊緣。立刻停止一切寫入操作,優先把資料備份出來(用另一台機器或開機碟以唯讀方式複製),再考慮更換磁碟。硬體壞軌不是軟體能修好的。

停止條件(符合任一,請先不要繼續動手,先求助或先備份):不確定哪顆是系統碟、尚未完成備份、BitLocker 已啟用但手邊沒有還原金鑰、磁碟已出現大量 SMART 警告、公司/學校控管設備且無 IT 授權。

💡 總結:預防再次發生

CRITICAL_OBJECT_TERMINATION 說到底是「系統的守門員被迫倒下」,而站長看過的 0xF4 案例,追到最後很高比例都不是玄學,而是很務實的三類:磁碟連線、儲存退化、以及某支亂搞的底層驅動。務實的預防重點就三個:

別忽略磁碟的早期警訊:偶發卡頓、開機變慢、事件檢視器開始出現磁碟相關警告時,就先看一次 SMART——0xF4 常常是磁碟臨終前的其中一次表現。
搬機、清灰後順手重插排線:很多 0xF4 是「動過機殼之後」才開始的,排線兩端到位、卡榫扣好,能省掉一大堆冤枉路。
平常就把記憶體傾印設定好:真的藍屏時才有 dump 可查,不必等它再當一次才後悔沒開;有了 dump,方法一的參數判讀才能派上用場。

站長的經驗法則是:0xF4 這種「關鍵程序死亡」型藍屏,重灌往往只是把系統重新裝到同一顆有問題的磁碟上、或再把同一支驅動裝回去,治標不治本。先把參數與 ExitStatus 讀清楚、再對症下藥,才不會白忙一場。

❓ 常見問題

Q:CRITICAL_OBJECT_TERMINATION 是什麼意思?

它代表一個系統運作不可或缺的程序或執行緒意外退出或被終止。官方說明得很直接:這些關鍵程序只要有一個死掉,系統就無法繼續運作,於是觸發 Bug Check 0x000000F4 主動當機自保。

Q:0xF4 藍屏到底是硬碟問題還是驅動問題?

兩者都可能,但實務上磁碟(壞軌、排線鬆脫、SSD 退化)是最常見的一條線。判斷方法是讀 dump 的 ExitStatus 與例外碼:出現換頁 I/O 錯誤就先查磁碟連線,出現資源不足就查吃記憶體的驅動。

Q:CRITICAL_OBJECT_TERMINATION 跟 CRITICAL_PROCESS_DIED 差在哪?

兩者都是關鍵程序死亡觸發的藍屏,成因高度重疊。0xF4(CRITICAL_OBJECT_TERMINATION)涵蓋程序與執行緒,並在參數裡直接給你 _EPROCESS 和 ExitStatus 這條除錯入口;0xEF(CRITICAL_PROCESS_DIED)則專指關鍵程序終止。判讀思路可以互相參照。

Q:怎麼查 ExitStatus 判斷原因?

用 WinDbg 開 dump 跑 !analyze -v,拿到 Parameter 2(指向 _EPROCESS 的指標)後,輸入 dt _EPROCESS <位址> ExitStatus 讀出 NTSTATUS 值,再用 !error <值> 翻成白話錯誤描述,就能判斷這個關鍵程序臨死前遇到什麼問題。

🔗 延伸閱讀

📎 參考資料來源

📖 第一級|廠商官方:

Bug Check 0xF4: CRITICAL_OBJECT_TERMINATION — Microsoft Learn — 2026-07-18 查證
Debugging a Bugcheck 0xF4(NtDebugging 官方除錯實例)— Microsoft Learn — 2026-07-18 查證

⚠️ 本文核心事實以第一級官方文件為準:停止碼定義、四個參數、ExitStatus 與例外碼判讀方式均引自 Microsoft Learn;磁碟連線為常見成因屬社群與官方問答之普遍案例歸納,非單一官方定論。

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