Windows Minifilter：如何在FLT回调中捕获主IRP_MJ_CREATE请求

首先直接结论：依赖请求属性的筛选逻辑才是生产环境的可靠方案，简单粗暴的“仅处理首个IRP_MJ_CREATE并拒绝其他”只适合极有限的原型测试场景，完全无法覆盖真实业务需求。

为什么简单筛选逻辑不可行？ #

• 单一用户模式操作可能触发多个关联IRP：比如调用CreateFile打开带扩展属性的文件，会先发起IRP_MJ_CREATE，后续还会触发IRP_MJ_QUERY_EA等请求，拒绝后续请求会直接破坏正常文件操作。
• 不同业务场景的IRP_MJ_CREATE有不同意义：比如文件重命名会触发两次IRP_MJ_CREATE（一次打开原文件，一次创建目标文件），仅处理首个会漏掉关键的重命名逻辑。
• 系统后台操作也会触发IRP：简单筛选无法区分用户发起的请求和系统服务（如杀毒软件、索引服务）的后台操作，导致误处理。

基于请求属性的筛选方案实践要点 #

要精准捕获核心请求，需结合以下维度的请求属性做组合判断：

• IRP操作类型与标志位：
  • 对IRP_MJ_CREATE，检查CreateOptions字段的标志（如FILE_SUPERSEDE表示覆盖创建、FILE_OPEN_EXISTING表示打开现有文件），区分不同的创建意图；
  • 对IRP_MJ_WRITE/READ，结合IoGetCurrentIrpStackLocation(Irp)->Parameters.Write.Length（或Read.Length）和文件对象的Flags，过滤掉零长度或系统级的后台读写。
• 请求发起者上下文：
  • 通过FltGetRequestorProcessId(Data)获取发起请求的进程ID，仅处理目标进程的请求；
  • 用FltGetRequestorProcessToken检查进程权限，排除系统特权进程的操作。
• 文件对象生命周期追踪：
  • 调用FltAllocateContext为每个IRP_MJ_CREATE成功的文件对象关联自定义上下文，后续的IRP_MJ_WRITE/READ/CLEANUP请求通过FltGetContext关联到同一个文件的上下文，确保请求链的完整性。
• 快速IO与IRP模式区分：
  • 很多高频用户操作会触发快速IO（如FastIoRead），需在快速IO回调中同步处理，通过Data->Iopb->Flags判断请求是快速IO还是普通IRP，避免遗漏。

额外实践建议 #

• 先通过ETW跟踪或DebugView日志，分析目标用户模式API对应的IRP序列，明确每个操作触发的IRP类型、标志和上下文，再针对性编写筛选逻辑；
• 过滤逻辑尽量轻量化，避免在回调中做复杂计算，优先用位运算检查标志位，减少对系统IO性能的影响。

内容的提问来源于stack exchange，提问作者zbx0310