Windows 11 ETW 自動記錄器：究竟是什麼在寫入磁碟
本頁內容
在乾淨的 Windows 11 26H2 中，註冊了 39 個 ETW 自動記錄器工作階段，其中 19 個已啟用，但實際上從開機起就寫入磁碟的只有 9 個。另有 3 個存在於記憶體環形緩衝區中（磁碟成本為零），5 個以即時模式運作且不產生檔案，而 2 個 Defender 工作階段實際上並未啟動。主要的產生來源是 Diagtrack-Listener：在遙測服務運作時，2 小時內約產生 110 MB 的事件。在自動記錄器檔案佔用的 32 MB 中，28 MB 是預先配置的空檔案。
狀態： 目錄是透過靜態讀取登錄檔彙整而成；實際狀態則以開機後 2 小時的快照驗證。單一組建、單一虛擬機器；轉移到其他組態（配備 WiFi 的筆記型電腦、使用 ReFS 的系統）會改變作用中檔案的組成。
待驗證的陳述
Section titled “待驗證的陳述”我們驗證了三項陳述：
- 「停用自動記錄器」是一項單純明確的操作，而且作用中工作階段的組成很少。
- 自動記錄器檔案佔用可觀的空間。
- 診斷追蹤在閒置時會產生明顯的事件流量。
- Windows 11 Pro，組建 26300.9457（26H2），無 WiFi 模組的虛擬機器；
- 登錄檔機碼 Autologger：全部 39 個工作階段、其啟動旗標、檔案模式與已連接的提供者；
- 乾淨系統開機後 2 小時的實際工作階段與檔案狀態；
- 1115 個已註冊的 ETW 提供者與 1049 筆「工作階段中的提供者」記錄。
未驗證：其他組建、配備無線模組的機器、ReFS 磁碟區與 RDP 負載；在長時間區間內停用遙測時的工作階段行為。
工作階段目錄是從登錄檔設定 Autologger 彙整而成：啟動旗標、檔案模式、限制與提供者。實際狀態則在開機後 2 小時進行比對：已啟動的工作階段、佔用的緩衝區與檔案大小。Diagtrack-Listener 的事件量估計是依據已寫入的緩衝區數量得出。
自動記錄器的組成
Section titled “自動記錄器的組成”| 類別 | 工作階段 |
|---|---|
| 註冊總數 | 39 |
| 依登錄檔啟用（Start=1） | 19 |
| 其中實際已啟動 | 17 |
| 從開機起寫入磁碟 | 9 |
| 存在於記憶體中（緩衝） | 3 |
| 即時模式且無檔案 | 5 |
| 組態中沒有 Start 值（不會啟動） | 3 |
依登錄檔啟用的兩個 Defender 工作階段實際上不會啟動：防護機制會以自身權限較低的工作階段取代它們。
九個檔案型工作階段：誰寫入多少
Section titled “九個檔案型工作階段：誰寫入多少”| 工作階段 | 用途 | 佔用 | 特點 |
|---|---|---|---|
| Diagtrack-Listener | 遙測接收端 | 服務運作時沒有檔案 | 2 小時內約 110 MB 的事件交給遙測服務 |
| NetCore | 網路堆疊診斷 | 22 MB | 預先配置的檔案；已寫入約 2.5 MB 的事件 |
| RadioMgr | 無線模組狀態 | 6 MB | 預先配置；在沒有 WiFi 的機器上是空檔案 |
| WdiContextLog | 開機與 PnP 診斷 | 2.2 MB | 依開機次數輪替 |
| NtfsLog | NTFS 追蹤 | 1.7 MB | 輪替 8 個檔案；DiagTrack 之後唯一明顯的流量 |
| WiFiSession | WLAN 診斷 | 80 KB | 沒有 WiFi 時幾乎是空的 |
| LwtNetLog | 網路診斷 | 64 KB | |
| RdpIdd-Trace | RDP 圖形 | 64 KB | |
| ReFSLog | ReFS 追蹤 | 4 KB | 沒有 ReFS 磁碟區時不會寫入 |
合計，作用中自動記錄器的檔案佔用 32 MB，其中 28 MB 是 NetCore 與 RadioMgr 的預先配置：這種大小的檔案永遠存在，與實際的事件量無關。
Diagtrack-Listener：沒有檔案的沉重流量
Section titled “Diagtrack-Listener：沒有檔案的沉重流量”只要遙測服務在運作，它就會以即時模式接管該工作階段：沒有檔案，但事件流量並未消失——2 小時內約 110 MB。該工作階段連接了 254 個提供者，其中大多數啟用了最高記錄層級。如果停用遙測服務，自動記錄器將繼續寫入檔案而沒有取用者——因此必須連同服務一起關閉它。
層級與提供者
Section titled “層級與提供者”記錄層級並非設定在工作階段上，而是設定在提供者上。在 1115 個已註冊的提供者中，有 607 個未出現在任何自動記錄器中——它們只在 runtime 工作階段中連接。在 1049 筆「工作階段中的提供者」記錄中，有 425 筆是沒有註冊名稱的 GUID，主要是遙測的情境識別碼。
已證實的部分
Section titled “已證實的部分”- 已觀察： 登錄檔中有 39 個工作階段，19 個已啟用，17 個實際已啟動，9 個寫入磁碟。
- 已測量： 作用中自動記錄器的檔案佔用 32 MB；其中 28 MB 是 NetCore 與 RadioMgr 的預先配置。
- 已測量： 在遙測服務運作時，Diagtrack-Listener 在 2 小時內寫入約 110 MB 的事件。
- 已觀察： 兩個 Defender 工作階段因防護機制的取代而不會啟動。
未證實的部分
Section titled “未證實的部分”- 其他組建與組態（WiFi、ReFS、RDP 負載）上的組成與容量。
- 輪替檔案在多次開機後的長期成長。
- 停用個別工作階段對問題可診斷性的影響：在本研究中我們並未停用任何工作階段。
單一次開機後 2 小時的單一快照；夜間與維護時段並未呈現。Diagtrack-Listener 的容量估計是依據緩衝區，而非檔案。預先配置的檔案永遠存在，但其大小並非對「已寫入」容量的測量。
大規模「停用所有自動記錄器」沒有意義：大多數工作階段本來就不寫入磁碟，而三個真正沉重的來源是針對性的。如果目標是減少遙測，請將 Diagtrack-Listener 連同遙測服務一起停用：在 BoosterX 中，這由設定 「背景 ETW 自動記錄器」 完成。如果目標是磁碟空間，請注意 32 MB 中有 28 MB 是兩個檔案的預先配置，而不是持續成長的日誌。其餘檔案型工作階段（NTFS、WDI、網路）的診斷價值，我們會評價得高於其磁碟成本。
本研究純屬觀察性：沒有任何工作階段被停用或變更。系統維持在原始狀態。
目錄由 BoosterX Research 在所描述的虛擬機器上彙整。本研究屬於 BoosterX 開發者，開發者對結果有直接利益；方法與限制已於上文說明。
- Microsoft: Configuring and Starting an Autologger Session，查核於 2026-09-22。
- Microsoft: Event Tracing，查核於 2026-09-22。
最後查核：2026-09-22。