CRITICAL_PROCESS_DIED 0xEF 藍屏怎麼修|站長揪兇

文章屬性:疑難排除(BSOD 底層除錯)
適用系統:Windows 11(24H2 / 25H2)與 Windows 10
難易度 / 耗時:⭐⭐ 中等偏進階 / 約 30–60 分鐘
核心結論:CRITICAL_PROCESS_DIED 是系統關鍵程序被搞死時觸發的保護性藍屏,九成出在驅動程式、系統檔或磁碟,先進安全模式跑 SFC 與 DISM 最有效
適用對象:開機就跳 0xEF、或隨機當機停在這個停止代碼的人

📌 快速答案

一句話答案:CRITICAL_PROCESS_DIED(0xEF)代表 csrss、wininit 等關鍵系統程序意外結束,Windows 為保護資料而強制藍屏;依序用安全模式跑 SFC、DISM 修系統檔,再還原問題驅動、chkdsk 檢查磁碟,多數情況不必重灌。

🧰 開始前的準備

適用系統:Windows 11 全版本、Windows 10;藍屏畫面顯示 CRITICAL_PROCESS_DIED,對應 Bug Check 代碼 0x000000EF
權限需求:系統管理員(SFC、DISM、chkdsk 都要用「系統管理員」命令提示字元)
需要工具:Windows 內建命令提示字元、事件檢視器、Windows 修復環境(WinRE);進階分析需要 WinDbg 與 minidump
預計耗時:基本修復約 30 分鐘;DISM 線上修復視網路與磁碟速度約 20–40 分鐘
難度門檻:會開系統管理員命令提示字元、會進安全模式就能做前半段;WinDbg 分析屬進階選配

🔍 症狀描述與錯誤訊息

先講結論:看到 CRITICAL_PROCESS_DIED,不代表你的電腦「壞了」,而是 Windows 主動踩剎車。這個藍屏最典型的畫面,是那張哭臉配上一行停止代碼:

🙁 你的裝置發生問題,需要重新啟動。
停止代碼:CRITICAL_PROCESS_DIED

它的行為模式有幾種很好認的樣子。第一種是開機開到一半就跳,重開機後又卡在同一個地方,形成無限藍屏迴圈(boot loop),連桌面都進不去。第二種是用到一半隨機當,可能是登入後幾分鐘、也可能是跑某個程式時,畫面凍一下就藍給你看。第三種比較隱匿,平常不當,但每次 Windows Update 之後或插上某個裝置才觸發。

不管哪一種,共通點都是:某個「不能死」的系統程序死了,而 Windows 判斷再撐下去會傷到你的資料,乾脆自己 bug check 重開。搞清楚這件事,你就知道為什麼「重灌」不該是第一步——因為問題常常出在驅動或磁碟,重灌只是把症狀壓下去,兇手還在。

🔎 問題根因

CRITICAL_PROCESS_DIED 的根因,幾乎都可以歸到「某個關鍵系統程序的狀態被破壞」這一句話上。依微軟官方 Bug Check 0xEF 文件的說明,當這些程序的狀態毀損或損壞時,由於它們對 Windows 運作至關重要,作業系統會判定自身完整性已有疑慮,於是觸發 bug check。實務上把兇手攤開來看,大致是這幾類:

驅動程式問題(最常見):不相容、過舊、或剛更新壞掉的驅動,間接把某個系統程序的記憶體或控制碼搞爛。顯示卡、儲存控制器、網卡驅動都是常客。
系統檔損壞:Windows 系統檔或元件存放區(component store)被改壞、更新到一半斷電、或被第三方工具動過,導致關鍵程序載入時就出事。
磁碟或檔案系統毀損:硬碟壞軌、SSD 韌體問題、或檔案系統結構錯亂,讓 Windows 讀不到關鍵檔案。
Windows Update 失敗:更新裝到一半失敗、回滾不乾淨,是「更新後才開始藍屏」的頭號嫌疑。
惡意程式:病毒感染系統檔甚至主開機記錄(MBR),破壞磁碟結構後連帶生出各種 bug check。
硬體與相容性:新加的硬體不相容、記憶體出錯、或 BIOS/韌體過舊。

這也是為什麼下面的解法會「由軟到硬、由簡到繁」排列:先修最容易壞、最好修的系統檔與驅動,真的都排除了才往磁碟與硬體查。

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

這一段是本文對一般教學部落格的降維打擊區,也是你之後自己看 dump 的基礎。

Windows 把一小群 user-mode 程序標記為「critical(關鍵)」。這些程序一旦非正常結束,核心不會像對待一般程式那樣「幫你重開就好」,而是直接讓整台機器 bug check。依微軟官方文件,內建的關鍵系統服務包含 csrss.exe、wininit.exe、logonui.exe、smss.exe、services.exe、conhost.exe、winlogon.exe。這也是為什麼這個藍屏叫「CRITICAL_PROCESS_DIED」——不是隨便一個程式掛了,是「不准掛的那幾個」掛了。

真正拆案的鑰匙,是這個 Bug Check 的四個參數。依微軟 Bug Check 0xEF 官方定義:

參數	意義
1	出事的處理程序物件(process object)
2	若為 0,是「處理程序」終止;若為 1,是「執行緒(thread)」終止
3	保留
4	保留

Parameter 2 是你第一個要看的東西:它告訴你死的是整個 process 還是某條 thread,這會決定你在 WinDbg 裡要用 !process 還是 !thread 往下追。Parameter 1 則是那個 process 物件的位址,拿它去 !process 就能看到到底是哪個程序、被誰動到。

還有一個實務上很關鍵、但很多文章沒講的點:官方文件明說,很多情況下在系統 bug check 之前,會先產生一份 user dump。也就是說,真正的根因往往藏在那份使用者模式的 dump 裡,而不是藍屏那一刻的核心 dump——從核心 dump 反推 user-mode 程式碼有先天限制(資料可能被換出或缺失)。所以進階排查時,user dump 要先看。想從 minidump 一路 !analyze -v 追到兇手模組的完整手法,可以搭配這篇 WinDbg 藍畫面 minidump 分析教學一起服用。

🛠️ 解決方案

⚠️ 動手前先讀:下面從安全、可逆的方法開始排,越後面越接近「終極手段」。做任何系統層修復前,先確保重要資料已備份;若你的裝置有啟用 BitLocker,請先確認手上有 Recovery Key 再進 WinRE。
🛑 停止條件(符合任一,請先停手找專業協助):不確定機器型號或 Windows 版本、尚未完成資料備份、BitLocker 已啟用但找不到 Recovery Key、公司或學校控管的設備而你沒有 IT 授權、指令輸出與本文預期明顯不符。

方法一:先進安全模式(進不了桌面才需要)

如果你根本開不進 Windows,連續兩三次在開機時強制關機,第三次通常會自動進入「自動修復」,再走 疑難排解 → 進階選項 → 啟動設定 → 重新啟動,開機後按 4 或 5 進入安全模式。安全模式只載入最小驅動與服務,能繞過害你藍屏的那支驅動,讓你有機會做後面的修復。

如果你還進得了桌面,直接跳方法二即可。

方法二:SFC 修系統檔(成功率最高的第一刀)

用「系統管理員」開命令提示字元,先跑 SFC。它會掃描並修復損壞的 Windows 系統檔:

SFC /scannow

跑完如果顯示「找到並修復了損毀的檔案」,重開機看是否還藍屏。要注意的是,SFC 是拿元件存放區(component store)裡的好檔去補;如果連元件存放區本身都壞了,SFC 會修不動——這時要換方法三的 DISM 先把倉庫修好。

方法三:DISM 修好系統映像(SFC 修不動時)

SFC 是「拿好料補破洞」,DISM 則是「先把料庫本身修好」。依微軟官方,快速檢查用 sfc /scannow,要修元件存放區的問題就得動用 DISM。順序這樣跑:

DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /CheckHealth
DISM /Online /Cleanup-Image /RestoreHealth

ScanHealth 掃描是否毀損、CheckHealth 回報映像是「健康 / 可修復 / 無法修復」,RestoreHealth 才真正動手修(預設會連 Windows Update 抓好檔補回來,所以需要網路)。DISM 跑完,再回頭跑一次 SFC /scannow,讓 SFC 用修好的倉庫把系統檔補齊,這是官方推薦的黃金組合。

方法四:還原 / 更新問題驅動

如果藍屏是「最近更新驅動或裝新硬體後」才開始,兇手八成是驅動。到裝置管理員(Win + X → 裝置管理員)裡,找有沒有打驚嘆號(!)的裝置,對它按右鍵看內容裡的事件記錄,揪出出錯的驅動,然後選擇更新或「回復驅動程式」。剛裝的新硬體,也可以先移除或換掉測試。

方法五:chkdsk 檢查磁碟

軟體層都排除了,就往磁碟查。用系統管理員命令提示字元跑:

chkdsk /f /r

/f 修正檔案系統錯誤、/r 定位壞軌並救回可讀資料。若目標是系統碟(通常是 C:),它會提示要在下次重開機時執行,輸入 Y 後重開機即可。這一步對「SSD 或硬碟快掛」引起的 0xEF 特別有效。

方法六:啟動修復 / 系統還原 / 重設(終極手段)

前面都無效時,依序考慮:啟動修復(WinRE → 疑難排解 → 進階選項 → 啟動修復,自動修復開機關鍵檔與開機設定)→ 系統還原(還原到藍屏發生前的還原點)→ 最後才是重設此電腦(可選擇「保留我的檔案」,重裝 Windows 但留下個人資料)。重設前務必再備份一次重要資料。

想看各停止代碼的通用除錯心法與 WinDbg 全流程,可參考站長的藍白當機 BSOD 除錯總攻略,本文則是 0xEF 的專篇。

✅ 驗證修復結果

修完別急著說解決了,「暫時不當」不等於「修好」。建議這樣確認:

重開機後正常使用一段時間,特別是重現當初會觸發藍屏的操作(玩遊戲、跑某程式、插某裝置),看是否還跳。
開事件檢視器(Win + X → 事件檢視器 → Windows 記錄 → 系統),看藍屏時間點附近是否還有紅色「錯誤」等級事件;修好後這類錯誤應該不再新增。
再跑一次 SFC /scannow,確認顯示「未發現任何完整性違規」。
若你有留 minidump,可用 WinDbg 對照新舊 dump 是否還指向同一支模組。

🔙 萬一翻車:回退步驟

情境一:修完更不穩、或某功能壞掉

多半是驅動更新或系統還原造成。回裝置管理員用「回復驅動程式」退回上一版;或用系統還原還原到你動手前的還原點。

情境二:重開機後進不了系統

連續強制關機兩三次觸發自動修復,進 WinRE → 疑難排解 → 進階選項,先試「啟動修復」,再試「系統還原」。這也是為什麼動手前要先確認 BitLocker Recovery Key 在手。

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

用另一台電腦製作 Windows 安裝 USB,開機進入修復環境跑 chkdsk、SFC /offbootdir、DISM 離線修復;真的救不回再考慮重灌,並把資料碟先接到別台機器備份出來。

💡 總結:預防再次發生

站長我把這個停止代碼的心法濃縮成一句:CRITICAL_PROCESS_DIED 是「果」不是「因」。畫面上寫的是「關鍵程序死了」,但真正該問的是「誰把它搞死的」——而答案幾乎不在那個程序本身,而在驅動、系統檔或磁碟。所以修它的正確姿勢,是照「軟體 → 驅動 → 磁碟 → 硬體」的順序收斂,而不是一看到藍屏就重灌。

要說預防,老實講就三件事最實在:驅動別亂更新也別放到過舊(尤其顯示卡與儲存控制器,認準官方或裝置管理員來源)、系統碟定期留意 SMART 健康度與剩餘空間、Windows Update 讓它裝完整、別在更新途中硬關機。做到這三點,0xEF 找上你的機率會低很多。

最後補一個誠實提醒:本文的指令、參數與關鍵程序清單,都對回微軟官方 Bug Check 0xEF 與 DISM/SFC 官方文件(見文末來源),屬於官方與方法論層級的整理;文中不含站長在特定機器上的實測數據——若你要引用「某驅動在某 build 上實測會觸發 0xEF」這類具體數字,請以你自己的 dump 與環境為準。

❓ 常見問題

Q:CRITICAL_PROCESS_DIED 一定要重灌嗎?

多數不用。依本文由簡到繁的順序(SFC → DISM → 驅動 → chkdsk → 啟動修復 / 系統還原)處理,大部分案例在重灌之前就能解決;「重設此電腦」與重灌是最後手段。

Q:0xEF 和 0x000000EF 是同一個嗎?

是。0xEF 是簡寫,0x000000EF 是完整的 Bug Check 代碼,兩者指的都是 CRITICAL_PROCESS_DIED,同一個停止代碼。

Q:藍屏一直迴圈、連安全模式都進不去怎麼辦?

連續強制關機兩三次觸發「自動修復」,走 WinRE 的「啟動修復」;若還是不行,用 Windows 安裝 USB 進修復環境做離線的 chkdsk 與 DISM 修復。

Q:怎麼知道到底是哪個程序或驅動害的?

看 minidump。用 Parameter 2 判斷是 process 還是 thread,再用 WinDbg 的 !analyze -v、!process / !thread 往下追;搭配事件檢視器裡藍屏同時段的錯誤事件一起看最準。

🔗 延伸閱讀

📎 參考資料來源

📖 第一級|廠商官方:

Bug Check 0xEF: CRITICAL_PROCESS_DIED – Microsoft Learn — 2026-07-03 查證
Repair a Windows Image(DISM /RestoreHealth 官方語法)- Microsoft Learn — 2026-07-03 查證
Use the System File Checker tool to repair missing or corrupted system files – Microsoft Support — 2026-07-03 查證

📖 第二級|權威技術媒體(causes / 修復流程交叉比對):

How to fix “critical process died” in Windows – Atera — 2026-07-03 查證

⚠️ 本文核心事實(停止代碼定義、關鍵程序清單、參數意義、DISM/SFC 語法)以第一級官方為準,第二級僅作常見成因與修復順序之補充。

📅 本文查證戳記:2026-07-03 依據 Windows 11(24H2 / 25H2)與微軟官方 Bug Check 0xEF 文件撰寫。若你在後續版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。