Windows I/O 的深層(第 6 回・最終回) ── 篩選驅動程式與迷你篩選驅動程式：Procmon 與病毒掃描為何能夠介入 I/O

本文是系列文章「Windows I/O 的深層」的最終回。

自從第 1 回裝置堆疊圖中畫出「檔案系統篩選驅動程式(防毒軟體・加密・Procmon 等)」這個方框以來,本系列中夾在中間的角色已經數度登場:Procmon 能夠記錄全部 I/O 的理由(第 1 回)。「唯獨那個環境的檔案存取很慢」(第 2 回)。一開啟就讓 OneDrive 開始下載的重新解析點(第 5 回)。這一回終於要正面處理這套介入機制本身──檔案系統篩選驅動程式與迷你篩選驅動程式──把本系列埋下的所有伏筆全數回收。

1. 先講結論

• 「介入 I/O」是作業系統官方認可的擴充點。檔案系統篩選驅動程式可以檢視、改寫、拒絕,並代為處理對檔案系統的要求(第 2 章)。¹
• 現在的標準是迷你篩選驅動程式。為了解決直接介入裝置堆疊的傳統方式所帶來的問題(順序不確定、無法解除安裝),已世代交替為向 Windows 內建的篩選管理員(FltMgr)註冊回呼的方式(第 2 章)。²³
• 運作方式是 pre/post 回呼。在每個操作的前後,會依註冊順序＝海拔順序被呼叫。放行、完成、拒絕、改寫──第 1 回看到的「驅動程式的選項」原封不動地適用於此(第 3 章)。²
• 海拔(標高)決定順序。依用途分組並分配編號區間(Activity Monitor 為 360000～389999、Anti-Virus 為 320000～329999 等),每個附加到磁碟區的執行個體都會有一個唯一的編號(第 4 章)。⁴⁵
• 你電腦裡的住客,可以用 fltmc 查看。Procmon(僅限執行期間)、防毒軟體、OneDrive 的雲端篩選驅動程式──全部都會列在這裡(第 5 章)。
• 防毒軟體的除外設定,指的是「省略該產品自身的掃描」,並不會影響其他迷你篩選驅動程式。除外是會削弱保護的取捨,開發用磁碟區則有 Dev Drive(非同步掃描)這個更安全的選項(第 6 章)。⁶⁷
• 「唯獨那個環境慢」的調查,要從 Procmon 的 Duration 欄和 fltmc 的構成比較開始(第 7 章)。

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

檔案系統篩選驅動程式是能夠攔截送往檔案系統(或其下方磁碟區)之要求的驅動程式。它可以記錄要求、監控要求、修改內容,甚至拒絕或代為處理──是防毒軟體、加密、備份、階層式儲存等軟體的基礎。¹

舊有的實作方式(傳統篩選驅動程式)是把自己的裝置物件直接堆疊在第 1 回看到的裝置堆疊上。機制本身很直觀,但實務上問題百出──堆疊的順序取決於載入順序,難以保證;一旦堆上去就無法安全脫離(無法解除安裝);還容易成為篩選驅動程式之間相容性錯誤的溫床。

因此 Windows 導入了篩選管理員(FltMgr)。FltMgr 本身以 Windows 內建篩選驅動程式的身分站上堆疊,各個篩選功能則以迷你篩選驅動程式的形式,向 FltMgr 註冊回呼。²

flowchart TB
    subgraph OLD["傳統方式"]
        L1["傳統篩選驅動程式 A"]
        L2["傳統篩選驅動程式 B"]
        LFS1["檔案系統"]
        L1 --> L2
        L2 --> LFS1
        NOTE1["順序全憑載入順序決定<br/>無法安全解除安裝"]
    end
    subgraph NEW["迷你篩選驅動程式方式－目前的標準"]
        FM["篩選管理員－FltMgr<br/>Windows 內建,只有它會出現在堆疊中"]
        M1["迷你篩選驅動程式 A,海拔較高"]
        M2["迷你篩選驅動程式 B,海拔較低"]
        LFS2["檔案系統"]
        FM -. "註冊回呼" .- M1
        FM -. "註冊回呼" .- M2
        FM --> LFS2
        NOTE2["順序由海拔決定<br/>可在任意時機載入<br/>支援解除安裝的篩選驅動程式也能解除安裝"]
    end

圖 1:世代交替。從「堆疊」在裝置堆疊上,轉為向 FltMgr「註冊」的方式

迷你篩選驅動程式方式的優點,官方文件已經明確列出──隨時都能載入、可以控制順序,若篩選驅動程式實作了解除安裝回呼,甚至能在執行期間解除安裝(未實作或拒絕解除安裝的篩選驅動程式則無法卸下)。³ 為了與傳統篩選驅動程式共存,FltMgr 可以化身為多個「框架(frame)」,出現在堆疊中的多個位置;而迷你篩選驅動程式即使解除安裝後重新載入,也保證會回到相同的位置(相同的海拔)。² 現今的防毒軟體、監控與同步軟體,幾乎全都是這種迷你篩選驅動程式。

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

迷你篩選驅動程式會向 FltMgr 宣告「自己對哪些操作感興趣」。例如只對 IRP_MJ_CREATE(開啟)和 IRP_MJ_WRITE(寫入)感興趣。如此一來,每當該操作流過時,就會呼叫操作之前(pre 回呼)與操作之後(post 回呼)。

sequenceDiagram
    participant IOM as I/O 管理員
    participant FM as FltMgr
    participant A as 迷你篩選驅動程式 A<br/>(海拔較高)
    participant B as 迷你篩選驅動程式 B<br/>(海拔較低)
    participant FS as NTFS

    IOM->>FM: 要求(IRP_MJ_CREATE 等,第 1 回的世界)
    FM->>A: pre 回呼
    FM->>B: pre 回呼
    FM->>FS: 送往檔案系統
    FS-->>FM: 處理結果
    FM-->>B: post 回呼
    FM-->>A: post 回呼
    FM-->>IOM: 完成(回到第 1 回的完成流程)

圖 2:pre/post 回呼。去程依海拔由高至低呼叫,回程則依相反順序呼叫

各個回呼能做些什麼?與第 1 回 4.3 節「驅動程式的三個選項」相同的架構,這裡以更安全的 API 提供。

flowchart TB
    PRE["呼叫了 pre 回呼"]
    Q{"這個操作要怎麼處理"}
    PASS["直接放行<br/>不需要 post 的話也一併宣告"]
    DENY["拒絕<br/>立即回傳存取拒絕等結果<br/>例如偵測到病毒、禁止寫入"]
    DONE["自行完成<br/>例如雲端篩選驅動程式<br/>取得實體後直接交出"]
    MOD["修改參數或內容後再放行<br/>例如加密篩選驅動程式"]
    PRE --> Q
    Q --> PASS
    Q --> DENY
    Q --> DONE
    Q --> MOD

圖 3:pre 回呼的選項。「檢視、阻止、代為處理、改寫」全部都是官方支援的做法

而第 4 回留下的作業,也在這裡得到回收──迷你篩選驅動程式連快速 I/O(不建立 IRP 的捷徑)也能列席。這是因為 FltMgr 讓回呼機制也貫通了快速 I/O 路徑,不會像傳統篩選驅動程式時代那樣,「一旦走捷徑就看不見」。Procmon 記錄檔中之所以會連 FASTIO_ 這一行都排列出來,正是拜這個立足點所賜。

4. 海拔(Altitude) ── 「海拔」決定順序

當多個篩選驅動程式對同一個操作感興趣時,誰先看到是個重大問題。如果防毒軟體不比加密更早看到內容,就會落得掃描密文的下場;監控工具若不站在所有人之上,就無法觀察到全貌。

決定這個順序的,就是海拔(altitude,標高)。每一種篩選驅動程式都定義了載入順序群組與編號區間。更精確地說,被賦予海拔的單位並不是整個驅動程式,而是附加到磁碟區的迷你篩選驅動程式「執行個體」。編號是唯一的,數字越大,就位在堆疊越上層(越靠近應用程式)。⁴ 一個驅動程式可以擁有多個執行個體定義,並以不同的海拔出現在多個位置,這也是為什麼 fltmc instances 的清單是以執行個體為單位列出的。

flowchart TB
    APP["偏向應用程式端,數字較大"]
    G1["FSFilter Activity Monitor,360000～389999<br/>觀察與記錄 I/O,Procmon 就在這裡"]
    G2["FSFilter Undelete,340000～349999<br/>復原已刪除的檔案"]
    G3["FSFilter Anti-Virus,320000～329999<br/>偵測與清除病毒"]
    G4["FSFilter Replication,300000～309999<br/>複製到遠端"]
    G5["FSFilter Continuous Backup,280000～289999<br/>持續備份"]
    G6["再往下還有 Content Screener、<br/>Quota Management、System Recovery、<br/>加密與壓縮等區段"]
    FS["偏向檔案系統端,數字較小"]
    APP --> G1 --> G2 --> G3 --> G4 --> G5 --> G6 --> FS

圖 4:海拔區間(節錄)。每種用途都有其應站上的「海拔」

重要的是,這個編號是由Microsoft 統一分配與管理的。⁵ 廠商不是自行認定,而是要申請並取得──因此不論在哪一台電腦上,都能維持「監控在防毒軟體之上、防毒軟體在加密之上」的秩序。這正是對傳統篩選驅動程式時代「載入順序全憑運氣」問題的解答。

自行開發迷你篩選驅動程式時的申請管道。這裡只為開發者寫下下一步該怎麼做。海拔的申請要依照 Request a Filter Altitude Identifier 的步驟,把郵件主旨設為「Filter altitude request」,寄英文郵件到 fsfcomm@microsoft.com 申請。必須填寫公司名稱、聯絡方式(不是個人信箱,而是可長期使用的公司別名)、產品名稱、產品網址、篩選驅動程式的說明、驅動程式的檔案名稱、篩選驅動程式類型、啟動類型,以及希望的載入順序群組與希望的海拔,所有欄位都要填齊。文件中也明確寫著處理需預留 30 個工作天、沒有加急受理窗口,以及實際分配到的編號可能與希望不同。⁸ 另外,如果公司在同一個載入順序群組中已經擁有整數的海拔,就可以自行在該編號後面加上小數(例如 325000.3),這種情況只要事後寄信通知即可。⁸

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

道理先講到這裡,來看看實物吧。在具有系統管理員權限的命令提示字元中:

:: 已註冊的迷你篩選驅動程式清單(附海拔)
fltmc

:: 哪個磁碟區附加了哪個篩選驅動程式
fltmc instances

:: 從磁碟區的角度來看
fltmc volumes

不帶引數的 fltmc 會輸出和 fltmc filters 相同的清單。輸出共有 4 欄,Microsoft 的文件中也刊載了相同格式的範例。⁹

C:\Windows\system32>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

以上是用於說明的節錄。列出的成員與執行個體數量因環境而異,但海拔的數值是 Microsoft 分配的固定值,因此可以和第 4 章提到的公開清單互相對照。

各欄位的意義如下。

光是這 5 行,就能看出 bindflt 和 cldflt 位在最上層的 FSFilter Top 區間(400000～409999)、WdFilter 位在 Anti-Virus 區間(320000～329999)、FileInfo 則位在最底層的 FSFilter Bottom 區間(40000～49999)。第 4 章看到的「每種用途都有應站上的海拔」這個架構,就這樣直接透過數字獲得了確認。而且只要先啟動 Procmon,再重新執行一次 fltmc,就會在 Activity Monitor 區間(360000～389999)多出一行以 PROCMON 開頭的項目。

雖然環境不同、成員也不同,但典型的住客都是本系列的常客。

• WdFilter ── Microsoft Defender 的迷你篩選驅動程式。位在 Anti-Virus 區間。在許多電腦上,是所有檔案 I/O 都必定會經過的關卡。
• cldflt ── 雲端檔案的篩選驅動程式。是 OneDrive 檔案隨選下載的執行部隊,在第 5 回看到的重新解析點(佔位符)被開啟時,負責準備實體內容。¹⁰
• PROCMON24(等) ── 只有在執行 Process Monitor 期間才會出現的、Activity Monitor 區間中的暫時性迷你篩選驅動程式。Procmon 能夠看到全部 I/O 的謎底就在這裡。¹¹ 請試著在啟動前後分別執行 fltmc 來比較看看。
• 除此之外,還有備份軟體、加密(資訊外洩防護)產品、EDR、虛擬化儲存等──業務用電腦的住客往往更多。

把從第 1 回就開始使用的 Procmon 這項工具,在最終回從工具箱外重新審視一次,會發現這是一個漂亮的循環──「觀察者,其實也是與觀察對象同一套機制下的住客」。

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

篩選驅動程式在實務上影響最大的,就是防毒軟體的掃描成本。以下用圖來說明時間發生在哪裡(細節依產品而異,以下是典型的形態)。

sequenceDiagram
    participant App as 應用程式
    participant AV as AV 迷你篩選驅動程式
    participant FS as NTFS

    App->>AV: 開啟檔案
    Note over AV: pre-create:路徑與原則的事前判定
    AV->>FS: 放行(執行開啟)
    FS-->>AV: 開啟成立(post-create)
    Note over AV: 若是尚未掃描的檔案<br/>就在這裡掃描內容<br/>有問題就取消這次開啟<br/>── 開啟變慢的主因
    AV-->>App: 沒有問題就回傳控制代碼
    App->>AV: 寫入、關閉
    Note over AV: 已變更的檔案<br/>會在關閉等時機成為重新掃描的對象
    Note over App,FS: 若是大量小檔案(例如建置的中間產物)<br/>這一來一往就會依檔案數量不斷累加

圖 5:掃描成本的發生點。單一檔案的成本雖小,但數萬個檔案累積起來就會成為主導因素

在此基礎上,就能正確理解兩個實務主題。

除外設定的技術意義。對於符合除外清單路徑的 I/O,篩選驅動程式的掃描處理會被省略。篩選驅動程式並不會從堆疊中消失,實際情況比較接近「不檢查」這個判斷提早被做出。而且還有一個重要的限定──除外只對擁有該設定的產品自身的篩選驅動程式有效。Microsoft Defender 的除外設定改變的是 WdFilter 的掃描,對同時運作的其他迷你篩選驅動程式(其他廠商的防毒軟體、EDR、備份、加密等)的行為完全沒有影響。當出現「設定了除外卻依然很慢」的情況時,請懷疑是不是有另一個住客在耗費時間(第 7 章的 fltmc 比較)。效果雖然很大,但除外必定會削弱該處的保護。Microsoft 的文件也反覆警告,除外會降低防護,因此應在評估風險之後控制在最小範圍。⁶ 誤判因應與效能影響的實務,在「自行開發的 Windows 應用程式被當成病毒處理時」中有詳細討論。

Dev Drive 這個新解答。這是專為開發工作負載(大量小檔案)設計的專用磁碟區,Microsoft Defender 會以效能模式(非同步掃描)運作。它被定位為資料夾除外的更安全替代方案,預設不會有額外的篩選驅動程式附加上去,但文件中也明確強烈警告,不應該把所有篩選驅動程式都移除後運作。⁷ 這是 Microsoft 目前對「想加快建置速度,但又害怕使用除外」這個問題所推薦的解答。

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

最後,把本系列累積下來的工具整理成一套步驟。

flowchart TB
    S["症狀－同一個應用程式,卻只有特定環境的檔案存取變慢"]
    P1["在 Procmon 中查看 Duration 欄<br/>哪個操作－IRP_MJ_CREATE？WRITE？<br/>消耗掉了時間"]
    Q1{"特定操作一律都很慢?"}
    F1["用 fltmc instances 和速度快的環境比較<br/>找出篩選驅動程式構成的差異"]
    Q2{"差異中的篩選驅動程式是原因?"}
    A1["除外設定,需搭配風險評估,<br/>或考慮 Dev Drive、洽詢廠商"]
    A2["懷疑篩選驅動程式以外的原因－<br/>快取－第 4 回、片段化或 MFT－第 5 回、<br/>網路目的地 UNC、裝置本身"]
    S --> P1 --> Q1
    Q1 -->|"是"| F1 --> Q2
    Q2 -->|"是"| A1
    Q2 -->|"否"| A2
    Q1 -->|"否,屬於零星狀況"| A2

圖 6:篩選驅動程式導致的緩慢的排查。關鍵在於「以操作為單位的耗時」與「環境之間篩選驅動程式構成的差異」

重點有兩個。第一,Procmon 會記錄每個操作各自的耗時(Duration)。只要能把「慢」分解成「哪個操作慢」,找出犯人的工作就已經完成一半了。第二,環境之間的差異,很多時候就是篩選驅動程式構成的差異。開發機與正式機、自家電腦與客戶端電腦──只要把 fltmc 的輸出並排比對,就能看出該懷疑的候選對象。

沒用過 Procmon 時的最初三個步驟。Duration 欄預設不會顯示,為了不讓大家卡在這裡,先把操作方式寫下來。

1. 以系統管理員身分啟動 Procmon.exe。
2. 開啟 Options 選單 > Select Columns…,在欄位清單中勾選 Duration。
3. 在 Filter 選單 > Filter…(Ctrl+L) 中輸入 Process Name / is / 目標的 exe 名稱 / Include,先按下 Add 按鈕後再按 OK(不按 Add 的話條件不會生效)。

接著只要點擊 Duration 欄進行排序,最耗時的操作就會集中在上方。若要以處理程序或檔案為單位彙總,也可以使用 Tools 選單 > File Summary。ProcMon 的整體操作方式,整理在「Process Monitor(ProcMon)實戰指南」中。

8. 系列的總整理 ── 六回的地圖

至此,第 1 回畫出的地圖上所有方框都已經打開。把全貌整理成一張圖。

flowchart TB
    APP["應用程式<br/>ReadFile / WriteFile / async-await"]
    API["第 2 回－同步與非同步 I/O<br/>控制代碼模式與 OVERLAPPED"]
    IOCP["第 3 回－IOCP 與 .NET 執行緒集區<br/>接收完成通知並執行接續"]
    IOM["第 1 回－I/O 管理員與 IRP<br/>名稱解析、三種物件、裝置堆疊"]
    FLT["第 6 回－篩選驅動程式與迷你篩選驅動程式<br/>FltMgr、海拔、pre/post"]
    CACHE["第 4 回－快取管理員<br/>256KB 檢視、lazy writer、快速 I/O<br/>與 NTFS 協同運作"]
    NTFS["第 5 回－NTFS<br/>MFT、資料流、連結、兩種日誌"]
    HW["儲存堆疊與裝置"]
    APP --> API
    API --> IOM
    IOCP -. "完成會回到這裡" .-> APP
    IOM --> FLT
    FLT --> NTFS
    NTFS -. "已啟用快取的 I/O 會協同運作<br/>檔案系統會呼叫快取功能" .- CACHE
    NTFS --> HW
    HW -. "中斷→完成,第 1 回" .-> IOCP

圖 7:本系列全貌的地圖。快取管理員並不是「單純通過的層」,而是與檔案系統協同運作的夥伴,快取未命中時,會由 NTFS 向儲存體發出要求

• 第 1 回:全貌 ── 所有讀寫都會變成 IRP
• 第 2 回:同步/非同步 ── OVERLAPPED 真正的含意
• 第 3 回:IOCP ── async/await 的地下室
• 第 4 回:快取 ── 你的 WriteFile 究竟何時送達磁碟
• 第 5 回:NTFS ── 從 MFT 理解檔案系統
• 第 6 回:篩選驅動程式與迷你篩選驅動程式(本文) ── Procmon 與病毒掃描為何能夠介入 I/O

9. 總結 ── 系列的結語

以下是最終回的總結。

• 介入 I/O 是作業系統官方認可的擴充點,目前的標準是向 FltMgr 註冊回呼(迷你篩選驅動程式)。順序由海拔決定性地決定,並由 Microsoft 統一分配與管理編號。²⁴⁵
• 運作方式是pre/post 回呼。可以放行、拒絕、代為處理、改寫,也能列席快速 I/O。無論是 Procmon、Defender 還是 OneDrive,都是這同一套機制下的住客。¹¹¹¹⁰
• 除外設定＝省略掃描,是與保護之間的取捨。開發用磁碟區有Dev Drive(非同步掃描)這個更安全的選項。⁶⁷
• 「唯獨那個環境慢」,要從Procmon 的 Duration 與 fltmc 的構成差異著手排查──本系列的工具原封不動地就成了調查步驟。

如果要用一句話總結整個系列,那就是──Windows 的 I/O,是一套一貫的設計:透過命名空間決定目的地,把要求做成封包(IRP)在各層之間流動,並讓每一層都能選擇「檢視、保管、代為處理」。在 File.ReadAllText 這一行程式碼底下,這六回份的結構每次都在運作。與其死記 API 的行為,不如從這張地圖推導出「應該會是這樣」──這正是希望各位透過本系列所獲得的能力。感謝各位陪伴這趟漫長的旅程。

相關文章

• Windows I/O 的深層(第 1 回) ── 所有讀寫都會變成 IRP：I/O 系統全貌
• Windows I/O 的深層(第 4 回) ── 快取管理員：你的 WriteFile 究竟何時送達磁碟
• Windows I/O 的深層(第 5 回) ── NTFS 的內部結構：從 MFT 理解檔案系統
• Process Monitor(ProcMon)實戰指南 ── 在10分鐘內找出「設定未被讀取」「ACCESS DENIED」的原因
• 自行開發的 Windows 應用程式被當成病毒處理時 ── Microsoft Defender 誤判的因應方式,以及與效能影響的相處之道
• Process Explorer / Handle / VMMap 實戰 ── 從「此刻」的狀態追查無回應、洩漏、「檔案使用中」
• Windows 應用程式開發中遵守最低限度安全性的檢核表

相關諮詢領域

合同會社小村軟體處理像是「只有特定環境會變慢」「資安軟體與自家應用程式互相干擾」這類與篩選驅動程式相關的 Windows 業務應用程式效能問題與缺陷調查。

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

參考連結

相關文章

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

相關主題

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

與本主題相關的服務

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

常見問題

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

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

兩者都是「介入對檔案系統之 I/O 要求的驅動程式」，但介入方式的世代不同。舊有的傳統篩選驅動程式,是把自己的裝置物件直接堆疊在檔案系統的裝置堆疊上,由於位置取決於載入順序,順序難以保證,還存在一旦載入就無法安全解除安裝等問題。作為目前標準的迷你篩選驅動程式,則是向 Windows 內建的篩選管理員(FltMgr)註冊「希望在這個操作前後呼叫自己」的回呼。位置由稱為海拔的編號決定性地決定,可以在任意時間點載入,若篩選驅動程式實作了解除安裝回呼,甚至能在執行期間將其移除。防毒軟體、加密、監控工具、雲端同步等現代篩選驅動程式,幾乎全部都是以迷你篩選驅動程式的形式實作。

為什麼防毒軟體能夠檢查所有的檔案存取？

因為作業系統官方就備妥了用於此目的的擴充點。迷你篩選驅動程式可以向篩選管理員註冊在開啟、讀取、寫入等操作之前(pre 回呼)與之後(post 回呼)被呼叫的程式碼。防毒軟體的篩選驅動程式位在防毒專用的海拔區間(320000～329999),例如可以在檔案開啟成立的瞬間之後(post-create)掃描內容,發現問題就取消該次開啟,讓存取失敗。正如本系列第 1 回所見,所有的檔案 I/O 都會流過裝置堆疊,因此只要站在這條必經之路的固定位置,就能檢查所有存取——道理就是這麼簡單。這不是什麼駭客手法,而是內建在作業系統設計中的機制。

防毒軟體的除外設定(資料夾除外)在技術上到底做了什麼？

它讓符合除外清單路徑的 I/O,省略掉該產品篩選驅動程式所執行的掃描處理。篩選驅動程式本身並不會從堆疊中消失,比較貼近實際情況的理解是「這條路徑不檢查」這個判斷被提早做出而已。有一個重要的限定:除外只對擁有該設定的產品自身生效。舉例來說,Microsoft Defender 的除外設定改變的是 Defender 的篩選驅動程式(WdFilter)的掃描,對同時運作的其他廠商防毒軟體、EDR、備份等其他迷你篩選驅動程式的行為沒有任何影響。每個產品都需要各自設定除外,「設定了除外卻依然很慢」時,原因有可能出在別的篩選驅動程式上。另外,正如 Microsoft 的文件反覆警告的那樣,除外會削弱該處的保護,因此應搭配風險評估,控制在最小範圍。在開發用途中,也值得考慮作為資料夾除外的安全替代方案而設計的 Dev Drive(效能模式＝非同步掃描)。

Process Monitor 是如何記錄所有 I/O 的？

因為 Procmon 自己會在啟動時,把自己以 Activity Monitor(活動監控)專用海拔區間的迷你篩選驅動程式身分,向篩選管理員註冊。在 Procmon 執行中,從具有系統管理員權限的命令提示字元執行 fltmc,就能確認清單中出現了以 PROCMON 開頭名稱的篩選驅動程式。由於它以迷你篩選驅動程式的身分,能夠列席所有磁碟區 I/O 操作的 pre/post,因此能夠毫無遺漏地記錄下哪個處理程序對哪個檔案執行了什麼操作。本系列出現過的 IRP 與快速 I/O 等術語,之所以會原封不動地出現在 Procmon 的顯示中,正是因為它站在了 I/O 通行本身的必經之路上進行觀察。

開發用電腦的建置變慢時,應該懷疑篩選驅動程式嗎？

非常值得懷疑。建置是大量小檔案的建立、讀寫、刪除的集合體,每一項操作都會成為篩選驅動程式群(尤其是防毒軟體的掃描)的檢查對象,因此是篩選驅動程式成本最容易浮上檯面的工作負載。調查的基本步驟,是在 Procmon 中查看 Duration 欄,確認時間消耗在哪個操作上,再用 fltmc instances 比較不同環境之間篩選驅動程式構成的差異。對策方面,除了在評估風險之後設定除外之外,還可以考慮使用專為開發用磁碟區設計的 Dev Drive。在 Dev Drive 上,防毒軟體會以效能模式(非同步掃描)運作,Microsoft 將其定位為比除外設定更安全的替代方案。

作者檔案

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

Go Komura

小村軟體有限公司 代表

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