MACHINE_CHECK_EXCEPTION(0x9C)藍屏排錯:讀懂 Bank 編號,先確認它該不該是 0x124

⚡ 站長快讀:核心重點

• 文章屬性:疑難排除(A5 底層除錯)
• 適用系統:Windows 10 / Windows 11
• 難易度 / 耗時:⭐⭐⭐ / 約 40 分鐘
• 核心結論:官方明訂 Vista 後這個碼已由 0x124 取代,只剩兩種情境會跳 0x9C;先確認為何不是 0x124。
• 適用對象:藍屏出現 MACHINE_CHECK_EXCEPTION 或停止碼 0x0000009C 的人。

📌 快速答案

一句話答案:MACHINE_CHECK_EXCEPTION 0x9C 代表 CPU 的機器檢查機制回報了致命錯誤,先讀參數 1 的 Bank 編號鎖定出錯的硬體單元,再從散熱、超頻與記憶體三處回推。

🧰 開始前的準備

• 適用系統:Windows 10 / Windows 11 全版本(Microsoft 官方 Bug Check 0x9C 文件未限定版本)
• 權限需求:系統管理員(讀取傾印檔、開事件檢視器、進 BIOS/UEFI 都需要)
• 需要工具:WinDbg(Debugging Tools for Windows)、事件檢視器(內建)、Windows 記憶體診斷 mdsched.exe(內建)、主機板或整機原廠提供的硬體診斷與韌體更新工具
• 預計耗時:基本排查約 40 分鐘;要開 WinDbg 讀傾印再加 40 分鐘

⚠️ 執行前先做三件事:①重要資料先備份到外接裝置或雲端——本文判定的是硬體層錯誤,硬體隨時可能再次當機甚至完全開不了機;②確認手上有可開機的救援 USB;③先建立系統還原點(開始搜尋「建立還原點」),本文後半段會動到 BIOS/UEFI 設定與驅動程式。

🛑 停止條件(符合任一,請先停下):不確定主機板型號或目前 BIOS 版本、尚未完成資料備份、已啟用 BitLocker 但手邊沒有復原金鑰、公司或學校管控設備而未取得 IT 授權、機器仍在保固內且你打算之後送修(自行刷韌體可能影響保固認定)、指令或工具輸出與本文描述明顯不符。

🔍 症狀描述與錯誤訊息

0x9C 的現場通常很沒有預兆:機器在跑遊戲、轉檔、編譯這類「CPU 吃滿」的工作時突然停住,或是待機時毫無理由地重開。畫面上留下的字樣是下面這幾種之一:

MACHINE_CHECK_EXCEPTION

STOP: 0x0000009C

你的裝置發生問題,需要重新啟動。(停止碼:MACHINE_CHECK_EXCEPTION)

Microsoft 官方對這個碼的定義只有一句話:MACHINE_CHECK_EXCEPTION 這個 bug check 的值是 0x0000009C,表示「發生了一次致命的機器檢查例外(fatal machine check exception)」。

和多數藍屏不同的是,0x9C 不一定會留下有用的傾印。這一句是本文從官方文件 Remarks 所載的發生條件推導出來的結論(官方原文並未直接談傾印品質),而它會決定你整個排查方向——我們馬上就會拆它。

另外一個常被忽略的訊號:很多人的機器根本沒藍屏,只是在你完全沒操作的情況下直接斷電重開,事後在事件檢視器的「系統」日誌裡看到 Microsoft-Windows-WHEA-Logger 記下的致命硬體錯誤。請先看那筆事件的錯誤來源型別:若是機器檢查例外(Machine Check Exception),那就是同一條產線上的訊號,只是這次還來得及寫進事件日誌,本文的排查路線同樣適用;WHEA 也會記 NMI、PCI Express 不可修正錯誤等其他來源的硬體錯誤,那些不屬於本文範圍。

🔎 問題根因

先給結論:0x9C 不是 Windows 出錯,是 CPU 舉手說「我這裡壞了」。 但真正決定你該往哪查的,不是這個名字,是它的四個參數——而且參數表有兩張,你得先知道自己在看哪一張。

差異化重點一:參數 1 是 Bank 編號,不是例外碼

大多數藍屏(0x8E、0x1E、0x50…)的參數 1 是「例外碼」或「被存取的位址」。0x9C 不是。 依 Microsoft 官方文件,現代機器上的四個參數是這樣:

官方明訂,這張表適用於「具備 MCA 與 MCE 功能的較新 x86 處理器(例如 Intel family 6 以上,如 Pentium Pro、Pentium IV、Xeon),或 x64 處理器」——也就是現在市面上所有機器。

還有另一張表,適用「具備 MCE 但沒有 MCA 功能的舊 x86 架構(例如 Intel Pentium)」,四個參數分別是 P5_MC_TYPE MSR 的低 32 位元、MCA_EXCEPTION 結構位址、P5_MC_ADDR MSR 的高 32 位元與低 32 位元。這張表你幾乎不會用到,列出來是為了讓你在網路上撞見「參數 1 是 MC_TYPE」的舊文章時,知道那是二十幾年前的機器。

用得到的只有一句:參數 1 是 Bank 編號。 Bank 是 CPU 內部按硬體單元劃分的錯誤回報暫存器組——每一組對應一個(或一群)硬體單元,例如某層快取、記憶體控制器、匯流排介面。知道是哪一個 Bank,方向就從「整台電腦」縮到「CPU 的某個區塊」。

差異化重點二:它跟 0x124 的關係,決定你要不要繼續往下查

這是全篇最值錢的一段,而且是官方明文、不是站長推論。Microsoft 在 0x9C 文件的 Remarks 段寫著:

這個 bug check 只在下列情況發生:

– WHEA 尚未完全初始化。

– 所有進行 rendezvous 的處理器,其暫存器中都沒有錯誤。

在其他情況下,這個 bug check 在 Windows Vista 及後續作業系統中,已由 Bug Check 0x124: WHEA_UNCORRECTABLE_ERROR 取代。

反過來在 0x124 的官方文件裡也對得上:「這個 bug check 在 Windows Vista 之前的版本不支援;在那之前,機器檢查例外是透過 bug check 0x9C 回報。」

兩份官方文件互相印證,結論很硬:在 Windows 10 / 11 上,正常情況下的機器檢查例外應該跳 0x124,不是 0x9C。 所以你手上這台跳 0x9C 的機器,大概率落在這兩格之一:

• 情況 A:錯誤發生得太早,WHEA 還沒初始化完。 由這個條件可以直接推得的典型場景是開機極早期就當、剛按下電源沒幾秒就重開。(另外「BIOS/UEFI 設定變動後才開始出現」是站長的經驗性觀察,與 WHEA 是否初始化完成沒有邏輯關聯,不是官方判準,只是實務上值得一問的線索。)
• 情況 B:所有 rendezvous 的處理器暫存器裡都沒有錯誤。 白話說:核心知道「發生了機器檢查」,但去問每一顆核心「是你嗎」,結果沒有一顆的 MCA bank 留下有效紀錄。

情況 B 有個很實際的推論,而且是本文與網路上多數 0x9C 教學最不一樣的地方:這種 0x9C 的傾印檔裡,可能根本沒有可指認的兇手。 你把 dump 丟進 WinDbg、跑完 !analyze -v,得到的很可能是一份「知道是機器檢查、但講不出是哪個單元」的報告。這不是你分析錯了,是這個 bug check 的定義本來就是這樣。

這一點直接改變排查策略:0x9C 的主戰場在硬體與韌體端,不在傾印分析端。 傾印該讀,但它是配菜。

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

要理解為什麼會有 0x9C 與 0x124 兩個碼,得看訊號在硬體與作業系統之間怎麼傳。

第一段:CPU 的機器檢查架構(MCA)

現代 x86/x64 處理器內建一套機器檢查架構(Machine Check Architecture,MCA):CPU 在執行過程中若偵測到自己內部或周邊發生硬體錯誤(快取同位錯誤、匯流排錯誤、記憶體控制器回報的不可修正錯誤等),會把錯誤資訊寫進對應 Bank 的 MCi_STATUS 這組 MSR(Model-Specific Register),必要時再觸發機器檢查例外(Machine Check Exception,MCE)打斷系統。

MCi_STATUS 的高位元帶有一組狀態旗標,用來表達「這筆紀錄有沒有效」「是否為不可修正錯誤」「是否被後來的錯誤覆蓋」「處理器狀態還可不可信」等資訊。完整的位元定義在 Intel 官方《Intel® 64 and IA-32 Architectures Software Developer’s Manual》第 3 卷的 Machine-Check Architecture 章節,AMD 的處理器程式設計手冊也有對應章節。Microsoft 的 0x9C 文件末尾也直接把讀者導到這兩家:「關於 MCA 的更多資訊,請參閱 Intel 或 AMD 網站。」

但實務上你不需要自己拆位元。 下面會示範的 WinDbg !errrec 指令會把這串數字解析成人看得懂的句子——這才是本文建議的做法,自己查表對位元既慢又容易錯。

第二段:Windows 這一端的 WHEA

Windows 從 Vista 起導入 Windows Hardware Error Architecture(WHEA),把「硬體錯誤回報與復原」做成一套完整架構。當硬體錯誤發生時,WHEA 會建立一筆錯誤紀錄(error record)保存錯誤資訊;核心把這筆紀錄夾在 ETW 硬體錯誤事件裡送出,於是它會被寫進系統事件日誌。這些錯誤紀錄的格式,依據的是 UEFI 規格 2.2 版附錄 N 所定義的 Common Platform Error Record。

於是整條訊號鏈長這樣:

硬體單元出錯 → CPU 寫入 MCA bank → 觸發 MCE → WHEA 接手建立錯誤紀錄 → 核心停機並產生 bug check

關鍵就在「WHEA 接手」這一格。 WHEA 接得到、而且處理器暫存器裡有東西可讀,就走 0x124(帶著完整的 WHEA_ERROR_RECORD);WHEA 還沒初始化好、或所有核心的暫存器都是空的,就落回 0x9C。這就是官方那兩句 Remarks 的機制解釋——0x9C 現在的角色,實質上是 WHEA 路線的「兜底出口」。

理解這件事,你就會知道:去追「0x9C 的參數 2 指向的 MCA_EXCEPTION 結構」常常是死路,因為情況 B 的前提就是暫存器裡沒有錯誤。時間應該花在事件日誌與硬體端。

兩個碼的官方定義差異,整理成一張對照圖:

四列的重點:①0x9C 是 Vista 之前就有的老碼,0x124 才是 Vista 起的新出口;②現代 Windows 上 0x9C 只在兩種情況出現;③兩者的參數 1 語意完全不同,不能互套;④參數 2 指向的結構也不同,0x124 那份才是資訊完整的 WHEA 錯誤紀錄。

🛠️ 解決方案

⚠️ 高風險段落警語:本節後半涉及 BIOS/UEFI 設定變更與韌體更新。動之前務必完成:①資料備份 ②記下目前的 BIOS 版本號與你改動前的每一項設定 ③確認電源穩定(桌機建議接 UPS,筆電請接電源並保持電量 50% 以上)。韌體更新中途斷電可能導致主機板無法開機,且不是所有主機板都能靠清 CMOS 救回來。若無法滿足上述任一條件,請停在方法二,並直接聯絡原廠或送修。

方法一:先讀畫面與事件日誌,把範圍縮小(必做,零風險)

先給結論:這一步的目標不是修好,是決定後面三步要走哪一條。

1. 抄下四個參數。 藍屏畫面若有顯示 STOP: 0x0000009C (參數1, 參數2, 參數3, 參數4),把四個數字抄下來。參數 1 就是 Bank 編號。

2. 開事件檢視器看 WHEA 紀錄。 按 Win + R 輸入 eventvwr.msc(或直接在工作列搜尋「事件檢視器」)→「Windows 記錄」→「系統」,在右側點「篩選目前的記錄檔」,事件來源選 Microsoft-Windows-WHEA-Logger(這正是 Microsoft 官方指定用來記錄硬體錯誤事件的提供者名稱,紀錄就放在系統記錄檔)。也可以用 PowerShell 直接撈(純查詢,不會改動任何設定):

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'} -MaxEvents 20 | Format-List TimeCreated, Id, LevelDisplayName, Message

看三件事:這些事件是不是集中在某個時段?是不是都在高負載時發生?訊息裡有沒有點名處理器編號或裝置?

3. 確認當機當下在做什麼。 0x9C 這類硬體錯誤高度依賴觸發條件。「只有玩遊戲會當」「只有轉檔會當」「開機十分鐘內必當」「待機一整晚回來發現重開了」——這四種指向完全不同的方向(散熱、供電、韌體初始化、電源管理)。這條資訊比傾印檔還值錢。

4. 把系統更新與韌體版本補齊。 Microsoft 官方的停止碼排查通則第 2 與第 3 步就是「確認已安裝最新的 Windows 更新、累積更新與彙總更新」與「確認 BIOS 與韌體是最新的」。先做前者(零風險),後者留到方法四。

方法二:硬體層三件事——散熱、超頻、記憶體(零風險到低風險)

先給結論:官方對機器檢查例外的處置建議,核心就是這三件事。

Microsoft 在 0x124 文件的成因段落寫得很直白:「這個 bug check 通常與實體硬體故障有關。它可能與過熱有關,或是硬體、記憶體有瑕疵,甚至是處理器開始故障或已經故障所致。如果已啟用超頻,請試著關閉。確認風扇等散熱系統運作正常。執行系統診斷以確認系統記憶體沒有瑕疵。比較不可能但仍有可能,是某個驅動程式導致硬體以此 bug check 失敗。」

⚠️ 這裡要老實說一句:上面這段是 0x124 的官方成因段,0x9C 的官方文件本身沒有成因或處置段落(它只有兩張參數表與 Remarks)。本文之所以拿它來用,依據是官方自己寫的「其他情況下 0x9C 已由 0x124 取代」——同一個機器檢查例外、同一套硬體來源,故硬體排查方向可以共用;但這一步是本文的推定,不是官方明文說「兩碼成因相同」。

照這段話拆成可執行的三步:

① 關掉所有超頻與記憶體超頻設定。 進 BIOS/UEFI,把 CPU 倍頻、電壓、Ring/Uncore、以及記憶體的 XMP / EXPO / DOCP 全部回到預設值(通常是「Load Optimized Defaults」或把 XMP 從 Profile 1 切回 Disabled)。

📌 這一步最常被跳過,也最常是答案。 XMP/EXPO 本質上是「記憶體以高於 JEDEC 標準的參數運行」,它在規格上就是一種原廠允許的超頻。記憶體控制器在 CPU 裡面,吃不消時回報的正是機器檢查錯誤。先關掉跑一天,是成本最低的分流實驗。

🔙 這一步的回退很單純:回 BIOS 把 XMP/EXPO 切回原本的 Profile 即可,不涉及韌體寫入。

② 檢查散熱。 確認 CPU 風扇/水冷幫浦實際在轉、機殼進出風沒被擋住、散熱器與 CPU 之間的散熱膏沒有乾裂。若機器已使用三年以上且從未清過灰,先清灰再測。負載時的 CPU 溫度可用主機板廠附的監控軟體或原廠工具觀察。

③ 測記憶體。 官方的停止碼排查通則把「執行相關的硬體與記憶體測試」列為基本步驟之一。先跑 Windows 內建的記憶體診斷:按 Win + R,輸入 mdsched.exe,選「立即重新啟動並檢查問題」(介面字樣依 Windows 版本略有差異;另一個選項是排程到下次重開機時執行)。內建工具是初篩,通過不代表沒問題;要更嚴格的長時間測試,可以搭配第三方深驗工具。這兩者的定位差異與該怎麼選,站內另有一篇專門比較:MemTest86 vs Windows 記憶體診斷:內建初篩還是第三方深驗?。若手上有多條記憶體,單條輪替上機是最直接的分流法。

若三步做完問題消失,先別急著把超頻設定加回去——至少穩定運行一週再考慮,而且一次只加回一項。

方法三:讀傾印,但要知道它的邊界(中等難度,零風險)

先給結論:傾印能告訴你「是不是機器檢查」與「哪個 Bank」,但依照官方定義,0x9C 這條路上它有可能什麼都給不出來。

1. 先確認系統會產生傾印。 工作列搜尋「進階系統設定」→「進階」分頁→「啟動及修復」的「設定」→「寫入偵錯資訊」選 「自動記憶體傾印」→確定→重開機生效。傾印檔位置:小型傾印在 %SystemRoot%\Minidump,核心/完整/自動/主動傾印在 %SystemRoot%\MEMORY.DMP。

2. 裝 WinDbg 並設好符號路徑。 從 Windows SDK 安裝時勾選 Debugging Tools for Windows。開啟 WinDbg 後,File →「Symbol File Path」填入 Microsoft 公用符號伺服器:

https://msdl.microsoft.com/download/symbols

3. 開傾印跑三個指令。

!analyze -v

先看 !analyze -v 的 Bugcheck Analysis 區塊確認碼與四個參數。接著,如果這次的錯誤有留下 WHEA 錯誤紀錄,可以用 !whea 取得錯誤來源表與錯誤紀錄位址:

!whea

拿到紀錄位址之後,用 !errrec 把它解析成可讀內容:

!errrec <錯誤紀錄位址>

!errrec 是這一整條路線上最值得學的一個指令。它會輸出一份 Common Platform Error Record,包含 Severity(嚴重性)、Notify Type(通知型別,機器檢查例外會顯示 Machine Check Exception)、以及最關鍵的 Error Packet 區段——裡面有 ErrorType(例如 0x0 - Processor)、ErrorSourceType(例如 0x0 - MCE)、RawDataFormat(例如 0x2 - Intel64 MCA),還有 Processor Number 與 Bank Number。

官方文件裡的示範輸出,甚至直接把結論寫成白話給你看:

Processor Error: (Internal processor error)

這個錯誤代表處理器已損壞,或者可能是電壓與/或溫度已超出門檻。若問題持續發生,請更換處理器。

(原文為 either the processor is damaged or perhaps voltage and/or temperature thresholds have been exceeded,perhaps 的推測語氣照譯保留。)

這句話就是 0x9C/0x124 這條線最終的診斷語言:處理器本身,或是餵給它的電壓與溫度。 注意 !errrec 與 !whea 都只在 Windows Vista 以後可用。

4. 讀不到東西也是一種結果。 如果 !analyze -v 只給你「MACHINE_CHECK_EXCEPTION」而說不出模組,!whea 也撈不到有效紀錄——回頭看情況 B 的定義:這正是 0x9C 該有的樣子,不是你操作失誤。把時間還給方法二與方法四。

想把 WinDbg 的傾印分析流程從頭學一次,站內有一篇以 0x124 為主角的實戰教學可以直接對照著做:BSOD 出現 WHEA_UNCORRECTABLE_ERROR?用 WinDbg 實戰分析。

方法四:韌體與驅動(⭐⭐⭐ 高風險,最後才動)

先給結論:韌體更新是官方通則裡的正式步驟,但它是本文唯一有可能把機器變成磚頭的一步,擺在最後。

① BIOS/UEFI 韌體更新。 Microsoft 的停止碼排查通則明列「確認 BIOS 與韌體是最新的」。做法上,本文只給原則,不給指令:

• 一律使用主機板或整機原廠提供的官方更新工具與官方檔案,依原廠說明書操作。不要用第三方刷寫工具、不要用來路不明的 ROM 檔。
• 更新前先在原廠頁面確認你的主機板型號與目前 BIOS 版本,並讀過版本說明——有些更新有「不可跳版」或「不可降版」限制。
• 更新前記下目前所有自訂設定(BIOS 更新通常會把設定清回預設),更新後再逐項設回去。
• 筆電、品牌桌機、公司配發機器:直接走原廠的驅動與更新程式,不要自己找 ROM。

② 檢查驅動程式。 0x124 官方文件的成因段寫著「比較不可能但仍有可能,是某個驅動程式導致硬體以此 bug check 失敗」(0x9C 官方文件無此段,套用為本文推定,同上)——機率低,但不是零。若方法一到三都沒收斂,可以用 Driver Verifier 對「最近更新過」或「已知有問題」的驅動做壓力驗證。

Driver Verifier 的官方使用守則值得原文照收:它會大量消耗 CPU 並明顯拖慢電腦、可能造成額外當機;不要一次驗證所有驅動,那會讓系統無法使用並降低工具效果;建議每次驗證 10–20 個驅動;若因為 Driver Verifier 而無法進入桌面,可以進安全模式停用它,因為該工具在安全模式下不會運行。

啟用(以系統管理員身分開啟命令提示字元):

verifier /standard /driver 目標驅動名稱.sys

停用(這一行請先抄下來再啟用):

verifier /reset

執行 verifier /reset 後需重新啟動才會生效。Driver Verifier 標記出問題驅動之後,回頭到裝置管理員看那個裝置目前掛的錯誤碼,常常能佐證是同一件事——站內有一篇把這些錯誤碼逐個拆開的整理可以直接對:裝置管理員錯誤碼完整解析:Code 10、28、31、43 分別代表什麼?。

③ 都做完還是當,而且 !errrec 指向處理器本身。 這時候的合理結論就是官方那句話——處理器可能已損壞。送修或 RMA 前,先把下列資料整理好:當機時間點清單、事件檢視器的 WHEA 事件匯出檔、傾印檔、你做過的每一項排查與結果、BIOS 版本與是否曾超頻。原廠客服看得懂這些,能省掉一輪「請您先重灌」的來回。

✅ 驗證修復結果

硬體類問題最麻煩的地方是「今天沒當」不等於「修好了」。建議用下面三層依序確認:

1. 事件日誌歸零:重新跑一次方法一的 PowerShell 查詢,確認改動之後的時間區間內沒有新的 Microsoft-Windows-WHEA-Logger 錯誤事件。這是最客觀的一層——它比「我用起來很順」可靠得多。
2. 重現原本的觸發條件:原本是玩遊戲當,就把同一款遊戲跑同樣長度;原本是轉檔當,就轉同一批檔案。用原本會當的情境去測,不要用文書作業去測。
3. 連續觀察 7 天:硬體的間歇性故障常常是「三天沒事、第四天當一次」。七天內零 WHEA 事件、零非預期重開,才算收斂。

若你在方法二關掉 XMP/EXPO 後問題消失,加回去時以「一次只改一項、每項觀察 3 天」為節奏;哪一項加回去後 WHEA 事件重新出現,那一項就是原因。

🔙 萬一翻車:回退步驟

⚠️ 老實說:BIOS 刷寫失敗導致的無法開機,在不具備 Flashback 或雙 BIOS 的主機板上,清 CMOS 通常救不回來,可能需要更換主機板或送原廠處理。任何寫著「重開機或清 CMOS 就能恢復」的說法,對這一項並不成立。本段為站長依實務經驗所寫的風險提醒,無單一官方文件可引;你那張主機板到底有沒有救援機制、怎麼用,一律以原廠說明書為準。

💡 總結:預防再次發生

站長我這幾年處理過的硬體型當機,最常見的誤診不是「查錯零件」,是「拿軟體工具去查硬體問題」——傾印讀了三輪、Driver Verifier 開了一星期,最後發現是記憶體開了 XMP 撐不住。0x9C 這個碼特別容易掉進這個陷阱,因為它長得跟其他藍屏一模一樣,但官方文件已經把話講在前面:在現代 Windows 上,它出現的前提之一就是「暫存器裡沒有錯誤可讀」。

依照這個底層邏輯,三件事最值得養成習慣:

第一,把 XMP/EXPO 當成超頻看待。 它是原廠允許的超頻,不是預設值。組機或換記憶體之後,先在預設參數下跑穩一週再開,問題會少一半。

第二,把 WHEA 事件當成健檢報告定期看。 很多硬體故障在真正藍屏之前,會先在事件日誌裡留下數週的「可修正錯誤」紀錄。每個月花兩分鐘跑一次方法一那行 PowerShell,遠比出事後讀傾印有效。

第三,溫度與供電先於零件更換。 官方在同一句話裡把「處理器已損壞」與「電壓與/或溫度已超出門檻」並列為兩種可能——既然是兩種可能,就先做便宜的那一種:清灰、換散熱膏,成本遠低於換 CPU,值得先排除。(補一句:官方那句的「電壓」指的是處理器的電壓門檻,常見於超壓與超頻情境;「順便檢查電源供應器的瓦數與年限」是站長的延伸建議,不在官方原句範圍內。)

最後提醒:0x9C、0x2E、0x124 看起來都指向硬體,但訊號來源與可用線索完全不同,別把處置方式互相套用。

❓ 常見問題

Q:出現 0x9C 是不是代表 CPU 一定壞了?

不一定,而且多數時候不是。0x124 官方文件的成因段列的是一串:過熱、硬體或記憶體瑕疵、處理器開始故障或已故障、超頻,以及機率較低的驅動程式(0x9C 自己的官方文件沒有成因段,本文依「0x9C 已由 0x124 取代」推定同樣適用)。「處理器已損壞」只是其中一種可能,而且要靠 !errrec 的輸出或排除法才能收斂。 在關掉超頻、清完灰、測完記憶體之前,不要下這個結論。

Q:CPU、記憶體、主機板,哪一個最可能有問題?

先講順序,再講機率。 依 0x124 官方文件的成因段,列出來的是過熱、硬體或記憶體瑕疵、處理器故障、超頻,官方並沒有給任何一種元件的機率排名,所以誰「最可能」沒有官方答案——但排查順序有,而且順序比機率有用:

三點重點:①先動便宜、可逆的那一項,不要一開始就換 CPU;②參數 1 的 Bank 編號能把範圍縮到 CPU 的某個區塊,但它指的是「誰回報」不是「誰壞掉」;③主機板與 CPU 在家很難分開判定,這正是要把排查紀錄整理好、交給原廠的原因。

Q:0x9C 和 0x124 到底差在哪?我應該看哪一篇資料?

依 Microsoft 官方文件,兩者都是機器檢查例外的出口,但 Windows Vista 以後,絕大多數情況會走 0x124;0x9C 只在「WHEA 尚未完全初始化」或「所有 rendezvous 的處理器暫存器中都沒有錯誤」這兩種情況出現。官方明文只寫到「取代」為止,沒有說兩碼成因相同;本文方法二所引的成因段出自 0x124 官方文件,把它套用到 0x9C 的硬體排查上是本文的推定。至於傾印分析,兩者的可得線索確實不同——0x124 有完整的 WHEA_ERROR_RECORD 可以拆,0x9C 依其發生條件常常沒有。

Q:超頻造成的機率高嗎?

0x124 官方文件的成因段把「如果已啟用超頻,請試著關閉」列為第一個具體動作,可見它的優先順位(0x9C 官方文件無成因段,套用為本文推定)。站長的實務建議是把它當第一個要排除的變因,理由是成本最低、回退最單純(改個 BIOS 選項),而且記憶體 XMP/EXPO 這種很多人不認為是超頻的設定也算在內。

Q:RMA 前該做哪些檢測?

至少四項:①關閉所有超頻(含 XMP/EXPO)後仍重現;②記憶體診斷結果(內建 + 長時間深驗);③事件檢視器的 WHEA 事件匯出檔;④傾印檔與 !analyze -v / !errrec 輸出。另外把「換過哪些零件、換了之後有沒有改善」寫成一張表——單條記憶體輪替、換過的電源供應器、清灰前後的溫度,這些是客服判斷該收哪個件的關鍵。

Q:我沒藍屏,只是電腦會自己重開,事件檢視器裡有 WHEA-Logger 錯誤,適用這篇嗎?

先看那筆事件的錯誤來源型別。 WHEA 記的是「硬體錯誤事件」這個大類,除了機器檢查例外之外,還包含 NMI、PCI Express 不可修正錯誤等其他來源。若是機器檢查例外,那就是同一套機制的訊號,只是這次系統還來得及把紀錄寫進事件日誌就重開了,方法一到方法四的排查順序完全一樣,而且你的處境比藍屏使用者好——你有可以直接查詢的事件紀錄。若是其他來源,請改查該來源對應的裝置。

Q:修完之後又復發怎麼辦?

先確認復發的觸發條件有沒有改變(以前只有玩遊戲當,現在待機也當=劣化中,優先送修)。若條件一樣,回到方法二把三件事重做一次,並把「單條記憶體輪替」做完;都做完仍復發、且 !errrec 指向處理器,就準備送修資料。不要在這個階段重灌系統——0x9C 是硬體層錯誤,重灌對它幾乎沒有幫助。

🔗 延伸閱讀

• DATA_BUS_ERROR 0x2E 藍屏排錯:讀懂四個參數,用實體位址找出真兇
• 電腦常當機/藍屏?用 Windows 內建「記憶體診斷」工具檢查 RAM 問題
• UNEXPECTED_KERNEL_MODE_TRAP(0x7F)藍屏排錯:讀懂第一參數的陷阱編號揪出真兇
• KERNEL_MODE_EXCEPTION_NOT_HANDLED(0x8E)藍屏排錯:參數 1 定路線、參數 2 鎖模組
• CRITICAL_STRUCTURE_CORRUPTION 0x109 藍屏怎麼修?讀懂 PatchGuard 與 Parameter 4

📎 參考資料來源

📖 第一級|廠商官方:

• Bug Check 0x9C: MACHINE_CHECK_EXCEPTION — Microsoft Learn — 2026-07-31 查證
• Bug Check 0x124: WHEA_UNCORRECTABLE_ERROR — Microsoft Learn — 2026-07-31 查證
• !errrec(WinDbg 擴充指令)— Microsoft Learn — 2026-07-31 查證
• Windows Hardware Error Architecture(WHEA)設計指南 — Microsoft Learn — 2026-07-31 查證
• 停止碼錯誤進階疑難排解 — Microsoft Learn — 2026-07-31 查證
• Intel® 64 and IA-32 Architectures Software Developer’s Manual(MCA 章節出處)— Intel — 2026-07-31 查證

⚠️ 本文核心事實以第一級為準。本文全篇未使用第二級來源。

📅 本文查證戳記:2026-07-31 依 Microsoft 官方 Bug Check 文件與 WHEA 設計指南撰寫。

若你在後續版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。