C# 文件系统微筛选驱动交互 C#如何与文件系统驱动通信来监控或拦截IO

c#无法直接与windows微筛选驱动通信，必须通过p/invoke调用fltlib.dll的filterconnectcommunicationport等api实现跨态通信，且需严格匹配端口名、手动管理非托管内存。

Windows 文件系统微筛选驱动不能用 C# 直接通信

微筛选驱动（MiniFilter）运行在内核态，C# 运行在用户态，两者隔离严格——FileStream、FileSystemWatcher 或任何托管 I/O API 都无法触达或控制微筛选驱动的行为。这不是权限问题，是 Windows 架构层面的硬隔离。

常见错误现象：AccessViolationException、STATUS_ACCESS_DENIED、调用 FilterConnectCommunicationPort 失败返回 0xC0000034（对象名 not found），或者注册通信端口后收不到任何消息。

• 微筛选驱动必须自己实现通信端口（FltCreateCommunicationPort），并暴露一个命名端点（如 DeviceMyMiniFilterPort）
• C# 端只能通过 Win32 API 的 CreateFile + DeviceIoControl（或 FilterSendMessage 对应的用户态 DLL 封装）与之交互，不能靠 .NET 原生类库
• .NET 6+ 的 SafeHandle 可封装设备句柄，但底层仍需 P/Invoke kernel32.dll 和 fltlib.dll

C# 调用 fltlib.dll 发送/接收消息的最小可行路径

微软提供 fltlib.dll 封装了微筛选通信的常用操作，比裸写 CreateFile + DeviceIoControl 更安全、更贴近驱动语义。但要注意：它不是 .NET 组件，必须显式加载并处理结构体对齐、指针生命周期。

使用场景：向已加载的微筛选驱动发送配置命令（如启用/禁用监控）、接收文件路径通知（例如驱动把 IRP_MJ_CREATE 的文件名发回用户态）。

• 必须用 [DllImport("fltlib.dll")] 导入 FilterConnectCommunicationPort、FilterSendMessage、FilterCloseCommunicationPort
• 连接端口时传入的端口名必须和驱动中 FltCreateCommunicationPort 注册的完全一致（包括前导反斜杠），大小写敏感
• FilterSendMessage 的输入/输出缓冲区需用 Marshal.AllocHGlobal 分配非托管内存，且长度必须匹配驱动预期；.NET 数组直接传会崩溃
• 示例片段：

  IntPtr port = IntPtr.Zero; uint status = FilterConnectCommunicationPort(@"DeviceMyMiniFilterPort", IntPtr.Zero, 0, null, 0, out port); if (status == 0) {     IntPtr inBuf = Marshal.AllocHGlobal(8);     Marshal.WriteInt32(inBuf, 1); // 启用指令     IntPtr outBuf = Marshal.AllocHGlobal(4);     uint bytesRet;     FilterSendMessage(port, inBuf, 8, outBuf, 4, out bytesRet); }

FileSystemWatcher 无法替代微筛选驱动的监控能力

FileSystemWatcher 是基于 NTFS USN 日志或目录变更通知的用户态轮询/事件机制，它根本看不到驱动层的 IO 决策过程——比如文件被重定向、被加密拦截、被拒绝打开，甚至某些绕过 Win32 API 的直接 IRP 操作（如 PowerShell 的 Set-Content -Encoding Byte 写入）都会漏报。

性能与兼容性影响明显：

• FileSystemWatcher 在高 IO 频率下容易丢事件（尤其网络共享路径），而微筛选驱动在 IRP 到达文件系统栈早期就能捕获，无丢失
• 它无法获取原始 IRP 参数（如 IoStackLocation->Parameters.Create.SecurityContext），也就没法做细粒度访问控制
• 某些云同步工具（onedrive、Dropbox）或反病毒软件会干扰 FileSystemWatcher 的底层通知源，导致静默失效
• 若你真正需要的是“阻止某类文件写入”，仅靠 C# 层监听再删除是马后炮，驱动层才能真正 FLT_PREOP_DISALLOW_FASTIO 或返回 STATUS_ACCESS_DENIED

调试通信失败时优先检查这三件事

90% 的 C# 与微筛选通信失败，根因不在代码逻辑，而在环境或驱动状态本身。

• 用 fltmc filters 命令确认驱动已加载且状态为 attached；若显示 not attached，说明没挂载到任何卷，通信端口也不会创建
• 用 fltmc instances 查看对应实例是否处于 active 状态；有些驱动默认不激活，需先发命令启用
• 检查驱动是否启用了通信端口：在驱动代码中确认调用了 FltCreateCommunicationPort，且返回状态为 STATUS_SUCCESS；未成功则 Device... 路径根本不存在，CreateFile 必然失败

驱动没跑起来，C# 再怎么 P/Invoke 都只是对着空气喊话。这点最容易被忽略——大家总盯着 C# 代码改来改去，却忘了先用管理员权限跑一遍 fltmc。