Windows 排程診斷：EnabledExecution 會停用什麼
本頁內容
簡短回答：
EnabledExecution=0停用的正是 已排程 的 Windows 診斷套件執行。Task Scheduler 仍可啟動對應的系統工作，但其處理常式不會執行偵測、疑難排解與自動修復。這不會停用整個 Windows 診斷，也不是已證實的 FPS、延遲、RAM 或磁碟最佳化。
狀態： 此原則的用途已有 Microsoft 文件記載。在 Windows 11 Pro 25H2 上已靜態確認，其值會在 Scheduled Diagnostics 處理常式內被檢查，並限制診斷套件的執行。本研究中未測量該工作的執行階段行為及其對效能的影響。
待驗證的陳述
Section titled “ 待驗證的陳述”我們驗證了四項陳述：
- Windows 將
EnabledExecution用作 Scheduled Diagnostics 的 machine policy。 0的值禁止已排程的診斷套件執行。- 手動啟動同一個工作不會繞過其處理常式內的原則檢查。
- 停用此原則並不代表停用所有 Windows 診斷與維護工具。
相關的 BoosterX 設定
Section titled “相關的 BoosterX 設定”與本頁相關的有「已排程診斷」、「自動維護」、「診斷事件」與「動作記錄」。禁止其中一條維護分支並不會停用整個 Windows 診斷，也無法證明能普遍節省 CPU。
什麼是 Scheduled Diagnostics
Section titled “ 什麼是 Scheduled Diagnostics”Scheduled Diagnostics 讓 Windows 定期偵測系統問題、執行診斷，並在允許的層級下自動修復部分找到的問題。
Microsoft 描述了三种可能的行為：
- 偵測並疑難排解問題，並通知使用者進行互動式修復；
- 偵測、疑難排解並自動修復部分問題；
- 禁止已排程的偵測、診斷與修復。
若未設定原則，Windows 會使用本機的疑難排解偏好設定。若沒有這類本機設定，Microsoft 記載的預設行為為啟用偵測、診斷與修復。
| 範圍 | 已檢查的內容 | 狀態 |
|---|---|---|
| Microsoft Policy CSP | 用途、Registry mapping、預設狀態與無需重新啟動的套用 | 已有文件記載 |
| Windows 11 Pro 25H2 build 26200.8655 x64 | 原則讀取與 Scheduled Diagnostics 處理常式的分支邏輯 | 已靜態確認 |
| Windows 10 與 Windows Server | 僅限公開文件中所述的適用性 | 未驗證確切的執行階段路徑 |
| 使用者效能 | CPU、RAM、I/O、FPS、frametime 與 input latency | 未測量 |
Microsoft 的公開文件指出，對應的 ADMX-backed policy 支援 Windows 10 2004 搭配特定 cumulative updates，以及 Windows 11 21H2 及更新版本中的 Pro、Enterprise、Education 與 IoT Enterprise 版本。Home 未列於該表中。這無法證明內部路徑在每個版本與組建上都保持不變。
本研究結合了兩類證據：
- Microsoft 官方文件，包含原則用途、其 Registry mapping 與各種狀態；
- 對服務 Scheduled Diagnostics 工作的 Windows 系統元件進行靜態檢查。
我們檢查了 0、1、缺少值以及額外 execution level 的處理方式。未使用虛擬機、系統追蹤或執行診斷套件。反編譯程式碼、內部工具與原始產物不予公開。
| 狀態 | 已記載或已確認的行為 |
|---|---|
EnabledExecution=0 |
已排程的偵測、診斷與修復皆被禁止 |
EnabledExecution=1 無獨立層級 |
Scheduled Diagnostics 路徑被允許；確切動作取決於 execution level |
| 原則不存在 | 使用本機偏好設定；Microsoft 記載預設為啟用行為 |
| 型別錯誤的值 | 不保證正常執行；不建議此種狀態 |
在受檢查的組建上，檢查是在系統工作的處理常式內執行。因此，手動啟動同一個工作不會把原則所禁止的執行變成允許的執行。
已確認的事項
Section titled “ 已確認的事項”EnabledExecution屬於 Scheduled Diagnostics，而非整個 Windows 診斷。0的值會透過受檢查的 scheduled handler 封鎖診斷套件的執行。- 系統工作及其註冊不會因此被刪除。
- 原則變更無需重新啟動即可套用；Scheduled Diagnostics 要運作需要執行中的 Task Scheduler 服務。
- 刪除 policy value 會讓 Windows 回到本機偏好設定與預設的正常邏輯。
未確認的事項
Section titled “ 未確認的事項”- 以可測量的幅度降低背景負載、CPU、RAM 或磁碟作業；
- 提升平均 FPS、P1、P0.1 或減少 input latency；
- 停用
sfc、chkdsk、Microsoft Defender、磁碟最佳化或所有維護工作； - 防止所有 Windows 找到問題時的通知；
- Windows 10、Windows 11 與 Windows Server 上相同的內部路徑。
缺乏量化結果很重要：排除一條罕見的診斷路徑，可能完全不會改變一般遊戲工作階段的指標。
本研究是在單一最新系統上以靜態方式完成。它確認了 decision path 的存在與意義，但未顯示實際啟動的頻率、已完成的工作量、設定還原後可能的 backlog 以及使用者實際感受的效果。
官方預設狀態與回退至本機偏好設定已有 Microsoft 文件記載。policy value 與本機 preference value 同時實際皆不存在的全新安裝行為，未另行重現。
對大多數使用者而言，保留 Windows default 較為安全：這樣 Windows 仍能預先偵測並修復某些問題。
只有在使用者想要禁止的正是已排程的診斷套件，並接受失去這項預防功能時，停用才是有意義的刻意取捨。請勿為了宣稱的效能提升而套用此設定：本研究並未顯示這樣的結果。
相關的免費設定說明於 BoosterX 的「已排程診斷」頁面。
若要還原，請透過 BoosterX 中的 Windows default 狀態刪除 policy override。依 Microsoft 文件，無需重新啟動或重新啟動服務：變更會立即套用。
還原後，具體行為取決於 Windows 的本機偏好設定。若未設定，Microsoft 指出預設為啟用偵測、診斷與修復。
公開主要來源
Section titled “ 公開主要來源”- ADMX_sdiagschd Policy CSP，Microsoft Learn - 原則用途、支援版本、Registry mapping、狀態與無需重新啟動的套用。
本研究由 BoosterX 團隊發布，屬於產品設定的一部分。BoosterX 中存在某項設定並未被用作其有效性的證據。BoosterX Wiki 與 Microsoft Corporation 無關聯、未經其授權、贊助或認可。
來源最後檢查：2026-08-24。
- 2026-09-20： 將 description 縮減至搜尋摘要的限制內。
- 2026-08-24： 根據 Microsoft 文件與 Windows 11 Pro 25H2 的靜態檢查發布首個公開版本。