⚡ 站長快讀:核心重點
- 文章屬性:疑難排除
- 適用系統:Windows 11 / Windows 10
- 難易度 / 耗時:⭐⭐(方法三 ⭐⭐⭐)/ 約 40 分鐘
- 核心結論:它不是一支程式,而是硬體中斷處理時間的總和。
- 適用對象:沒開重負載卻卡頓、音訊爆音、游標停頓的人。
📌 快速答案
一句話答案:System Interrupts CPU 佔用高代表驅動的中斷處理常式與延遲程序呼叫吃掉核心時間,要用 ETW 追蹤把時間對回具體驅動模組,而不是重灌或關閉服務。
🧰 開始前的準備
- 適用系統:Windows 11 與 Windows 10 皆適用。文中用到的 Windows Performance Recorder(WPR),其官方命令列說明頁載明需要 Windows 8.1 或更新版本的作業系統。
- 權限需求:系統管理員。啟動 ETW 追蹤、更新或回復驅動、停用裝置全都需要系統管理員權限。
- 需要工具:
- Windows Performance Recorder / Windows Performance Analyzer:兩者都包含在 Windows 評估及部署套件(Windows ADK)中,ADK 同時附有 Xperf。
- 裝置管理員(系統內建,用來回復或更新驅動)。
- Process Explorer(Sysinternals 免費工具,官方下載頁載明用戶端執行環境為 Windows 11 以上;版本更新頻繁,一律以官方下載頁當下標示為準,本文查證當日為 v17.14、2026 年 9 月 10 日發佈)。
- 預計耗時:錄製與判讀約 20 分鐘,驅動處置與重測約 20 分鐘。若牽涉到主機板韌體或外接裝置逐一排除,另計。
🔍 症狀描述與錯誤訊息
先講結論:System Interrupts 不會給你錯誤訊息,它的「錯誤訊息」就是延遲本身。 這也是它難查的原因——沒有事件檢視器錯誤碼、沒有藍屏、沒有當機對話框,你只會覺得電腦「怪怪的」。
實務上,這類問題常見的樣貌是下面這幾種組合:
- 工作管理員的「處理程序」分頁出現一列 System Interrupts(Windows 正體中文版顯示為「系統中斷」),CPU 欄位長期停在一個不歸零的數字,而且你根本沒有開任何重負載程式。
- 游標移動一頓一頓,或是鍵盤打字會突然「卡住半秒」再一次吐出來。
- 播放影片或視訊會議時音訊出現爆音、破音、瞬斷,畫面掉格。
- 插上某個 USB 裝置、接上某條網路線、或是筆電一離開電源之後,上述症狀才開始。
這裡有一個非常關鍵、卻幾乎被所有教學漏掉的事實:這一列本身沒有對應的映像檔路徑,因此「開啟檔案位置」這類動作對它不可用——它不是一個真正的處理程序。 它是 Windows 把一段「不屬於任何使用者程式」的核心時間集中呈現出來的結果。理解這件事,才會明白為什麼所有「結束 System Interrupts」「關閉 System Interrupts 服務」的建議都是無效指引。
⚠️ 如果你的症狀是直接藍屏而不是卡頓,那就不是本文的題目,請改看對應的停止碼分析文章。System Interrupts 佔用偏高與藍屏是不同的失敗面,只是兩者常常指向同一支驅動。
🔎 問題根因
先講結論:依中斷處理的機制,System Interrupts CPU 佔用高的排查方向會落在「某支驅動的中斷處理路徑太慢」或「中斷被觸發得太頻繁」這兩件事上。(這是由 ISR/DPC 機制推得的方向,不是任何統計比例。) 它不是 Windows 壞掉,也不是 CPU 不夠力。
要理解為什麼,得先知道中斷處理在 Windows 裡是怎麼被切成兩段的。依微軟官方驅動程式文件,一個會收中斷的實體裝置,其驅動會註冊一個或多個中斷服務常式(Interrupt Service Routine,ISR),系統每次收到該中斷就呼叫一次 ISR。而官方同樣明講:ISR 必須盡可能快地執行完畢,所以驅動通常會把「處理完這個中斷剩下的事」延後到 ISR 回傳之後——系統為此提供了延遲程序呼叫(Deferred Procedure Call,DPC),DPC 由 ISR 排入佇列,之後在比 ISR 更低的 IRQL 執行。
換句話說,你在工作管理員看到的那個數字,是這兩段時間加總後的表象。而它們失控的方式完全不同,這正是本文最想建立的第一個觀念:不分層就永遠在猜。
| 失控型態 | 實際發生什麼 | 典型嫌疑裝置 | 可觀察到的特徵 |
|---|---|---|---|
| ISR 太久 | 驅動在最高優先權的中斷處理裡做了太多事,或等待硬體/韌體回應 | 儲存控制器、主機板晶片組、電源管理相關裝置 | 卡頓呈現「整台鎖住一瞬間」,連滑鼠都不動 |
| DPC 太久或太多 | ISR 把工作全丟給 DPC,佇列排隊變長 | 網路卡、Wi-Fi、音效、顯示卡 | 高網路流量或播放音訊時症狀最明顯 |
| 中斷觸發太頻繁 | 裝置反覆送出中斷,每次都不貴但次數爆量 | 接觸不良的 USB 裝置、異常的外接硬碟、故障的周邊 | 拔掉某個裝置後立刻改善 |
ℹ️ 本表之「典型嫌疑裝置」與「可觀察特徵」為由 ISR／DPC 機制推得的排查方向,不是統計結果——微軟官方文件只描述機制本身,並未對裝置類別與失控型態的對應做任何統計或列舉。實際兇手仍以下一節的量測結果為準。
表格重點摘要:
- 三種型態的共通點是「核心時間被吃掉」,但入手方向不同,所以第一步不是改設定,而是量測。
- 只看工作管理員那個百分比,無法區分這三種型態——它把三者加在一起了。
- DPC 側的問題常見於網路與音訊路徑,因為這兩類驅動天生就要處理大量、密集的封包或緩衝區。
- 「拔掉某個裝置就好了」屬於第三型,通常是硬體本身或連接品質的問題,不是驅動寫得爛。
- 同一支驅動有可能同時踩中兩型,所以量測要看的是「模組層級的時間分佈」,不是單一數字。
🔬 底層機制:這段 CPU 時間到底算在誰頭上?
先講結論:這段時間發生在核心模式,而且不屬於任何一個使用者處理程序,所以工作管理員只能另外開一列來擺它。
ISR 執行的時機是「硬體說話的當下」。依官方文件,系統每次收到該中斷就會呼叫驅動註冊的 ISR;這段程式碼跑在非常高的優先權上,會把當下那顆 CPU 核心上原本在跑的東西直接打斷。因為它太霸道,官方才會明訂 ISR 必須盡快結束,並提供 DPC 讓驅動把後續工作延後、在較低的 IRQL 再做完。
這條「使用者程式碰不到、但會直接搶走 CPU」的路徑,正是 Windows 使用者模式與核心模式分界的具體展現。如果你對這條界線還不熟,建議先看Windows 使用者模式與核心模式差在哪?程式為什麼不能直接控制硬體,再回來看下面的內容會順很多。
線路式中斷與訊息式中斷的差別
還有一層機制值得知道,因為它解釋了「為什麼有些裝置一出問題就整台頓,有些卻只影響自己」。
依微軟官方文件,PCI 裝置可以產生訊息式中斷(Message-Signaled Interrupts,MSI)。MSI 在 PCI 2.2 規格中被提出,作為傳統線路式中斷的替代方案(官方用語是 alternative,不是取代):裝置不再靠一支專用接腳觸發中斷,而是對特定記憶體位址寫入一個值來觸發。Windows 兩種都支援。
規格上的差異相當明確:PCI 2.2 的訊息由位址加上一個 16 位元的值構成,裝置最多可支援 16 個訊息;PCI 3.0 定義了擴充版的 MSI-X,訊息改為位址加上 32 位元的值、每個訊息有各自的位址,單一裝置最多可支援 2,048 個不同訊息。若一個裝置同時支援 MSI 與 MSI-X,作業系統會自動採用 MSI-X。
這件事的實務意義是:訊息數量愈多,裝置愈能把中斷分散到不同的處理路徑上。 而官方也寫得很清楚——如果隨插即用(PnP)管理員無法配給驅動所要求的訊息數量,它會只配給該裝置一個訊息。落到單一訊息的裝置,在高負載下就比較容易把中斷與後續 DPC 擠在同一條路上。
這也是為什麼網路上會流傳「去登錄檔把裝置改成 MSI 模式就會變快」這種偏方。先把話說在前面:依官方文件,MSI 的啟用方式是在驅動安裝過程中於登錄檔啟用,那是驅動與裝置設計層的事,不是給使用者拿來調校的開關。本文在方法三會說明為什麼不建議你手動去動它。
DPC 失控到極限會發生什麼事
DPC 不是「慢一點而已」。依微軟官方的 Bug Check 0x133 文件,DPC watchdog 會在兩種情況下被觸發:①偵測到單一長時間執行的 DPC;②系統累計長時間停留在 DISPATCH_LEVEL 或更高的 IRQL。參數 1 的值就是用來區分這兩者。
同一份官方文件還給了一個很值得記住的量級:DPC 不應執行超過 100 微秒、ISR 不應執行超過 25 微秒,不過系統實際套用的逾時值設得比這高得多。這兩個數字說明了這條路徑對時間有多敏感——你在工作管理員看到的「幾個百分點」,底下是以微秒為單位的預算被反覆超支。也就是說,System Interrupts 佔用偏高與 0x133 藍屏,本質上是同一條路徑上的輕症與重症。 如果你的機器除了卡頓還偶爾跳這支停止碼,那分析方向是共通的,可以直接參考電腦一直跳 DPC_WATCHDOG_VIOLATION?先別重灌,八成是這支驅動程式。
🛠️ 解決方案
⚠️ 開始前請先做這三件事:①建立一個系統還原點;②把重要資料另外備份一份;③確認你手上有這台機器的型號與原廠支援頁網址。方法一與方法二風險低,但方法三會停用硬體裝置,必須有回頭路。
方法一:先分層——用 WPR 錄一段,看 ISR 與 DPC 誰在跳
先講結論:不要從「改設定」開始,要從「錄一段」開始。 這一步的產出是一個檔案,而不是一個猜測。
Windows Performance Recorder(WPR)是微軟官方的效能錄製工具,基於 Windows 事件追蹤(ETW),隨 Windows ADK 一起提供,用來記錄系統與應用程式事件,之後交給 Windows Performance Analyzer(WPA)分析。WPA 則負責把 WPR 或 Xperf 錄到的 ETW 事件畫成圖表與資料表,並且可以開啟任何 ETL 追蹤記錄檔。
操作步驟如下(全部在系統管理員身分的終端機執行,安裝與執行請分開兩行,不要串成一行):
- 先從微軟官方網站下載並安裝 Windows ADK,安裝時勾選 Windows Performance Toolkit。
- 開始錄製。這裡用官方內建的 CPU usage 側寫檔,它記錄的是系統上每顆 CPU 的使用狀況;
-filemode依官方命令列說明是「錄到檔案」(預設為記憶體模式):
wpr -start CPU -filemode官方命令列說明頁給的範例分別是 wpr -start CPU(記憶體模式的完整版 CPU 側寫檔)與 wpr -start CPU.light -filemode(輕量版、檔案模式),可依磁碟空間取捨。
- 讓症狀重現 30 到 60 秒。這一步是整個流程的成敗關鍵——如果錄製期間電腦是順的,那份檔案就沒有價值。請刻意做會誘發症狀的事:大量檔案複製、視訊會議、線上影片、插拔那個可疑的 USB 裝置。
- 停止錄製並輸出檔案。官方語法為
wpr -stop <file> <problem description>——檔名是必填參數,問題描述雖為選填,但官方建議填寫:
wpr -stop C:\Temp\interrupts.etl "System Interrupts high CPU"- 用 WPA 開啟這個 ETL 檔。依官方的 CPU 分析文件,DPC/ISR 圖表是 WPA 中 DPC/ISR 資訊的主要來源,該圖表提供 Module 欄位(含有該 DPC 或 ISR 函式的模組);官方在排查步驟中明確指示:在 DPC/ISR 圖表中選用預設集 DPC/ISR Duration by Module, Function。若想先看是哪顆核心受害,官方另有 DPC/ISR Duration by CPU 預設集。
ℹ️ 若這份追蹤裡看不到 DPC/ISR 圖表,改用官方另一個內建側寫檔
GeneralProfile重錄一次即可(wpr -start GeneralProfile -filemode)。
判讀的重點只有一句話:你要的不是百分比,而是模組名稱。 WPA 會把時間歸屬到具體的驅動檔名(例如某張網路卡或音效卡的驅動),那個檔名就是後續所有動作的唯一依據。如果排在最前面的是 ntoskrnl 或 hal 這類通用系統模組,不要就此斷定是硬體問題——那只代表時間還沒辦法直接歸屬到某支裝置驅動。此時請改套用官方的 DPC/ISR Duration by CPU 預設集,看是哪一顆核心在受害,再往下拆;等到排行榜上出現具體的裝置驅動檔名,才進入方法二。
沒有裝 ADK 的輕量替代方案:Sysinternals 的 Process Explorer 是免費工具,官方下載頁載明用戶端執行環境為 Windows 11 以上(本文查證當日標示為 v17.14、2026 年 9 月 10 日發佈;此頁版本更新頻繁,請以當下標示為準)。它的顆粒度不如 WPA,但足以快速判斷「這台機器的核心時間是不是真的被中斷路徑吃掉」,適合用來決定要不要進一步安裝 ADK。
方法二:把模組名對回裝置,做最小幅度的變更
先講結論:拿到模組名之後,正確順序是「先回復、再更新、最後才考慮停用」,不是反過來。
- 找出模組屬於哪個裝置:用檔名到裝置管理員裡逐一比對。在裝置管理員中對裝置按右鍵選「內容」,切到「驅動程式」索引標籤,再點「驅動程式詳細資料」,就能看到這個裝置實際載入了哪些驅動檔。
- 如果症狀是最近才出現,先回復驅動。微軟官方支援文件明確指出:若問題是在一次 Windows Update 之後才發生,重新安裝前一版驅動往往就能解決。官方的回復步驟是:開始功能表按右鍵→裝置管理員→展開該類別→對裝置按右鍵選「內容」→「驅動程式」索引標籤→回復驅動程式→選擇原因→按「是」確認→視提示重新啟動。官方同時提醒:執行驅動回復必須以具備系統管理員權限的帳號登入。
- 如果回復選項是灰的,或回復之後沒有改善,再往新版走。官方建議的更新途徑有兩條:在裝置管理員對裝置按右鍵選「更新驅動程式」→「自動搜尋更新的驅動程式軟體」;或是先從裝置製造商官網下載對應 Windows 版本與架構的驅動,再用「瀏覽電腦上的驅動程式」指定資料夾安裝。
- 只從原廠官網下載。這一點官方文件寫得很直接:請避免從製造商官方網站以外的任何網站下載驅動程式。 那些號稱能一鍵更新全機驅動的第三方工具,在這類問題上是加深混亂,不是解決問題。
- 主機板韌體也要納入考慮。如果 WPA 指向的是晶片組、電源管理或 ACPI 相關的模組,那麼問題可能不在作業系統這一層,而在主機板韌體。這時請到主機板或整機的原廠支援頁,確認是否有針對穩定性或電源管理的韌體更新。
⚠️ 更新主機板韌體屬於高風險操作。更新過程中斷電或中斷可能導致主機板無法開機,且多數韌體無法自行回退。請務必接上不斷電系統或確認電源穩定、逐字照原廠指示操作,並先確認原廠是否提供回刷舊版韌體的管道。若原廠沒有提供回刷方式,而你的症狀只是輕微卡頓,請不要更新韌體。
方法三:二分法停用裝置(⭐⭐⭐,最後手段)
⚠️ 高風險操作警語:本段會停用硬體裝置。停用錯誤的裝置可能導致無法上網、無法看到畫面、甚至無法開機。開始前請確認你已建立系統還原點、已備份重要資料,並且知道如何進入安全模式。
先講結論:二分法只在「量測結果不明確」時才用,它是補刀,不是第一刀。
停止條件清單(符合任一項,請不要繼續):
- 你不確定這台機器的型號,或不確定目前 Windows 的版本。
- 你還沒有建立系統還原點,也沒有備份資料。
- 這台是公司或學校的管控設備,而你沒有 IT 部門的授權。
- 系統磁碟啟用了 BitLocker,而你手上沒有修復金鑰。
- 你打算停用的是儲存控制器、顯示卡或任何列在「系統裝置」底下的項目。
執行原則:
- 一次只停用一個裝置,而且只停用非必要的周邊(音效、藍牙、額外的網路介面、指紋辨識、讀卡機這類)。
- 每停用一項,就重新跑一次方法一的錄製流程,用同一種負載重測。
- 有改善就停手,把該裝置重新啟用,改去處理它的驅動,而不是讓它一直停用著。
- 禁止停用:任何儲存控制器、系統磁碟相關裝置、顯示卡、以及「系統裝置」分類下你不認識的項目。
- 如果懷疑某支驅動有實作層面的問題(而不只是版本舊),再考慮動用 Driver Verifier。這個工具威力很大、誤用會直接讓機器開不了機,務必先讀完Driver Verifier 完整使用教學 2026|揪出偷偷作亂的驅動程式再動手。
關於網路上流傳的「改登錄檔開 MSI 模式」:不建議。理由已在前一節說明——依官方文件,MSI 是在驅動安裝過程中於登錄檔啟用的機制,訊息數量由 PnP 管理員分配,配不到要求數量時就只配一個。手動改寫這些鍵值等於繞過裝置與驅動原本的設計假設,常見後果是裝置無法啟動;若你改到的是儲存或顯示相關裝置,還可能直接開不了機。在你能夠明確說出「這支驅動的哪一個已知缺陷會被這個改動修好」之前,不要動它。
✅ 驗證修復結果
先講結論:驗證不能靠感覺,要用同一份負載重跑同一份錄製流程。
- 量化面:用方法一同樣的指令再錄一次,做同樣的事、錄同樣長的時間,然後比較 WPA 裡「那個模組」的時間佔比有沒有下降。負載不一樣,比較就沒有意義。
- 症狀面:回到最初讓你察覺異常的那件事——播同一支影片、開同一個視訊會議、複製同一批檔案,看爆音、掉格、游標停頓是否消失。
- 持續面:讓機器正常使用一到兩天。部分中斷類問題只在特定情境下出現(例如省電模式、外接螢幕接上時、Wi-Fi 訊號弱時),當下測一次過關不代表真的解決。
如果模組的時間佔比下降、但症狀還在,那通常代表不只一個來源。回到方法一的排行榜,處理第二名。
🔙 萬一翻車:回退步驟
情境一:停用裝置後某個功能不見了
開啟裝置管理員,找到剛剛停用的裝置(通常會有一個向下箭頭的標記),按右鍵選「啟用裝置」,必要時重新啟動。
情境二:更新驅動之後反而更糟
回到裝置管理員→該裝置內容→「驅動程式」索引標籤→回復驅動程式。這正是微軟官方提供這個按鈕的用途。若回復按鈕是灰的(代表系統沒有保留舊版),就用系統還原點回到更新前的時間點。
情境三:系統無法正常開機(最壞情況)
- 先試官方列出的正常入口:登入畫面點「電源」,按住 Shift 再選「重新啟動」;或從「設定」進入復原頁面,在「進階啟動」按「立即重新啟動」。
- 如果連登入畫面都到不了:依官方 WinRE 文件,偵測到連續兩次 Windows 開機失敗時,WinRE 會自動啟動(官方列出的自動觸發條件還包括開機完成後兩分鐘內連續兩次非預期關機、或連續兩次系統重新開機)。
- 進入後選「疑難排解」→「進階選項」→「啟動設定」→重新啟動後選擇安全模式。
- 在安全模式中執行情境一或情境二的回退動作,或直接套用先前建立的系統還原點。
- 若系統磁碟啟用了 BitLocker,這個過程會要求你輸入修復金鑰——這就是為什麼前面的停止條件要你先確認金鑰在手。
💡 總結:預防再次發生
站長我想強調的是:這類「沒有錯誤訊息的慢」,最容易踩的陷阱不是技術不夠,而是順序顛倒——先換驅動、先關服務、先重灌,最後才想到要量一下。中斷路徑的問題偏偏是最不能用猜的——因為造成卡頓的那支驅動,通常不是你直覺會懷疑的那一支。
要讓這件事不再復發,長期上可以做這三件:
- 驅動只從兩個來源拿:Windows Update,或裝置製造商官網。官方文件本身就明白要求避免第三方網站,而在中斷處理這種核心路徑上,來路不明的驅動造成的代價特別高。
- 記住「回復驅動程式」這個按鈕存在。官方文件指出問題若發生在 Windows Update 之後,裝回前一版驅動往往就解決了。很多人根本不知道有這個選項,直接跳去重灌。
- 留一份「好的時候」的基準錄製。系統狀態正常時,花五分鐘用方法一錄一份 ETL 存起來。下次出問題,你就有東西可以比對——這是把「我覺得變慢了」變成「這個模組多吃了多少」的唯一辦法。
最後提醒一句:如果所有驅動都更新到最新、也回復過舊版,症狀仍然存在,而且拔掉某個外接裝置就會改善,那答案很可能不在軟體。硬體接觸不良、線材老化、外接硬碟即將故障,都會表現成「中斷被觸發太頻繁」。這時候繼續在系統設定裡繞,只是浪費時間。
❓ 常見問題
Q:System Interrupts 是病毒嗎?
不是。它不是一支可執行檔,也沒有對應的映像檔路徑,所以病毒無法「變成」它。不過要留意:惡意程式確實可能取一個長得很像的名字並以獨立處理程序出現。判斷方式很簡單——真正的那一列沒有映像檔路徑,「開啟檔案位置」不可用;如果你看到的項目可以開啟檔案位置、而且指向一個奇怪的路徑,那就不是它。不過這只是快篩,最終仍以 Windows 安全性的完整掃描結果為準。
Q:為什麼它會吃掉這麼多 CPU?
因為它代表的是驅動的 ISR 與 DPC 所消耗的核心時間。依官方文件,系統每收到一次中斷就呼叫一次 ISR,而 ISR 必須盡快結束、把後續工作以 DPC 延後到較低的 IRQL 執行。當某支驅動在這條路徑上太慢,或中斷被觸發得太頻繁,累積起來就會在工作管理員顯示成一個醒目的數字。
Q:可以直接結束它嗎?
不行,而且這個問題本身就問錯方向。它不是可以被結束的處理程序;就算做得到,你要「結束」的等於是整台機器與硬體溝通的能力。正確的動作是找出讓中斷處理變慢的那支驅動或那個裝置。
Q:怎麼知道是哪個硬體?
用方法一的 WPR 錄製加 WPA 判讀,把時間歸屬到具體的驅動模組名稱,再用該檔名到裝置管理員的「驅動程式詳細資料」裡反查是哪個裝置。跳過量測直接猜硬體,是這類問題最常見的時間浪費。
Q:修完之後又復發怎麼辦?
先確認復發的情境是否與上次相同。若是在 Windows Update 或驅動自動更新之後復發,直接用「回復驅動程式」處理;若是換了使用情境才復發(例如接上新的外接裝置、改用無線網路),那代表原本就有第二個來源,重跑一次方法一,看排行榜第二名是誰。
🔗 延伸閱讀
- INTERRUPT_EXCEPTION_NOT_HANDLED(0x3D)藍屏排錯:參數 1、2 是紀錄指標,不是陷阱編號
- DRIVER_IRQL_NOT_LESS_OR_EQUAL(0xD1)藍屏怎麼修?讀懂四個參數揪出兇手驅動
- 電腦睡一睡、關機就藍屏?DRIVER_POWER_STATE_FAILURE(0x9F)先揪出這支驅動程式
- Windows 11 25H2 筆電發燙?解密 Modern Standby (S0) 與 SleepStudy 深度檢測
📎 參考資料來源
📖 第一級|廠商官方:
- Introduction to Interrupt Service Routines (ISRs) — Microsoft Learn — 2026-09-11 查證
- Introduction to DPC objects — Microsoft Learn — 2026-09-11 查證
- Introduction to message-signaled interrupts — Microsoft Learn — 2026-09-11 查證
- Windows Performance Recorder — Microsoft Learn — 2026-09-11 查證
- Windows Performance Analyzer — Microsoft Learn — 2026-09-11 查證
- Built-in Recording Profiles — Microsoft Learn — 2026-09-11 查證
- Process Explorer — Microsoft Sysinternals — 2026-09-11 查證
- Update drivers through Device Manager in Windows — Microsoft Support — 2026-09-11 查證
- Bug Check 0x133: DPC_WATCHDOG_VIOLATION — Microsoft Learn — 2026-09-11 查證
- WPR Command-Line Options — Microsoft Learn — 2026-09-11 查證
- CPU Analysis(WPA DPC/ISR 圖表與預設集)— Microsoft Learn — 2026-09-11 查證
- Windows Recovery Environment (Windows RE) — Microsoft Learn — 2026-09-11 查證
⚠️ 本文核心事實以第一級為準,第二級為補充。
📅 本文查證戳記:2026-09-11 依 Microsoft Learn 與 Microsoft 支援之官方文件撰寫。
若你在後續版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。