CLOCK_WATCHDOG_TIMEOUT(0x101)藍屏排錯教學

文章屬性:疑難排除
適用系統:Windows 10 / Windows 11(多核心處理器皆可能觸發,不限特定版本)
難易度 / 耗時:⭐⭐⭐ / 約 30–60 分鐘(含至少一次重開機驗證)
核心結論:CLOCK_WATCHDOG_TIMEOUT(0x101)代表某顆 CPU 核心逾時沒回應時脈中斷,九成案例出在超頻/XMP 不穩或驅動衝突,少數才是真硬體故障
適用對象:電腦跳出 0x101 藍屏、或事件檢視器出現 Bug Check 0x101、莫名重開機的人

📌 快速答案

一句話答案:CLOCK_WATCHDOG_TIMEOUT(0x101)是某顆 CPU 核心逾時未回應時脈中斷,常見於超頻/XMP 不穩、晶片組驅動過舊,少數是硬體故障。

🧰 開始前的準備

適用系統:Windows 10 21H2 以後、Windows 11(24H2、25H2 皆有案例),多核心/多執行緒處理器
權限需求:系統管理員(進 BIOS/UEFI 需重開機進韌體介面,不需登入 Windows)
需要工具:WinDbg(Microsoft Store 下載)、Windows 內建 Driver Verifier(verifier.exe)、Windows 記憶體診斷(mdsched.exe)、主機板/筆電廠 BIOS 更新工具
預計耗時:約 30–60 分鐘,若要跑 Driver Verifier 壓力測試或記憶體延伸測試,需額外留數小時

🔍 症狀描述與錯誤訊息

CLOCK_WATCHDOG_TIMEOUT 通常來得很突然:電腦可能正在玩遊戲、開著瀏覽器閒置,甚至什麼都沒做,畫面就直接跳出藍底白字的當機畫面,上面寫著:

Your PC ran into a problem and needs to restart.
CLOCK_WATCHDOG_TIMEOUT
Stop code: 0x00000101

有些人會發現重開機後卡在「正在準備 Windows」很久,或收集錯誤資訊的百分比長時間停在 0%——這是因為系統要把當機當下的核心快照寫進傾印檔,而故障的那顆核心可能連寫檔案都寫不順。事後打開事件檢視器(Event Viewer)查看「Windows 記錄檔 → 系統」,通常會看到來源為 BugCheck、事件識別碼 1001,內容包含 0x00000101 這組代碼。

這顆停止碼比較特別的地方是:它不像某些 BSOD 一裝新軟體就跳,反而常常「隨機」發生——可能連續三天沒事,某天又跳兩次,讓人抓不到規律。

🔎 問題根因

依照微軟官方 Bug Check 0x101 CLOCK_WATCHDOG_TIMEOUT 文件,這個 bugcheck 值為 0x00000101,代表在多處理器(含多核心)系統中,某顆次要處理器核心該收到的時脈中斷,在允許的時間內沒有收到。白話講:Windows 核心排程器每隔一段極短時間就會用時脈中斷「點名」每一顆邏輯核心,確認它還活著、還在正常處理事情;如果某顆核心連續好幾次都「點名不到」,系統就判定它可能當機或卡死了。

官方文件列出的四個參數(Parameter)分別是:

Parameter	意義
1	時脈中斷逾時間隔(以 nominal clock ticks 為單位)
2	固定為 0
3	無回應處理器的 PRCB(Processor Control Block,處理器控制區塊)位址
4	該顆當機核心的索引編號

Cause(官方原文結論):「指定的處理器沒有在處理中斷。這通常發生在該處理器無回應或陷入死結(deadlocked)時。」也就是說,0x101 不是「軟體邏輯錯誤」那種常見當機,而是系統偵測到某顆 CPU 核心從時間軸上『消失』了。

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

這段是 A5 類文章的靈魂,理解了以後看到 0x101 就不會只會複製貼上錯誤代碼去 Google。

Windows 是搶佔式多工(preemptive multitasking)的核心,在多核心系統上,每一顆邏輯處理器都要跟其他核心保持「同步感」——排程器才能公平分配工作、記憶體管理員才能安全地跨核心操作分頁表。這套同步機制仰賴時脈中斷(clock interrupt)規律地敲每一顆核心。

CLOCK_WATCHDOG_TIMEOUT 的角色,就是核心裡的一個「看門狗」:它盯著每顆處理器的 PRCB(處理器控制區塊,記錄這顆核心目前在做什麼、上一次回應是什麼時候),一旦發現某顆核心連續錯過時脈中斷的時限,看門狗就會觸發 nt!KeBugCheckEx,帶著 bugcheck code 0x101 與上面四個參數,把整台機器停下來。

為什麼要停下來、而不是把當掉的那顆核心關掉繼續跑?因為在 SMP(對稱多處理)架構下,一顆核心「失聯」代表它當下可能正抓著某把鎖(spinlock)不放,或是正在寫某塊共用記憶體寫到一半——強行忽略它,輕則資料損毀,重則整台機器陷入更難排查的詭異狀態。跟 DPC_WATCHDOG_VIOLATION 完整除錯常被搞混,但兩者機制不同:0x133 是「某個 DPC 常式在 DISPATCH_LEVEL 執行太久」——問題出在軟體層的某段程式碼賴著不走;0x101 則是「這顆核心連最基礎的時脈中斷都沒回應」,層級更底層,常見成因也更偏硬體/韌體/時脈穩定度,而非單純某支驅動的邏輯錯誤。

實務上,「核心失聯」最常見的成因有三類:

時脈本身不穩:超頻(CPU 或記憶體 XMP/EXPO)把核心或記憶體控制器操到超出穩定範圍,核心在高負載瞬間跟不上時脈,直接漏接中斷。
韌體/驅動搶佔了核心太久:過舊的晶片組驅動、顯示卡驅動,或某些系統管理中斷(SMI)常駐韌體常式,把 CPU 卡在不可搶佔的狀態太久。
硬體真的出問題:CPU 腳位接觸不良、主機板供電不穩、電源供應器(PSU)瞬間掉壓,或記憶體時序跑飛,都可能讓某顆核心短暫「斷訊」。

🛠️ 解決方案

⚠️ 動手前的安全提醒:本文步驟涉及 BIOS/UEFI 設定變更與 Driver Verifier 系統壓力測試,執行前請先:①筆電請接上電源,避免重開機過程中斷電;②動手前先拍照或記下目前 BIOS 內的自訂設定(尤其是超頻、XMP/EXPO 數值),萬一要復原才有依據;③桌機若需要重新確認 RAM/電源接線,不熟悉拆殼的人建議請有經驗的朋友或送修協助,不要在不確定的狀態下硬拆。

方法一:BIOS 重置為預設值 + 關閉 XMP/EXPO 超頻設定(成功率最高、優先做)

超頻(不管是自己手動調的,還是筆電/主機板廠商出貨就內建的「效能模式」設定檔)是 0x101 最常見的成因,建議第一步就從這裡下手:

重開機,依廠牌快速鍵進入 BIOS/UEFI(常見是開機時重複按 Del 或 F2,不同廠牌略有差異,螢幕開機畫面通常會提示按鍵)。
找到「Load Optimized Defaults」或「Load Setup Defaults」之類的選項,重置為原廠預設值。
個別確認記憶體 XMP / AMD EXPO / DOCP 是否已關閉——這類設定檔會把記憶體時脈與時序推到超出主機板保守範圍,是隱性超頻最常被忽略的一環。
若曾經手動調過 CPU 倍頻、電壓、Ring/Uncore 頻率,一併還原為 Auto 或原廠值。
儲存並離開(通常是 F10),讓系統正常開機,觀察一段時間是否還會跳 0x101。

若你有安裝 Intel Extreme Tuning Utility(Intel XTU)、AMD Ryzen Master、MSI Afterburner 這類超頻軟體,這些工具會在開機時把設定值重新寫回去、蓋掉你在 BIOS 做的還原,建議暫時解除安裝或至少關閉開機自動套用,才能確認 BIOS 端的重置有沒有生效。

方法二:更新晶片組與顯示卡驅動,用 Driver Verifier 揪出卡住核心的驅動(進階)

排除超頻因素後,下一步檢查驅動是否過舊或有相容性問題:

到主機板/筆電官網下載最新晶片組驅動(Chipset Driver)與顯示卡驅動,兩者都跟中斷處理、電源狀態切換高度相關。
若更新驅動後仍然發生,可以用 Windows 內建的 Driver Verifier 讓可疑驅動在更嚴格的條件下運作,提早暴露問題。

⚠️ Driver Verifier 警語:這個工具的設計目的就是「故意讓有問題的驅動更容易當機」,開啟後你的電腦短期內當機頻率可能不減反增,這是正常現象、不是它壞了。請先確認資料都已備份,並記住如何進安全模式關閉它(下方「萬一翻車」段落有寫),再開始測試。

開啟後正常使用電腦幾天,若 0x101 再度出現,這次的傾印檔通常會清楚指出是哪一支驅動把核心卡住了,再回官網更新或回報該廠商即可,詳細操作步驟可參考 Driver Verifier 完整使用教學。

方法三:硬體排查——記憶體、電源供應器、CPU 腳位(前兩招無效才做)

若重置 BIOS、關閉超頻、更新驅動都做過還是持續發生,才輪到懷疑硬體本身:

測記憶體:先用 Windows 內建的 Windows 記憶體診斷工具教學跑一次基本檢測;若想更徹底,可以進一步用 MemTest86 做長時間壓力測試。
檢查電源供應器(PSU)是否穩定:桌機用戶若 PSU 已使用多年、或功率邊緣,瞬間高負載時電壓下滑也可能讓核心「斷訊」,必要時可考慮更換較高瓦數或品質更穩定的供應器。
重新確認 CPU 與 RAM 是否確實入槽:少數案例純粹是安裝時沒有完全壓到定位,重新拔插一次(注意靜電防護)也可能解決問題。
以上皆正常仍反覆出現,且集中在特定核心編號(可從 minidump 的 Parameter 4 看出),就要考慮是 CPU 或主機板本身瑕疵,建議送回原廠或經銷商檢測,若仍在保固期優先走保固更換。

✅ 驗證修復結果

處理完任何一個方法後,不要只重開一次機就當作解決了——0x101 常常是「間歇性」發生,建議正常使用電腦至少一至兩週,期間留意:

可靠性監視器(工作列搜尋「可靠性」→「檢視可靠性歷程記錄」)有沒有新的當機事件。
事件檢視器 → Windows 記錄檔 → 系統,篩選來源 BugCheck,確認沒有新的 0x101 紀錄。
C:\Windows\Minidump\ 資料夾沒有比你動手當天更新的 .dmp 檔。

如果調整 BIOS/驅動後,原本每週跳好幾次的頻率明顯降低但沒有完全消失,通常代表方向正確、但還沒排除所有干擾源(例如超頻+驅動同時有問題),可以按順序把方法一到三都跑過一輪。

🔙 萬一翻車:回退步驟

以下任一情況,請先暫停、不要繼續動手:不確定自己主機板/筆電型號與 BIOS 版本、還沒記下原始 BIOS 設定就已經重置、筆電電量低於 30% 且不在電源旁、這台是公司或學校配發設備且沒有 IT 部門授權、開了 BitLocker 但沒有 Recovery Key 就打算調整儲存控制器相關設定。

情境一:BIOS 重置後開機找不到系統/卡在開機畫面

多半是「Load Optimized Defaults」順帶把儲存控制器模式從 AHCI 切回其他模式(或反過來)。重新進 BIOS,找到儲存裝置設定(SATA/NVMe Mode),改回原本能開機的模式,再存檔重開。

情境二:開啟 Driver Verifier 後系統開機就藍屏、進不了桌面

進入安全模式(開機時強制關機 2–3 次觸發「自動修復」→ 進階選項 → 安全模式),在系統管理員命令提示字元輸入 verifier /reset 關閉 Driver Verifier,重開機即可恢復正常。

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

用 Windows 安裝媒體開機進入 WinRE(Windows 恢復環境),選擇「疑難排解 → 進階選項 → 開機修復」;若懷疑是 BIOS 設定造成,也可以先移除電池(桌機拔 CMOS 電池或短接主機板上的 Clear CMOS 針腳數秒)讓 BIOS 恢復出廠值,這個動作會清空所有 BIOS 自訂設定但不會影響硬碟資料。

💡 總結:預防再次發生

CLOCK_WATCHDOG_TIMEOUT 這顆停止碼,在 Microsoft 官方支援社群的討論串裡有個滿一致的共通點:提問的人大多最近才動過跟「時脈」有關的東西——不論是自己手動超頻,還是筆電、主機板廠商出貨時就內建了一組不夠保守的 XMP/EXPO 效能設定檔。站長我會建議,買新機或組新機時,與其一路把所有「效能模式」「XMP」都打開圖個安心,不如先確認系統穩定跑過至少一兩週,再考慮要不要疊加超頻——省下來的除錯時間,遠比那零點幾秒的效能差距划算。

另一個容易被忽略的預防習慣,是BIOS 更新別拖太久。晶片組廠商經常在韌體更新裡修正處理器電源管理、時脈穩定度相關的邊角案例,這類問題往往不會寫進顯眼的更新 log,但正好就是 0x101 這類「隨機」BSOD 的常見苦主。半年到一年檢查一次主機板/筆電官網有沒有新版 BIOS,是相對低成本的預防動作。

最後提醒:如果你的電腦是近期才買的全新機器,尤其是筆電,0x101 反覆出現且方法一到三都試過仍無改善,不要猶豫太久,直接聯絡原廠客服走保固鑑定——原廠工程師通常也會用類似的 minidump 分析流程確認問題,你手上如果已經留了傾印檔與事件檢視器截圖,送修時提供給工程師,通常能加快鑑定速度。

❓ 常見問題

Q:CLOCK_WATCHDOG_TIMEOUT(0x101)跟 DPC_WATCHDOG_VIOLATION(0x133)是同一種問題嗎?

不是同一種,但兩者都屬於 Windows 的「看門狗」保護機制,容易被搞混。0x133 是某個 DPC(延遲程序呼叫)常式在 DISPATCH_LEVEL 執行太久,問題通常出在特定驅動程式的軟體邏輯;0x101 是某顆 CPU 核心連最基本的時脈中斷都沒回應,層級更底層,常見成因偏向超頻、時脈穩定度或硬體本身。

Q:我完全沒有超頻過,為什麼還是跳 0x101?

「沒有自己超頻」不代表系統時脈就一定跑在最保守的設定。不少筆電出廠就預設開啟接近極限的效能模式,主機板廠商也常把 XMP/EXPO 設定檔標成「建議開啟」甚至直接預設啟用——這些在使用者感覺上都不算「自己超頻」,但對系統來說一樣是把時脈推離原廠最保守的驗證範圍。先照方法一把 BIOS 重置為預設值看看,是排除這個可能性最快的做法。

🔗 延伸閱讀

📎 參考資料來源

📖 第一級|廠商官方:

Bug Check 0x101 CLOCK_WATCHDOG_TIMEOUT — Microsoft Learn — 2026-07-09 查證
How to Use Driver Verifier for Driver Testing — Microsoft Learn — 2026-07-09 查證

📖 第二級|技術支援社群佐證:

Got a “clock watchdog timeout” blue screen? — Microsoft Q&A — 2026-07-09 查證(Microsoft 官方支援平台使用者回報與工程師建議討論串)

⚠️ 本文核心事實(bugcheck 參數定義、官方成因說明)以第一級官方文件為準,第二級為社群案例佐證與常見排查順序參考,非官方規格定義。

📅 本文查證戳記:2026-07-09 依據 Windows 10/11 官方文件撰寫,無站長本機實測數據,診斷與修復步驟以微軟官方文件與公開技術資料交叉查證。
若你在特定機型上遇到步驟失效或有其他排查心得,歡迎留言分享,對其他讀者也是很有價值的案例。