资讯动态

filemon V4.33 内核驱动捕获文件 I/O:原理、排障与过滤实战

发布时间:2026/10/6 10:08:38 来源:尧图企业网站定制
简介filemon V4.33 是一款经典的系统文件监控工具主要面向系统管理员、运维工程师与软件开发者用于实时监听系统中文件和文件夹的访问、读取、写入、删除等操作是排查软件冲突、性能瓶颈及理解软件运行机制的有效助手。相比 V7.04 的兼容性问题V4.33 在多数环境下更稳定且为绿色免安装版本无需改动系统设置即可直接解压使用。资源以 rar 压缩包形式提供包内共 2 个文件一个 HTML 格式的帮助文档内含使用说明、授权信息等另一个 ZIP 压缩包则封装了程序本体解压后即可直接使用。资源整体仅 77KB极为轻量目前已吸引 245 人学习与下载。借助实时监控、过滤搜索以及日志记录等核心功能用户可以快速定位具体进程对系统文件的每一步操作为后续诊断提供依据。尽管界面字体在部分显示器上可能稍显不适但并不影响其诊断能力。对于需要深入理解文件系统行为、排查应用异常的中高级使用者这份资源提供了简洁实用的工具与配套说明值得收藏备查。1. ProcMon 时代的 filemon V4.33为什么老工具还值得花一小时复现如果你翻过老教材、内网运维手册或者逆向分析入门资料多半见过 filemon 这个名字。V4.33 是它最后的版本官方后续把能力并进了 ProcMon可直到今天排查“哪个进程占着某个文件删不掉”“服务启动时到底读了哪个配置”这一类场景filemon 依然以极低的内存占用和单 exe 的形态出现在很多老手的工具箱里。它解决的事很具体把每一次文件打开、读写、改名、删除请求连同发起进程、返回结果和路径按顺序摆在你面前。本文写给三类人要快速复现的老系统排障、想在虚拟机里练读原始 I/O 日志的入门审计、以及想搞明白磁盘监控工具工作原理的开发者。下面从捕获机制讲到过滤、高亮和导出再把最容易翻车的几个现场逐条拆给你。2. filemon 的捕获机制文件请求是怎么被拦下并写进日志的2.1 挂钩点I/O 管理器到文件系统之间那层过滤器不理解 filemon 的原理你看到日志很容易误判。它不是一个靠轮询文件表来猜行为的工具而是把一个内核驱动装进 Windows 的文件系统栈里位置在 I/O 管理器和 NTFS/FAT 之间。任何进程发起文件操作都会生成一个 IRPI/O Request Packet或者走快速 I/O 路径先经过这层过滤器filemon 在请求前后各插了一脚请求发出时记一次请求完成时再记一次两次的差值就是结果列里的状态码。所以你看到的每行日志并不只是“谁访问了哪个文件”它还包含了请求的类型、发起进程、进程 ID、操作要到达的路径、以及这次请求最终是被接受还是被拒绝。内核驱动把事件写进一块环形缓冲区用户态界面再从缓冲区里按顺序取出来显示。这也是为什么 filemon 会丢事件的场景很固定缓冲区写满、界面处理不过来后面的请求被覆盖。老工具不存在“按需订阅”的概念它把整个系统的文件请求都搬过来再靠界面的过滤条件帮你砍掉不关心的部分。这个设计带来一个很实用的推论只要驱动装上了哪怕没有任何进程在界面上显示它也在工作。很多人在 Filemon 窗口里看不到事件第一反应是工具坏了实际上是过滤条件挡掉了全部内容。后面第 4 章会专门讲过滤。2.2 结果列和 Time 列先看懂再谈过滤打开 filemon 的第一眼你会看到六列左右的信息。我按 V4.33 英文原版界面描述Time 列显示的是自捕获开始到该事件经过的毫秒数是相对时间不是墙钟时间Process 列是进程名PID 是进程标识Request 列是操作类型常见的有 CreateFile、ReadFile、WriteFile、CloseFile还有目录枚举和文件属性查询Result 列是内核返回状态Path 列是完整路径Other 列留给了日志找不到归属的补充信息。结果列是最容易误读的地方。SUCCESS 意味着这次请求被文件系统接受了不代表数据一定写进了物理磁盘ACCESS DENIED 说明请求被拒绝可能是权限问题也可能是文件设了只读属性SHARING VIOLATION 很典型文件已经被另一个进程以独占方式打开你再尝试打开就会得到这个状态。复现一个病毒或者崩溃问题时你经常看到同一路径前面几行全是 SUCCESS突然出现一个 SHARING VIOLATION然后崩溃点就浮出来了。Time 列只做相对定位别拿它换算日期时间。实际用法是清空历史、打点标记当前时刻然后执行一次目标操作回到 filemon 看 Time 列里最近一段毫秒差的集中区域。这样定位要看的行比用鼠标在几万行里翻要快得多。2.3 验证驱动是否加载sc query filemon在虚拟环境里装完 filemon 后先别急着乱点打开管理员 PowerShell 确认驱动状态。我在排障时习惯先跑这一句sc.exe query filemon Start-Service filemon -ErrorAction SilentlyContinuesc.exe query filemon的作用是查询名为 filemon 的内核服务当前状态。如果显示STATE : STOPPED说明驱动文件在但没启动可以用后面的Start-Service尝试拉起。如果提示服务不存在说明驱动没有安装成功常见原因包括没有用管理员身份运行、被杀毒软件扫掉、系统版本不支持。注意filemon 的驱动不会像普通服务那样常驻它会随着工具退出而卸载。所以“查询不到驱动”不代表工具坏了重启 filemon 后驱动会重新加载。我一般用这个命令判断的是驱动到底有没有资格在这个系统里被加载而不是它在不在运行。这个区分很重要因为到了第 5 章你会看到新版 Windows 上大多数 filemon 打不开的故障都发生在驱动加载这一步。3. 把 filemon V4.33 跑起来环境选型、启动顺序与第一份日志3.1 环境选型先放过 Win10把 V4.33 放到该放的系统里V4.33 官方支持的宿主系统止步于 Windows 2000/XP/2003 这一代。很多人下了资源直接双击结果 Win10 上是闪退、蓝屏或者驱动签名报错然后下一个“这个资源不能用”的结论。真要用它做事第一步就是选对运行环境。我的建议非常明确如果你手里的机器是 Win7 以上 64 位系统别跟 V4.33 较劲直接转 ProcMon如果你就是想要 filemon 这种轻量、单文件、低内存的体验建一个 Windows XP SP3 虚拟机或者 2003 虚拟机来跑。虚拟机的硬件要求不高512M 内存都能转得动跑起来比在物理机上处理兼容性问题节省大量时间。选好环境后把下载到的 filemon.exe 放到一个干净的目录比如 C:\tools。首次运行会弹授权协议对话框点 Agree 接受即可。Sysinternals 老工具普遍支持/accepteula参数跳过这一步这条参数在后面做自动化触发脚本时非常有用。提示如果你非要在 Win7 32 位上试开启测试签名模式bcdedit /set testsigning on后有一定概率能跑但 64 位系统不要浪费时间V4.33 的内核驱动没有新签名体系支持的接口折腾到最后还是得回到虚拟机方案。3.2 第一次捕获一个脚本、一段日志、五个基本操作环境准备好之后我们可以做一次标准捕获演练——目标是把“创建文件、复制文件”这个动作完整抓到 filemon 的列表里。先准备一个批处理脚本echo off set TOOLSC:\tools REM /accepteula 跳过第一次授权对话框 start %TOOLS%\filemon.exe /accepteula timeout /t 3 /nobreak set TARGETC:\temp\sample echo hello %TARGET%.txt copy %TARGET%.txt %TARGET%_copy.txt nul echo done脚本的逻辑是先用start命令以非阻塞方式把 filemon 拉起timeout /t 3 /nobreak等 3 秒目的是给驱动加载和界面初始化留出时间然后用echo重定向生成 sample.txt触发一次写请求最后用copy做文件复制触发读和写两个请求。跑完这个脚本回到 filemon 窗口你会发现列表里混着大量的 svchost.exe、explorer.exe、filemon.exe 自身的请求。这不是异常而是默认状态。要看清自己的操作需要按顺序做以下五个动作暂停捕获在 Capture 菜单里把 Capture Events 的勾选去掉避免新的事件继续涌入。清空历史在 Capture 菜单里找到清空显示项或者用工具栏对应的清空按钮把之前积累的无关行全部清掉。设置进程过滤在 Options 菜单里打开 Filter/Highlight 对话框Process Include 填cmd.exe和filemon.exe让列表只显示这个脚本进程的活动。恢复捕获并重新触发重新勾选 Capture Events再执行一次脚本。观察结果确认列表里出现了 sample.txt 和 sample_copy.txt 的 CreateFile、ReadFile、WriteFile、CloseFile 记录。这五个动作是 filemon 操作的基本盘后面每一个复杂排障都建立在它们的组合上。先理解为什么暂停、为什么清空、为什么过滤比记住上面哪个按钮在哪个菜单更重要——汉化版的菜单翻译各不相同所以你记住功能点按英文原版菜单来找永远找得准。3.3 列读不懂怎么办Process/PID/Request/Result/Path/Other第一次看到完整日志时建议先做一次“行级阅读练习”。以 test_copy.txt 为例你会看到大致这样一组记录先是 CreateFilePath 指向 test_copy.txtRequest 带打开意图接着是 ReadFile 和 WriteFile代表复制过程中源文件在读出、目标文件在写入最后是 CloseFile句柄释放。这组记录之间的毫秒差通常极短但它们确实按顺序排在列表里。如果把一个文件打开过程拆细最值得看的是三个点CreateFile 的 Result 是 SUCCESS 还是 SHARING VIOLATION、ReadFile/WriteFile 的数量和次数分配、CloseFile 之后有没有跟着出现奇怪的属性查询。这三点分别对应着文件能否被访问、数据读写量、以及操作结束后是否有进程还在查它的元数据。还有一列经常被忽略Other。这一列在正常操作里大部分时间是空的但它偶尔会显示请求类型之外的信息。比如某些异步操作、带附加标志的请求在主 Request 列看不出差别时Other 列会给出补充。我见过有人拿着两段看起来一模一样的 File 日志半天找不到差异最后发现是 Other 列里一个标志位不同。所以读日志时别只盯着 Request 和 Path 两列。4. 过滤、高亮与导出把十几万行压缩到你真正要看的那几行4.1 进程过滤和路径过滤Include/Exclude 到底怎么填filemon 的过滤对话框是很多人第一次用就卡住的地方。它分成进程过滤和路径过滤每类又有 Include 和 Exclude 两个框。你要理解的是两个框的叠加语义Include 框里的规则是“满足条件的行才显示”Exclude 框里的规则是“满足条件的行被隐藏”。当同一行同时命中 Include 和 Exclude 时隐藏优先。我通常是这样配置的出问题的目标进程名确定时就在 Process Include 填进程名比如notepad.exe一次只填一个多进程场景用分号或者空格分隔我记得老版本支持用空格分隔多个名称。路径过滤更讲究一些它可以填的很具体比如C:\temp\*是匹配整个目录也可以填到根盘符做粗筛。但路径里不能写环境变量必须用绝对路径。中文路径可以直接填中文前提是系统区域设置一致否则显示会变乱码。有个新手最容易踩的动作把目标路径填进 Exclude 而不是 Include。如果你发现“过滤之后整个列表全空了”八成都不是工具坏了而是把要看的路径写进了 Exclude 框。判断方法很简单——先只填 Process Include不加路径规则确认列表能出内容再逐步叠加路径规则。一次只改一个条件出了结果再动下一个。4.2 高亮标记在不停抓取的列表中把目标行“拎”出来过滤能砍掉行但有些场景你不想砍只想让目标行在滚动列表里更醒目这时候用的是高亮功能。高亮和过滤的区别在于过滤器改变了显示范围行真的消失了高亮只是给满足条件的行上色行还是在那里。在 Options 菜单的高亮设置里我可以定义一条路径规则C:\temp\*然后让匹配的行标成醒目的配色。这样就算捕获没暂停、列表一直在滚动我也能用眼睛锁住目标区域。实操时我习惯先加路径高亮再加进程高亮两层高亮搭配能让“某个进程对某个目录的全部访问”在满屏日志里像一条彩色轨迹一样清楚。高亮规则和过滤规则共用同一套匹配语法所以填路径时同样要写绝对路径。它不减少事件数量在高频 I/O 场景下也不要指望它降低 CPU 占用。4.3 导出日志文本和 HTML 怎么选需要把日志留档或者发给别人分析时用菜单里的保存功能导出整个视图。V4.33 的保存动作有一个关键前提先暂停捕获再保存。否则在点击保存那个瞬间保存动作本身触发的文件 I/O 会混进日志末尾污染你的数据。导出格式上我一般首选纯文本。它体积最小方便用命令行继续筛HTML 格式适合给你不熟悉工具的人看浏览器打开就能搜索和跳转。如果后续要做长时段审计建议按时间窗口分多次保存不要在同一个文件里堆几十万行文本——没有哪个文本编辑器能在这种体量下流畅编辑最后还得靠脚本拆文件反而多一道工序。下面是我常用的导出格式对照格式适用场景后续处理建议文本自己用脚本继续追查grep/findstr 按进程名或路径匹配HTML发给同事阅读检索浏览器内搜索适合快速核对CSV需要导入表格做统计用 Excel 打开前先确认列分隔符5. 避坑记录filemon 最容易翻车的五个现场5.1 现场一双击闪退或蓝屏现象在 Win7/10/11 上以管理员身份运行 filemon.exe出现两种情况——要么程序闪退后没有任何反应要么出现蓝屏。原因V4.33 的内核驱动为 XP/2003 时代的接口设计新系统在加载驱动时做了签名和接口双重校验失败后驱动无法附着到文件系统栈GUI 便直接退出极端情况下驱动又不兼容导致系统崩溃。解决不要试图在新系统上硬扛建 XP/2003 虚拟机来运行32 位 Win7 可以试bcdedit /set testsigning on后加载但成功率并不高Win10/11 直接用 ProcMon 承接 filemon 的职责。每次拿到这种老工具我第一件做的事是看驱动的目标系统而不是先双击运行。5.2 现场二服务进程的事件看不到现象开机自启的服务一直在读写配置文件但 filemon 里 Process 列死活找不到这个服务名。原因filemon 的驱动是随工具启动才挂载到文件系统栈的服务在开机阶段比驱动先运行它启动期间产生的文件访问早已结束自然进不了缓冲区。你后面重启服务时能抓到但首次初始化那一段是盲区。解决如果想抓服务启动阶段的行为把 filemon 加入启动项让驱动先于服务加载再重启目标服务如果服务已经被某个守护进程拉起就先把服务停掉清空历史再手动启动。触发动作要尽量贴近真实启动路径不要用“手工打开配置窗口”替代服务启动两者产生的文件请求集合差异很大。5.3 现场三过滤后整个列表全空现象配置了路径过滤之后原本有内容的列表瞬间变成零行而且把系统重启重开 filemon 问题依旧。原因路径被填进了 Exclude 框而不是 Include 框或者路径写错了盘符/大小写匹配不到任何行。解决按“先进程后路径、先 Include 后 Exclude”的顺序逐步验证。第一步只用 Process Include 填cmd.exe确认列表有数据第二步才往 Path Include 里填绝对路径。如果加了路径规则后列表空了把该规则从 Include 挪到目标路径之外看是否恢复。这个现场是新手翻车率最高的一条但也是最容易自查的一条。5.4 现场四一次复制操作写出几万行日志现象想测一个文件夹复制动作结果捕获开了不到十秒几万个事件行刷屏界面卡到点不动最后不得不强杀进程。原因没有做任何前置过滤把整个系统的文件事件全灌进来了再加上自身日志写入动作又产生了新事件形成放大效应。崩溃点往往是界面渲染跟不上内核缓冲区写入速度。解决开捕获前在 Process 过滤里只留目标进程确认目标进程路径后再加路径过滤测试脚本里用timeout或Start-Sleep做延迟让动作和观察分开。复制动作本身一般只需要几十秒抓完立刻暂停捕获、确认事件量级再决定是否扩大范围。别指望在满屏日志里人眼找到目标行那是事后才做的体力活。5.5 现场五结果列全是 SUCCESS磁盘计数器却不动现象日志里同一个路径反复出现 WriteFile/ReadFile 且结果都是 SUCCESS但打开性能监视器看物理磁盘计数器读写流量几乎为零。原因filemon 记录的是文件系统层请求这些请求可能被缓存满足在真正落到磁盘之前就返回了成功。比如读一个最近刚被写过的文件缓存还在内存里ReadFile 在缓存层命中磁盘计数器自然不动。解决想验证真实落盘给目标文件加大写入量让缓存被挤出去或者关掉对应路径的缓存策略。这个现场不是 bug它恰恰说明了第 2 章的原理请求成功不代表到了磁盘介质。用它来排查缓存命中和磁盘落盘之间的差异反而是正确的用法。6. 日志验证技巧把 I/O 时间戳和实际动作对齐的两种做法6.1 做法一PowerShell 打点用相对时间差对齐filemon 的 Time 列是相对毫秒没法直接和系统时钟比但你可以用“脚本打点 相对时间差”的方法验证。下面这个脚本在三次复制之间加入了固定延迟复制文件名里带编号方便在日志里定位$src C:\temp\test.txt for ($i 1; $i -le 3; $i) { $t Get-Date -Format HH:mm:ss.fff Write-Host copy#$i at $t Copy-Item $src (C:\temp\copy_ $i .txt) Start-Sleep -Milliseconds 500 }脚本的意图是三次复制之间刻意间隔 500 毫秒。跑完后在 filemon 里过滤C:\temp\copy_*你会看到 copy_1、copy_2、copy_3 三组 CreateFile 请求它们的 Time 列相对差应该接近 500。如果差距明显不是 500要么是系统负载太高缓冲延迟要么是捕获过程中有事件丢失这本身就是一个信号。参数上Start-Sleep -Milliseconds 500是可控变量想让差异更大更明显就改成 1000。6.2 做法二Process Explorer 反查句柄验证归属只靠 filemon 自己验证自己多少有点玄学成分。我一般会再用另一个工具交叉检查Process Explorer 的反查句柄功能。在 Process Explorer 的 Find 菜单里打开 Find Handle or DLL输入C:\temp\test.txt它能列出当前有哪些进程真正打开了这个文件。这一步能验证 filemon 里看到的 Process 列和实际句柄持有者是否一致。当两者的结果对不上时优先怀疑 filemon 的事件缓冲区被覆盖或者过滤条件把真正持有的进程行给挡掉了。我在做写入型故障排障时固定先开 filemon 记录再开 Process Explorer 反查句柄两手交叉几乎每一次都能在五分钟内定位到是哪个进程在反复读写目标文件。从那以后我每次用 filemon 都强制走一遍“清空历史、暂停捕获、加路径过滤、触发动作、反向验证”这五步把自证环节放在最前面少走了很多弯路。希望帮到你。本文还有配套的精品资源点击获取

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑