Windows I/O 的深層(第 6 回・最終回) ── 迷你篩選驅動程式的機制與用 Procmon 調查延遲

只是開個檔案，在某些電腦上卻要等上一段時間。裝了防毒軟體的環境裡，建置與大量檔案複製會變慢。另一方面，啟動 Process Monitor 之後，明明沒有改動自己的應用程式，卻能看到檔案操作的記錄。

理解這兩件事的線索，是在檔案 I/O 的途中進行監控與控制的檔案系統篩選驅動程式。Windows 為此準備了專門的擴充點。¹

在系列「Windows I/O 的深層」的最終回，我們要談的是目前標準的實作方式——迷你篩選驅動程式。前半段先弄清機制，後半段接著講如何用 fltmc 與 Procmon 調查「在哪個環境、哪個操作變慢」。即使是不開發驅動程式的應用程式開發者，這也能當成釐清效能問題的一張地圖。

1. 先講結論

迷你篩選驅動程式，是向 Windows 內建的篩選管理員（FltMgr）註冊「要處理哪個操作、在哪個階段處理」的驅動程式。FltMgr 會依照註冊內容，以及名為高度的相對位置指定來呼叫回呼。從應用程式看來是同一個檔案操作，途中某個篩選驅動程式的處理，仍可能影響結果與耗時。²

不過，「有篩選驅動程式」和「這個篩選驅動程式就是變慢的原因」是兩回事。 fltmc 是確認組成的工具，Procmon 是觀察操作的工具。兩者都不是靠一份清單或單一數值就能斷定原因的工具。

本文以下面這組區分為主軸往下讀。

圖中實線表示始終成立的關係，虛線表示附帶條件的關係（成立條件寫在詳細頁面中各關係的說明中）。關係的完整清單（共 34 條，附依據與可信度）以及主要概念的定義，彙整在知識地圖詳細頁面（日文）。資料：JSON-LD / Turtle

2. 夾在中間者的歷史 ── 從傳統篩選驅動程式到 FltMgr

檔案系統篩選驅動程式，是監控與控制發往檔案系統或其他篩選驅動程式之要求的驅動程式。它用在防毒、加密、備份等地方，除了記錄要求，還能變更參數、拒絕存取。這裡說的「插進來」不是 CPU 的硬體中斷，而是介入 I/O 的處理路徑的意思。¹

在傳統方式下，篩選驅動程式自己把裝置物件附加到裝置堆疊上，負責把要求往下層傳遞，或處理完成。從附加順序、安全卸除，到與其他篩選驅動程式共存，實作方要處理的範圍很廣。

相對地，在迷你篩選驅動程式方式下，附加到堆疊之類的共通處理由 FltMgr 承擔，各個驅動程式只註冊所需操作的回呼。 迷你篩選驅動程式同樣是核心模式的驅動程式，驅動程式物件並不會消失。改變的是參與檔案系統堆疊的那套機制。³

flowchart TB
    accTitle: 傳統方式與迷你篩選驅動程式方式
    accDescr: 對比傳統方式下篩選驅動程式自己附加到堆疊，以及迷你篩選驅動程式方式下向 FltMgr 註冊處理的圖。
    ROOT["參與檔案 I/O 的方式"]
    ROOT -->|"傳統方式"| LEG["篩選驅動程式自己附加"]
    ROOT -->|"迷你篩選驅動程式方式"| MINI["向 FltMgr 註冊處理"]
    LEG --> OWN["自行實作附加與完成處理"]
    MINI --> SHARED["FltMgr 負責共通處理"]

圖 1：篩選驅動程式自己附加到堆疊的方式，與向 FltMgr 註冊處理的方式的對比。

圖中呈現的是由 FltMgr 代替迷你篩選驅動程式附加到堆疊上的結構。實際上，為了與傳統篩選驅動程式共存，FltMgr 也可能以多個框架的形式附加到不同位置。共存在配置上有其限制，光是改用迷你篩選驅動程式，並不能解決所有的搭配問題。²

FltMgr 抑制了載入順序造成的位置不穩定，也支援在運轉期間卸載。不過，能被卸除的只有實作了對應回呼並允許卸載的驅動程式。這並不保證調查過程中可以隨意卸下任何一個篩選驅動程式。³

3. 迷你篩選驅動程式的運作 ── pre/post 回呼

迷你篩選驅動程式會把例如對應 IRP_MJ_CREATE 的開啟、建立操作，或對應 IRP_MJ_WRITE 的寫入操作註冊為處理對象。pre 回呼是往下層傳遞之前的處理，post 回呼則是結果從下層回來的階段的處理。兩邊都註冊可以，只註冊需要的一邊也可以。²

下圖是 A 與 B 都處理同一個操作，並在 pre 中把要求往下層傳遞、同時要求呼叫 post 的情況。

sequenceDiagram
    accTitle: 往下層傳遞並接收完成時的回呼順序
    accDescr: A 與 B 都註冊了目標操作、把要求往下層傳遞並要求 post 時，pre 從高度高的一側開始呼叫，post 則依相反順序呼叫。
    participant FM as FltMgr
    participant A as 篩選驅動程式 A（高）
    participant B as 篩選驅動程式 B（低）
    participant FS as 檔案系統
    FM->>A: pre
    FM->>B: pre
    FM->>FS: 往下層傳遞
    FS-->>FM: 處理結果
    FM-->>B: post
    FM-->>A: post

圖 2：通常的一去一回中，pre 從高度高的依序呼叫到低的，post 則是相反順序。並不是所有要求都會發生這樣的一去一回。

pre 的傳回值決定後續的處理。把代表性的幾種整理一下，如下所示。⁴⁵

如果某個篩選驅動程式在 pre 就完成了要求，要求便不會再往比它更下層的篩選驅動程式與檔案系統前進。傳回 FLT_PREOP_COMPLETE 的篩選驅動程式自己的 post 也不會被呼叫，完成結果會回到已經收下要求並要求了 post 的上層那一側。因此，重要的是不要認為「既然註冊了，pre 和 post 就一定都會被呼叫」。⁴

另外，擱置並不只是單純多加一段等待時間。擱置要求的驅動程式有責任讓要求被妥善地恢復與完成。實作時還要處理操作類型、IRQL、緩衝區的存留期、取消等限制。本文的表格是處理的概觀，並不能直接當作實作步驟。⁵

3.1 快速 I/O 也在範圍內，但不等於「所有 I/O 都看得到」

FltMgr 處理的不只是以 IRP 為基礎的 I/O，也包含快速 I/O 與檔案系統篩選（FSFilter）的回呼操作。「這條路徑不使用 IRP，所以迷你篩選驅動程式看不到」這種理解是錯的。反過來，認為所有存取都必然變成 IRP、都會通過同一串回呼，也並不正確。²

可觀察的範圍，會隨著所附加的磁碟區、註冊的操作、註冊時的排除條件、要求是否在上層就已完成等因素而改變。對記憶體對應檔案的每一次記憶體存取，也不會每次都被記錄成一個檔案 I/O 事件。傳統篩選驅動程式同樣有處理快速 I/O 的機制，支援快速 I/O 這件事本身，並不是迷你篩選驅動程式獨有的功能。³⁶

4. 高度 ── 「海拔」決定順序

如果同一個操作有多個篩選驅動程式參與，就必須決定按什麼順序處理。指定這個相對位置的就是高度（altitude）。數值越大，位置離檔案系統越遠；數值越小則越近。它不是執行緒的優先權，也不是表示該產品效能或重要程度的數值。⁷

這項設定寫在驅動程式的執行個體定義裡，實際附加到某個磁碟區之後就成為執行個體。同一份定義會套用到多個磁碟區，因此並不是為每個磁碟區各自發放不同的高度。 一個驅動程式也可以擁有多份定義，但取得多個高度並不是常見的用法。⁷

依用途劃分的載入順序群組與編號區間，規定如下。

flowchart TB
    accTitle: 迷你篩選驅動程式依用途劃分的高度區間
    accDescr: 數值越高，相對位置離檔案系統越遠。圖中只是部分群組的節錄，未涵蓋從最上層到最下層的全部區間。
    TOP["數值較大的一側"] --> M["Activity Monitor：360000〜389999"]
    M --> U["Undelete：340000〜349999"]
    U --> AV["Anti-Virus：320000〜329999"]
    AV --> R["Replication：300000〜309999"]
    R --> B["Continuous Backup：280000〜289999"]
    B --> LOW["繼續往下的依用途劃分的群組"]

圖 3：依用途劃分的高度區間節錄。實際上 Activity Monitor 之上還有別的區間，監控類的篩選驅動程式並不總是位於整個堆疊的最上層。

第一個高度要向 Microsoft 申請。如果在同一個載入順序群組裡已經被分配到整數值，也有機制可以在該值上加上小數部分做出新的高度，再通知 Microsoft。這並不表示沒有既有整數值的開發者可以自由使用任意編號。⁷

開發時，請依照 Request a Filter Altitude Identifier 的說明，寄一封主旨為 Filter altitude request 的 ASCII 純文字郵件到 fsfcomm@microsoft.com。信中要填寫公司名稱、可長期使用的公司聯絡方式、產品名稱與 URL、說明、驅動程式檔名、篩選驅動程式類型、啟動類型、希望的群組與編號等。官方說明中需要預留 30 個工作天的處理時間，而且未必能拿到希望的編號。這是在開發與發布的規劃階段就該先確認好的項目。⁸

5. 住客介紹 ── 用 fltmc 看看你的電腦

弄懂機制之後，來確認實際的組成。以系統管理員身分開啟命令提示字元，執行下面這幾條唯讀的命令。⁹¹⁰

:: 已載入的檔案系統篩選驅動程式清單
fltmc filters

:: 篩選驅動程式與磁碟區的附加狀況
fltmc instances

:: 磁碟區清單
fltmc volumes

fltmc filters 與不帶引數的 fltmc 輸出的是同一份清單。下面是用來說明各欄讀法的範例，不是這次在實機上的測量結果。高度使用的是公開的分配值，各行的組成與執行個體數量只是舉例。¹¹

Filter Name                     Num Instances    Altitude    Frame
------------------------------  -------------  ------------  -----
bindflt                                 1        409800         0
cldflt                                  1        409500         0
WdFilter                                4        328010         0
luafv                                   1        135000         0
FileInfo                                4         45000         0

名字出現在 filters 裡，和它有沒有附加到放著問題檔案的那個磁碟區上，要分開確認。比較組成時要一路看到 instances，這是重點。就算確認了附加對象，也還是不知道它對該操作註冊了哪些回呼、實際做了什麼處理。¹⁰

5.1 常見的篩選驅動程式

WdFilter 是 Microsoft Defender 的篩選驅動程式，分配到的是 Anti-Virus 區間的 328010。cldflt 是支撐 Cloud Files API 的雲端檔案篩選驅動程式，分配到的是 409500。在 OneDrive 的隨選檔案中，本機的預留位置會與同步提供者協同運作，取得所需的資料。這並不表示每次開啟檔案都必定會下載整個檔案。¹¹¹²

Procmon 的檔案系統監控同樣使用迷你篩選驅動程式。比較啟動前後的 fltmc filters，在某些環境下可以看到名稱以 PROCMON 開頭的驅動程式。不要把結尾的編號以及載入、卸載的時機當成固定的，請確認手邊的實際狀態。

不過，Procmon 對登錄檔以及處理程序、執行緒的監控，並不是全都由檔案系統用的迷你篩選驅動程式實現的。另外，Procmon 裡的一行並不代表一次實體磁碟存取。觀察檔案操作和觀察儲存裝置的動作，是不同的層次。¹³

6. 防毒軟體把時間花在哪裡

如果組成是在檔案操作途中等待掃描結果，那段等待時間就包含在應用程式做完該操作為止的時間裡。在大量建立、更新小檔案的建置中，一件一件的檢查處理也可能累積起來。不過，並沒有規定每次存取都要把整個檔案重讀一遍，掃描的條件與時機會隨產品與設定而不同。¹⁴

下面是把開啟後的檢查放在把結果回傳給應用程式之前執行的概念圖。它不是呈現特定產品內部實作的圖，也不保證所有檔案的處理順序。

sequenceDiagram
    accTitle: 等待掃描結果後才完成開啟的組成範例
    accDescr: 舉例說明在 post-create 進行檢查的產品組成。它不是呈現所有產品實作的圖，也不表示每次都必定掃描。
    participant APP as 應用程式
    participant AV as AV 迷你篩選驅動程式
    participant FS as 檔案系統
    APP->>AV: 開啟檔案
    AV->>FS: 確認條件後往下層傳遞
    FS-->>AV: 開啟成立
    Note over AV: 本例中在 post-create 等待檢查結果
    alt 檢查允許通過時
        AV-->>APP: 成功結果
    else 需要拒絕時
        Note over AV: 依照限制取消這次開啟
        Note over AV: 不會復原建立與覆寫造成的變更
        AV-->>APP: 失敗結果
    end

圖 4：在 post-create 等待檢查結果的組成範例。實際的檢查條件與時機隨產品而不同，光憑這一點無法找出延遲的原因。

技術上，可以在成功的 create 的 post 回呼裡呼叫 FltCancelFileOpen，設定失敗狀態，把這次開啟當成失敗來處理。不過，這不是把檔案變更復原的功能。它不會刪除新建立的檔案，也不會還原覆寫之前的內容，而且呼叫本身還有必須在建立控制代碼之前等限制。¹⁵

6.1 排除設定不是「把篩選驅動程式撤掉」

排除設定的作用，是減少該設定所套用之掃描的對象。它不是把篩選驅動程式本身從堆疊上卸除的設定，也不是對其他廠商的 EDR、備份、加密篩選驅動程式等一體適用的設定。即使在同一個產品系列裡，也不能把防毒的排除和其他保護功能的排除視為同一件事。¹⁴

因此，設了排除仍然很慢時，該想的並不一定是「設定壞掉了」。套用對象、管理原則、別的篩選驅動程式、檔案系統、網路、應用程式那一側的等待等等，都還有確認的空間。反過來說，就算排除之後變快了，光憑這個結果也不能斷言不存在掃描以外的因素。

不要把大範圍排除或停用保護功能當成調查的第一步。 先把日誌與重現條件記錄下來，如果確實需要變更，就在與系統管理員確認過風險之後，訂好範圍、期限與復原的步驟。誤判的處理在「自行開發的 Windows 應用程式被當成病毒時」也有談到。¹⁴

6.2 Dev Drive 是有條件地降低掃描影響的選項

存放開發用檔案的地方，也可以把 Dev Drive 納入考慮。Microsoft Defender 的效能模式會把對相應檔案開啟操作的掃描改為非同步執行，在保留保護的同時降低對效能的影響。Microsoft 把它定位成開發用途中資料夾排除的更安全替代方案。¹⁶¹⁷

不過前提是：它是受信任的 Dev Drive、Defender 作為主要的防毒軟體在運作、即時保護處於啟用狀態等等。指定一般的 NTFS 資料夾並不會得到同樣的行為，也不是所有防毒產品都會切換成非同步掃描。 在 Dev Drive 上還要確認篩選驅動程式的附加原則，核實與所需資安產品、備份產品的相容性。¹⁷¹⁶

7. 調查「唯獨那個環境慢」

調查依找出慢操作 → 比較目標磁碟區的組成 → 用追加測量驗證候選的順序推進。不論是每次都慢，還是只有第一次慢、偶爾才慢，都不構成把篩選驅動程式從候選中剔除的理由。

7.1 先統一重現條件

比較之前，先記錄應用程式的版本、操作內容、輸入檔案、儲存位置、執行使用者，以及作業系統與資安產品的版本。不要把本機檔案與 UNC 路徑、尚未取得的雲端檔案與已經取到本機的檔案混在一起比較。

第一次和第二次以後也要分開。快取的狀態、同步的進度、有沒有其他處理在跑如果不同，同一個操作的耗時也可能改變。多重現幾次，把應用程式整體的經過時間，和採集追蹤的時間區段對應起來。

7.2 用 Procmon 找出慢操作

以系統管理員身分啟動 Procmon，先暫停擷取並清掉既有的事件。縮小對象範圍，只在重現所需操作的那段期間記錄然後停止，事後會比較容易回頭讀。基本操作也請參考「Process Monitor 實戰指南」。¹³

1. 在 Options > Select Columns… 中顯示 Duration 欄。
2. 在 Filter > Filter…(Ctrl+L) 中指定目標處理程序名稱或 PID，按 Add 之後再套用。如果實際的 I/O 是由子處理程序或服務執行的，就把它們也納入調查對象。
3. 開始擷取、重現症狀，然後停止。把 Operation、Path、Result、Duration 放在一起看，必要時用 Duration 的篩選條件或 Tools > File Summary 縮小範圍。

不要依賴「點一下事件清單的 Duration 標頭就能排序」這種步驟。對於大量短時間操作堆積起來的問題，只抽出 Duration 較長的項目會漏掉原因候選，所以也要確認件數。另外，CreateFile 不只出現在新建時，開啟既有檔案時也會出現。不要只看操作名稱，還要讀詳細資訊。¹³¹⁸

這裡的 Duration，是 Procmon 作為該事件所觀測到的操作耗時。它不是某個特定迷你篩選驅動程式單獨的執行時間。 其中可能包含下層檔案系統、裝置、網路等的等待。把並行操作的 Duration 相加，也不一定會等於應用程式整體的經過時間。

7.3 把 fltmc 的差異變成「候選」

在快的環境和慢的環境分別採集 fltmc filters 與 fltmc instances，比較附加在出問題的儲存位置上的篩選驅動程式。像下面這樣，把觀察到的事實與對它的解讀分開。

堆疊裡出現篩選驅動程式的名字，是調查該處理路徑的線索。但是，光是名字列在裡面，並不能證明這個驅動程式運轉了很長時間。必要時用 Windows Performance Recorder/Analyzer 等採集 CPU 執行與等待的狀況，再與產品的診斷資訊對照。¹⁹

懷疑 Defender 時，可以用官方的效能分析器確認掃描負擔較大的檔案與處理程序。在受支援的環境中以系統管理員身分開啟 PowerShell 開始記錄，用另外的操作重現症狀之後，按 Enter 停止。下面的例子還會建立存放記錄的資料夾。²⁰

$traceDirectory = Join-Path $env:TEMP 'DefenderPerformance'
New-Item -ItemType Directory -Path $traceDirectory -Force | Out-Null
$tracePath = Join-Path $traceDirectory ('scan-{0}.etl' -f (Get-Date -Format 'yyyyMMdd-HHmmss'))

# 在記錄過程中重現目標操作，按 Enter 停止記錄
New-MpPerformanceRecording -RecordTo $tracePath

# 確認對掃描影響較大的檔案
Get-MpPerformanceReport -Path $tracePath -TopFiles 10 -TopScansPerFile 5

這份報告呈現的，同樣只是關於 Defender 掃描的資訊。不要把排在前面的路徑直接搬進排除清單，而要確認它是否與重現時的緩慢有關聯。採集到的日誌裡可能包含檔案名稱、使用者名稱等，因此存放位置與分享對象也要留意。

透過變更設定來做比較，放在收集完上述證據之後。在正式環境試 fltmc unload，或是改寫高度來調整順序，都不作為通用的處理辦法。

8. 系列的總收尾 ── 六回的地圖

整個系列從應用程式的 API 呼叫開始，一路看過了名稱解析、I/O 要求、完成通知、快取和檔案系統。這一回的迷你篩選驅動程式，位在其中監控與控制發往檔案系統之要求的位置。

flowchart TB
    accTitle: Windows I/O 系列各回討論的觀點
    accDescr: 把各回主題關聯起來的概念圖。它不是一條執行路徑，也不表示所有 API 呼叫都會經過 IRP、磁碟與 IOCP。
    APP["應用程式的檔案操作"]
    SYNC["第 2 回：同步與非同步 I/O"]
    IOM["第 1 回：I/O 管理員與 IRP"]
    FLT["第 6 回：FltMgr 與迷你篩選驅動程式"]
    FS["第 5 回：NTFS 的內部結構"]
    CACHE["第 4 回：快取管理員"]
    IOCP["第 3 回：IOCP 與完成後的處理"]
    APP -. "呼叫方式" .-> SYNC
    APP -. "要求處理的結構" .-> IOM
    IOM -. "檔案 I/O 的監控與控制" .-> FLT
    FLT -. "往下層前進時" .-> FS
    FS -. "在啟用快取的 I/O 中協同" .- CACHE
    SYNC -. "對應的完成通知方式" .-> IOCP

圖 5：呈現系列各回關係的概念圖。並不是所有 I/O 都會經過所有方框，也存在不存取裝置、不伴隨中斷就完成的路徑。IOCP 同樣是在對應的控制代碼與通知設定下使用的完成通知機制。

這張圖不是一次執行追蹤。快速 I/O、可以由快取處理的要求、不往下層傳遞就完成的要求等等，路徑都不一樣。不要把 API 呼叫、檔案系統操作、IRP 和實體磁碟存取一對一對應起來，這是串起各回時的注意事項。²

• 第 1 回：I/O 系統的全貌 ── 名稱解析、物件、IRP 與裝置堆疊
• 第 2 回：同步與非同步 I/O ── 控制代碼的模式、OVERLAPPED、完成的處理
• 第 3 回：IOCP 與 .NET 執行緒集區 ── 完成通知與處理的接續
• 第 4 回：快取管理員 ── 寫入、快取、落實到儲存體
• 第 5 回：NTFS 的內部結構 ── MFT、串流、連結、日誌
• 第 6 回：迷你篩選驅動程式（本文） ── 檔案 I/O 的監控與控制，以及與環境相關的延遲調查

9. 總結 ── 系列的結語

迷你篩選驅動程式透過 FltMgr 提供的回呼參與檔案 I/O。通常的一去一回中，pre 從高度高的依序呼叫到低的，post 則是相反順序，但實際的路徑會隨註冊內容與途中完成而改變。

了解這套機制之後，就能說明為什麼 Procmon 裡會出現檔案操作，以及資安產品為什麼可能影響檔案存取的耗時。同時，能監控的範圍，以及光憑那些觀測無法判斷的事也會跟著浮現。

遇到「只有特定環境慢」時，用 Procmon 縮小操作範圍，用 fltmc instances 確認附加對象，再用產品的診斷功能與條件一致的比較來佐證。排除設定與 Dev Drive 則放在之後，確認過套用條件與對保護的影響再做選擇。按這個順序，就能在不靠猜測削弱保護的前提下把調查推進下去。

系列裡談的這些結構，不是為了把原因一口咬定成某一個，而是用來判斷下一步該測哪裡的地圖。把應用程式裡一行程式碼底下可能發生的事分開來想，是把缺陷與效能問題變成可重現、可說明的形式的第一步。

相關文章

• Windows I/O 的深層（第 1 回）：I/O 系統的全貌
• Windows I/O 的深層（第 4 回）：快取管理員
• Windows I/O 的深層（第 5 回）：NTFS 的內部結構
• Process Monitor 實戰指南
• Microsoft Defender 的誤判處理與效能影響
• 用 Process Explorer、Handle、VMMap 進行調查
• Windows 應用程式的最低限度資安檢核表

相關諮詢領域

合同會社小村軟體承接「只有客戶端的電腦檔案操作很慢」「導入資安產品之後行為就變了」這類 Windows 業務應用程式的效能問題與缺陷調查。即使還處在不清楚原因是篩選驅動程式，還是應用程式、檔案系統、網路的階段，也可以成為調查對象。

聯絡我們時，請在您了解的範圍內告知：會變慢的操作、會發生與不會發生的環境、用的是本機、共用資料夾還是雲端，以及已導入的資安產品。包含機密資訊的日誌與檔案的分享方式，請先與我們討論。

• Windows 應用程式開發
• 缺陷調查・原因分析
• 技術諮詢

參考連結

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

檔案系統篩選驅動程式和迷你篩選驅動程式有什麼不同？

檔案系統篩選驅動程式是監控與控制檔案 I/O 的驅動程式的統稱。迷你篩選驅動程式是其中一種實作方式，它按操作向 Windows 的篩選管理員（FltMgr）註冊回呼。與傳統方式的主要差別在於，附加到堆疊以及完成處理等共通處理由 FltMgr 負責。迷你篩選驅動程式彼此之間的相對位置由高度決定。運轉期間的卸載，僅限該驅動程式有實作對應支援並允許被卸除的情況。

防毒軟體是否每次都會掃描所有的檔案存取？

並不一定。迷你篩選驅動程式是否被呼叫，取決於所附加的磁碟區、註冊的操作等條件。在此之上要掃描什麼，還會隨產品的原則、檔案的變更狀態、排除設定等而改變。存在監控檔案 I/O 的機制，和每次存取都重新掃描整個檔案，是兩回事。

防毒軟體的排除設定，是把篩選驅動程式卸除的設定嗎？

通常不是。它是針對排除對象，用來省略該設定所套用之掃描的設定。它也不會把其他產品的 EDR、備份、加密等一併關閉。排除的適用範圍隨產品與保護功能而不同，大範圍的資料夾排除會削弱保護。效能調查要先測量，需要變更設定時，只在與系統管理員達成共識的最小範圍內進行。

只用 Process Monitor 能找出慢的篩選驅動程式嗎？

Procmon 有助於找出慢操作與目標路徑，但 Duration 並不是個別迷你篩選驅動程式的處理時間。光是堆疊裡出現某個驅動程式的名字，也無法斷定原因。還要用 fltmc 確認它是否附加到目標磁碟區，再用產品的診斷功能、追加的追蹤以及條件一致的比較來佐證。另外，Procmon 的記錄並不能毫無遺漏地呈現對實體磁碟的全部存取。

建置很慢時，移到 Dev Drive 上就一定會改善嗎？

未必一定會改善。Microsoft Defender 的效能模式以受信任的 Dev Drive、Defender 作為主要的防毒軟體運作、即時保護處於啟用狀態等為前提。它把對相應檔案開啟操作的掃描改為非同步執行以降低影響，但並不是能解決其他廠商產品的行為，或 CPU、網路等別的瓶頸的功能。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。