filemon V4.33：文件系统过滤驱动调试与IRP监控实战

简介filemon V4.33 是一款经典的系统文件监控工具面向系统管理员、开发人员及需要排查软件冲突或性能问题的技术人员。它能实时跟踪进程对文件和注册表的访问、读取、写入、创建、删除等操作并支持过滤、搜索与日志记录且不修改系统状态属于安全的非侵入式诊断工具。相比部分新版本在特定环境下出现的运行错误V4.33 稳定性更好、兼容范围更广适合快速定位文件活动异常。资源包共 2 个文件包含 1 个 html 说明文档与 1 个 zip 压缩包整体约 77KB说明文档提供使用指导与授权信息压缩包内为可执行程序及相关文件解压即可使用。目前已有 244 人学习下载。通过该工具读者可直观观察各进程的文件操作细节理解软件运行机制为排查冲突、优化性能提供可靠依据但需注意其对较新操作系统的兼容性。1. filemon V4.33一个被低估的文件系统过滤驱动调试利器如果你在 Windows 内核开发或安全研究领域摸爬过一段时间大概率听过 filemon 这个名字。它不是某个商业软件的最新版本而是一款经典的文件系统过滤驱动调试工具V4.33 是它在社区中流传较广的一个稳定版本。简单说它能挂载在文件系统驱动栈上实时捕获 IRP_MJ_CREATE、IRP_MJ_READ、IRP_MJ_WRITE、IRP_MJ_CLEANUP 等关键操作的完整上下文把进程名、文件路径、操作类型、返回状态、耗时全部打印出来。这解决了一个非常具体的痛点当你写的过滤驱动导致系统蓝屏、文件锁死、或者某个进程莫名其妙访问失败时光靠 WinDbg 断点单步效率极低而 filemon V4.33 能给你一份按时间排序的完整操作流水。它适合驱动开发、EDR 对抗研究、文件加密沙箱调试这类需要看清文件系统底层行为的从业者。接下来的内容我会按“它到底怎么工作 → 怎么把它跑起来 → 怎么改参数适配自己的场景 → 哪些坑我替你踩过”这条线讲透。2. filemon V4.33 的过滤驱动挂载原理与最小可跑环境2.1 为什么它必须用过滤驱动而不是 API Hook很多新手第一反应是用 SSDT Hook 或者 IAT Hook 去拦截 NtCreateFile、NtReadFile 这些用户态入口。但 filemon V4.33 走的是另一条路它注册一个文件系统过滤驱动通过 IoAttachDeviceToDeviceStack 挂到目标卷设备对象上。这样做的好处是无论上层是 Kernel32 的 ReadFile还是内核里直接调 ZwReadFile甚至 FastIO 路径只要最终落到文件系统驱动都会经过过滤驱动。API Hook 在 64 位系统上受 PatchGuard 限制而且绕过方法太多比如直接发 IRP 就能躲开。过滤驱动则处在 IRP 必经之路上捕获粒度更细能看到 IRP 栈参数、完成例程返回值、以及 FastIO 的 AcquireForCcFlush 这类操作。代价是它不能过滤网络重定向器或某些第三方文件系统除非你手动挂载到那些设备栈上。2.2 编译 filemon V4.33 需要准备的工具链filemon V4.33 原始代码通常以 WDK 工程形式存在常见做法是用 Visual Studio 2019 或 2022 配合 Windows Driver Kit 10 来编译。你需要确认三件事第一WDK 版本与目标系统架构匹配x64 驱动不能加载到 ARM64 上第二工程属性里“Driver Signing”设为 Test Sign 或者关闭强制签名否则加载时直接报 0xE000024B第三如果代码里用了 ExAllocatePoolWithTag注意在较新 WDK 里要改成 ExAllocatePool2 并指定 POOL_FLAG_NON_PAGED否则编译告警会变成错误。下面是一个典型的编译命令示例用 MSBuild 直接出 sys 文件msbuild filemon.vcxproj /p:ConfigurationRelease /p:Platformx64 /p:TargetVersionWindows10逻辑说明这条命令调用 MSBuild 编译 filemon 驱动工程Configuration 选 Release 是为了减少调试输出对性能的干扰Platform 指定 x64 对应 64 位系统。参数 TargetVersion 告诉 WDK 用哪套头文件和库Windows10 对应 10.0.19041 之后的 WDK。编译成功后会在 x64\Release 下生成 filemon.sys 和 filemon.inf。如果报“无法解析外部符号 __security_cookie”说明你漏了 BufferOverflow 相关的库在链接器输入里加上 BufferOverflowFastFailK.lib 即可。2.3 用 sc 命令加载驱动并确认挂载状态编译出 sys 之后不要急着双击 inf 安装。我一般用 sc create 手动注册服务这样卸载干净不会残留注册表项。命令如下sc create filemon type kernel binPath C:\test\filemon.sys sc start filemon sc query filemon逻辑说明第一行创建内核服务type kernel 表示这是驱动binPath 指向 sys 文件绝对路径注意等号后面必须有空格。第二行启动服务如果返回“服务无法启动”且错误码 577说明驱动签名有问题错误码 1275 说明依赖的驱动没加载。第三行查询状态STATE 显示 4 RUNNING 才算成功。此时 filemon 已经挂到所有卷设备栈上但默认可能只输出到 DbgPrint你需要用 DebugView 并勾选 Capture Kernel 才能看到。参数方面如果你只想监控 C 盘可以在驱动入口里改 IoAttachDeviceToDeviceStack 的目标设备名从 \Device\HarddiskVolume1 换成具体卷减少无关日志。3. 配置 filemon V4.33 的过滤规则与输出格式3.1 用 PID 和进程名做第一层过滤默认情况下 filemon V4.33 会把所有进程的文件操作都打出来系统空闲时每秒几千条根本没法看。我一般先加 PID 过滤。在驱动代码里找到 IRP_MJ_CREATE 的预处理回调在调用 PsGetCurrentProcessId 之后加一个判断ULONG targetPid 1234; ULONG currentPid (ULONG)(ULONG_PTR)PsGetCurrentProcessId(); if (currentPid ! targetPid) { return STATUS_SUCCESS; // 直接放行不记录 }逻辑说明PsGetCurrentProcessId 返回 HANDLE强转成 ULONG 比较。targetPid 是你想监控的进程 PID比如 notepad.exe 的 PID。参数说明如果你要监控多个 PID可以改成数组遍历或者用位图。注意这个判断要放在 IoSkipCurrentIrpStackLocation 之前否则会破坏 IRP 栈。如果发现过滤后仍然有大量日志检查是不是把 FastIO 路径漏了FastIO 不走 IRP 回调需要在 FastIoDispatch 里单独处理。3.2 输出格式里必须保留的四个字段filemon V4.33 原始输出格式比较简陋只有操作类型和文件名。我建议至少保留四个字段进程名、PID、操作类型、NTSTATUS 返回值。进程名通过 PsGetProcessImageFileName 获取注意这个函数返回的是 ANSI 字符串且最大 15 字符。PID 用 PsGetCurrentProcessId。操作类型从 IRP 主功能号映射比如 IRP_MJ_CREATE 对应“Create”IRP_MJ_READ 对应“Read”。NTSTATUS 从 IoStatus.Status 取。下面是一个格式化输出的代码片段DbgPrint([filemon] %s(%lu) %s %wZ Status0x%08X\n, pProcessName, currentPid, opTypeStr, pFileObject-FileName, irp-IoStatus.Status);逻辑说明%wZ 用于打印 UNICODE_STRINGpFileObject-FileName 就是文件路径。参数说明opTypeStr 是你自己映射的字符串数组注意不要用 DbgPrint 打印超过 512 字节的内容否则会被截断。如果发现文件路径为空说明 IRP_MJ_CREATE 的 FileObject 还没关联到设备对象需要从 IRP 栈参数里取 FileName。3.3 用 DebugView 抓内核日志并保存到文件DebugView 是 Sysinternals 的工具但很多人不知道它可以直接把内核日志写文件。打开 DebugView勾选 Capture → Capture Kernel然后 Options → Log To File指定路径。注意不要勾选“Clock Display”否则时间戳会混在每行里后期用脚本解析很麻烦。我一般还会在驱动里加一个序列号每输出一条日志就 InterlockedIncrement 一次这样即使 DebugView 丢包也能看出漏了哪几条。参数方面DebugView 的缓冲区默认 4MB如果日志量太大在 Options → Buffer Size 里改成 64MB否则会覆盖旧日志。另外Win10 之后 DbgPrint 默认被过滤需要在注册表 HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Debug Print Filter 下加一个 DWORD 值 DEFAULT0xFFFFFFFF重启生效。4. filemon V4.33 避坑与常见问题排查4.1 加载驱动后系统直接蓝屏 0x0000007E现象sc start filemon 之后立刻蓝屏错误码 0x7E指向 filemon.sys。原因最常见的是在 DriverEntry 里没有调用 IoCreateDevice 就注册了 FastIoDispatch或者过滤驱动的高度值设得太高挂到了文件系统驱动之上但没处理 IRP_MJ_FILE_SYSTEM_CONTROL。解决把驱动高度值改成 0x80000 以下确保挂在文件系统驱动之下。另外检查 DriverEntry 返回前是否调用了 IoDeleteDevice 清理失败路径。4.2 日志里只有 Create 没有 Read/Write现象DebugView 能看到大量 Create 操作但 Read 和 Write 一条都没有。原因filemon V4.33 默认只挂载了 IRP_MJ_CREATE 的完成例程没有注册 IRP_MJ_READ 和 IRP_MJ_WRITE 的预处理回调。解决在 DriverEntry 里找到 IRP_MJ_READ 和 IRP_MJ_WRITE 的 MajorFunction 数组把对应的 Dispatch 函数从 IoPassThrough 改成你自己的处理函数。注意 Read/Write 的 IRP 可能走 FastIO需要在 FastIoDispatch 里设置 Read 和 Write 的回调。4.3 文件路径显示为 \Device\HarddiskVolume1...现象日志里文件名全是设备路径不是 C:\Windows... 这种可读路径。原因FileObject-FileName 在 IRP_MJ_CREATE 阶段是相对路径需要结合 FileObject-RelatedFileObject 和卷设备名拼接。解决用 IoVolumeDeviceToDosName 把设备对象转成 DOS 路径然后和 FileName 拼接。注意这个函数在 IRP_MJ_CREATE 的预处理阶段可能返回 STATUS_INVALID_DEVICE_REQUEST需要放到完成例程里做。4.4 驱动卸载后系统卡死或文件句柄泄漏现象sc stop filemon 之后系统响应极慢或者某些文件无法删除。原因过滤驱动在卸载时没有等待所有挂起的 IRP 完成直接 IoDetachDevice 导致 IRP 栈悬空。解决在卸载例程里先设置一个标志位让所有新 IRP 直接放行然后调用 IoReleaseRemoveLockAndWait 等待现有 IRP 完成最后再 Detach。另外如果驱动里用了 ExAllocatePoolWithTag 分配内存确保在卸载时全部 ExFreePoolWithTag 释放。4.5 在 Win11 上加载报错 0xE000024B现象sc start 返回“驱动程序无法加载错误码 0xE000024B”。原因Win11 默认开启强制驱动签名且要求驱动有 WHQL 签名或测试签名。解决在管理员命令行执行 bcdedit /set testsigning on重启后桌面右下角显示“测试模式”再加载即可。注意测试模式会降低系统安全性调试完记得 bcdedit /set testsigning off 并重启。5. 用 filemon V4.33 做文件操作时序分析的进阶技巧当你已经能稳定抓到日志之后下一步不是继续加过滤条件而是把日志变成可分析的时序数据。我一般会在驱动里加一个高精度时间戳用 KeQueryPerformanceCounter 取计数然后在用户态用 Python 脚本把计数转成毫秒。具体做法是在每条 DbgPrint 前面加一个 64 位整数格式化成 %lluDebugView 保存文件后用正则提取。下面是一个解析脚本的片段import re from collections import defaultdict pattern re.compile(r\[filemon\] (\w)\((\d)\) (\w) (.?) Status0x([0-9A-F]) TS(\d)) ops defaultdict(list) with open(filemon.log, r, encodingutf-8, errorsignore) as f: for line in f: m pattern.search(line) if m: proc, pid, op, path, status, ts m.groups() ops[pid].append((int(ts), op, path, status)) # 计算同一 PID 下相邻操作的耗时 for pid, records in ops.items(): records.sort() for i in range(1, len(records)): delta records[i][0] - records[i-1][0] if delta 1000000: # 超过 1ms 的操作 print(fPID {pid}: {records[i-1][2]} - {records[i][2]} 耗时 {delta/1000000:.2f}ms)逻辑说明正则提取进程名、PID、操作类型、路径、状态码和时间戳。按 PID 分组后按时间排序计算相邻操作的时间差。参数说明delta 的单位是 KeQueryPerformanceCounter 的计数需要除以频率才是秒这里简化成 1000000 对应 1ms 是假设频率为 1GHz实际要用 QueryPerformanceFrequency 获取。这个脚本能帮你快速定位哪个文件操作卡了超过 1ms比如杀软扫描、加密驱动解密、网络重定向超时。另一个进阶用法是结合 ETW。filemon V4.33 的日志是文本解析慢且容易丢。你可以在驱动里用 EtwWrite 把事件写到自定义 ETW Provider然后用 Windows Performance Analyzer 做火焰图。这样能看到文件操作在哪个线程、哪个 CPU 上执行以及和磁盘 IO 的对应关系。我一般会保留 filemon 的 DbgPrint 作为快速验证同时开 ETW 做深度分析。注意 ETW Provider 的 GUID 要自己生成注册时用 EtwRegister卸载时 EtwUnregister否则会导致系统日志报错。最后说一个我踩过的坑filemon V4.33 在监控大量小文件操作时DbgPrint 本身会成为瓶颈因为 DbgPrint 在 Win10 之后默认走的是缓冲区但缓冲区满了会阻塞。我的习惯是先把日志级别降到只记录失败操作也就是 Status 不是 STATUS_SUCCESS 的才打印这样日志量减少 90% 以上。等定位到问题进程后再针对那个 PID 打开全量日志。这个“先粗后细”的过滤策略比一上来就全量抓取高效得多。希望帮到你。本文还有配套的精品资源点击获取