Windows I/O 底层原理（第 6 篇·完结篇）——迷你过滤器的机制与用 Procmon 排查延迟

只是打开一个文件，在某些电脑上却要等很久。装了杀毒软件的环境里，构建和大批量文件复制会变慢。另一方面，启动 Process Monitor 之后，明明没有改动自己的应用，却能看到文件操作的记录。

理解这两件事的线索，是在文件 I/O 的中途进行监视和控制的文件系统过滤器驱动程序。Windows 为此准备了专门的扩展点。¹

在系列“Windows I/O 底层原理”的完结篇里，我们来看当前标准的实现方式——迷你过滤器（Microsoft 中文文档中称为“微筛选器”）。前半部分讲清机制，后半部分接着讲如何用 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 的说明，向 fsfcomm@microsoft.com 发送主题为 Filter altitude request 的 ASCII 纯文本邮件。邮件里要填写公司名、可长期使用的公司联系方式、产品名与 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 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。