简介这份《process monitor使用说明.docx》面向需要排查Windows系统异常、软件冲突、权限受限与终端软件运行问题的IT运维人员及安全分析初学者聚焦Process Monitor在文件系统、注册表、进程和线程活动监控中的实际应用。文档结合IPGuard、ip-guard等终端管理软件的问题定位场景帮助读者理解监控范围、过滤思路、数据留存与结果研判之间的关系适合作为日常故障诊断、软件兼容性核查和性能瓶颈初筛的参考材料。资源包共1个docx文档大小约84KB篇幅紧凑便于随查随用也方便团队内部传阅或用作培训辅助材料。已有696人学习下载说明其在系统监控与终端软件排障场景中具有一定实用价值。读者可从中获得从现象复现到关键事件筛选、再到根因判断的整体框架并借助文档中的分析视角提升系统问题定位效率减少无效排查时间。1. 现场跑三趟不如开一次 procmon现场同事说点一下就闪退你抱上笔记本跑过去重启三次没复现回到工位刚坐下电话又响。往返几趟之后真正缺的不是经验而是一次完整的事件记录。Process Monitor下面统一叫 procmon干的就是这件事它把文件、注册表、进程线程、网络四类系统调用按时间轴摊开谁在什么时刻碰了哪个路径、返回码是什么一条不落地落到日志里。这份《process monitor 使用说明.docx》解决的是最前端的纪律问题——什么时候停采集、什么时候清空、什么时候按放大镜。它适合需要给第三方软件定性的人业务系统打不开、配置写不进去、和 ip-guard 这类终端管控客户端共存时行为异常都能靠它把口供录下来。流程不复杂但顺序错一步抓回来的就是一锅噪声。2. 事件流的底层账本procmon 到底在录什么、录多少2.1 四类事件源与各自的排查入口procmon 在用户态挂界面在内核里挂一个文件系统过滤驱动再加注册表回调与进程、线程通知。这个层级决定了它的强项凡是最终落到文件路径、注册表键、进程创建、网络端口的动作都能被记下来哪怕调用方一行日志都不打。代价是量级——一次打开软件的动作背后可能是十几万条事件。常见做法是先把四类事件源的量级和典型 Operation 摆出来按先小后大的顺序看事件类别典型 Operation什么情况下先看它单次复现的典型条数进程与线程Process Create、Thread Create、Process Exit软件压根起不来、启动链断在中间百级网络TCP Connect、TCP Send、UDP Send连不上服务端、解析异常、握手超时千级注册表RegOpenKey、RegQueryValue、RegSetValue配置读不到默认值、策略不生效万级文件系统CreateFile、ReadFile、WriteFile、CloseFileDLL 加载失败、配置写不进、文件被占用十万级顺序很重要。很多软件打不开其实是进程创建那一步就失败了压根没跑到读配置反过来能打开但功能不对才需要下沉到文件和注册表。一上来就盯着文件系统看等于在十万行里找一个本来不存在的答案。另外记住一点procmon 记录的是系统调用返回之后的结果不是应用层的意图。它告诉你这个路径打开失败了返回 ACCESS DENIED但不会告诉你为什么拒绝。后半截要靠 Stack 页签和进程树去补这是第 4 章的内容。2.2 事件风暴与缓冲区为什么先停再清不是仪式采集是来一条记一条界面批量刷新渲染。默认事件堆在内存里条数上去之后内存占用直线上升到顶就开始丢最早的事件。Options 菜单里的 Set Backing File 可以把事件落到磁盘上的临时文件同时能设一个体积上限超过之后按最旧的丢。这两件事合起来解释了说明书为什么反复强调先停止采集、再清空。第一停止是为了切断噪声源。目标软件只要还在跑后台定时任务、心跳、日志轮转就持续产生事件。你在这个背景下按清空清掉的只是屏幕上已经渲染的行采集通道并没有归零一秒之后又是几万条压上来前面做的全白费。正确顺序是点放大镜停止图标带红叉→ 点橡皮擦清空 → 再点放大镜开始。第二清空是为了让时间轴对齐。分析时大家习惯从复现动作开始那一刻往后数如果日志开头还压着上一次的残留起止时间就得靠肉眼找交接给别人时更容易错位。第三Backing File 是后悔药。现场机器内存本来就不宽裕几百万条事件足以让 procmon 自己变成问题的一部分。我一般会在开抓之前先设好落盘路径和上限比如 2 GB把丢事件变成一个可预期的行为而不是等界面卡死了才发现前半段没了。提示Backing File 生成的不一定只有一个文件超出上限后会滚动出编号文件回传时别只拷第一个。2.3 一次最小可用捕获的按钮状态判读工具栏上真正要认的只有四个漏斗Filter、放大镜Capture、向下箭头Autoscroll、橡皮擦Clear。放大镜没有红叉表示正在采集带红叉表示已停止。这个图标状态是最容易翻车的地方——以为自己停了其实还在抓或者以为在抓结果是停的复现动作从头到尾一条没录上。按说明书走一遍落地成可执行的顺序关闭要采集的目标软件包括托盘进程和它拉起的后台服务任务管理器里确认没有残留进程名打开 procmon首次运行接受 EULA确认标题栏显示管理员权限否则大量系统级事件根本看不到看放大镜若无红叉先点一下停止点橡皮擦清空当前列表确认事件计数归零配过滤条件第 3 章展开把目标进程和相关路径圈进来点放大镜开始采集让复现问题的同事按原始步骤操作操作完成立刻点停止File Save 落盘命名规范见第 6 章。第 3 步和第 4 步是最容易被跳过的两步也是后面所有分析能不能成立的前提。3. 照着说明书走一遍从关掉目标软件到落盘一个日志文件3.1 启动、停止、清空的三步顺序与状态判读说明书里那句若出现如下图显示则按照操作重置确定后再按照步骤 1 操作说的其实是同一个坑上一次采集没结束或者采集通道还开着你按清空只是清了显示。判断依据是三处——放大镜图标状态、状态栏的 Events 计数、以及窗口标题里是否还挂着正在写入的日志文件名。把这三处做成一张判读表现场对着看就不会错现象含义下一步动作放大镜无红叉Events 计数持续上涨正在采集点放大镜停止等计数不再变化放大镜带红叉Events 计数不为 0已停止但有残留事件点橡皮擦清空确认计数归零Events 计数归零后仍快速上涨清空后采集又被触发先停止再清空确认红叉状态标题栏无管理员标识权限不足事件残缺以管理员身份重启 procmon顺序上只有一条铁律停止在前清空在中开始在后。反过来做先清空再停止你会看到计数刚归零又跳回几千然后误以为软件有问题。还有个小细节目标软件的关闭要关干净。很多客户端关掉主窗口后托盘还在服务还在跑进程名还在进程列表里。抓之前用任务管理器按名称排序确认一遍比事后在日志里排除噪声省事得多。3.2 过滤器怎么加三列组合的实操Filter 对话框就四个字段Column、Relation、Value、Action。看起来简单真正的坑在规则顺序——procmon 从上往下逐条判断命中第一条就停止后面的规则不再参与。这意味着 Exclude 写在 Include 后面等于没写。举个真实会遇到的例子。你想只看 app.exe同时想排掉对 pagefile.sys 的访问。如果这么写顺序ColumnRelationValueAction1Process Nameisapp.exeInclude2PathcontainspagefileExcludepagefile 的访问会先命中第 1 条被 Include 进来第 2 条永远轮不到。正确写法是把排除往前放顺序ColumnRelationValueAction1PathcontainspagefileExclude2Process Nameisapp.exeInclude一套常用的起步配置可以直接抄目的ColumnRelationValueAction排除 procmon 自身噪声Process NameisProcmon64.exeExclude排除分页与休眠文件PathcontainspagefileExclude只看目标进程Process Nameisapp.exeInclude盯住配置目录Pathbegins withC:\ProgramData\Vendor\Include只看失败结果ResultisACCESS DENIEDInclude注意 Include 和 Exclude 混用时规则顺序决定了最终留下的集合。最稳的习惯是Exclude 全部排在前面Include 排在后面从上往下读一遍能说通再点 OK。3.3 保存格式与回传PML、CSV、XML 的取舍File Save 里有三件事要选格式、保存范围、目标文件。格式上PML 是 procmon 的原生日志格式保留全部列、Stack 页签和进程树只有它能被 procmon 完整回放。CSV 和 XML 是给脚本吃的CSV 会丢 Stack 信息中文系统下还可能把列名本地化成进程名称操作这类写解析脚本时要先打印表头确认。有些资料说保存成 .EVtx那其实是 Windows 事件日志的格式和 procmon 不是一套东西别混。保存范围上有两个选项All events 和 Events displayed using current filter。前者是全部后者只存当前过滤后可见的。现场回传我一般选 All events因为对方可能有不同的分析角度过滤后的日志等于把别人的视线也一起裁掉了。需要批量处理时用命令行起停更省事也能避免忘了点开始这种低级失误# 1) 无界面启动事件直接落到 backing file避免内存被吃满 $procmon C:\Tools\Procmon\Procmon64.exe Start-Process $procmon -ArgumentList /Quiet,/Minimized,/AcceptEula,/BackingFile,C:\Trace\base.pml # 2) 复现人操作完成后收尾让后台实例把缓冲刷到磁盘并退出 Start-Process $procmon -ArgumentList /Terminate -Wait # 3) 确认产物注意可能有 base-1.pml 这类滚动文件 Get-ChildItem C:\Trace\base*.pml | Select-Object Name, Length, LastWriteTime参数说明/Quiet跳过启动时的过滤设置弹窗/Minimized最小化到任务栏避免挡住操作界面/AcceptEula静默接受协议只在受控机器上用/BackingFile指定落盘文件/Terminate通知正在运行的实例停止采集并落盘退出。第 3 步的base*.pml通配是为了把滚动文件一起收走只拷base.pml会丢后面的半段。拿到 CSV 之后先用一个小脚本看分布比在界面里翻页快得多import csv from collections import Counter csv_path rC:\Trace\base.csv with open(csv_path, newline, encodingutf-8-sig) as f: reader csv.reader(f) header next(reader) # 先确认列名中文系统可能是本地化表头 print(列名:, header) i_op header.index(Operation) i_res header.index(Result) i_path header.index(Path) i_proc header.index(Process Name) stat, samples Counter(), [] for row in reader: if len(row) max(i_op, i_res, i_path, i_proc): continue # 字段缺失的行直接跳过避免 IndexError stat[(row[i_op], row[i_res])] 1 if row[i_res] in (ACCESS DENIED, NAME NOT FOUND) and len(samples) 200: samples.append((row[i_proc], row[i_op], row[i_path], row[i_res])) for (op, res), n in stat.most_common(10): print(f{op:28}{res:20}{n}) for s in samples[:20]: print(s)逻辑说明先用csv.reader读表头并打印避免DictReader在本地化列名下取不到键再按 (Operation, Result) 组合计数看清分布之后再决定加什么过滤条件最后把失败样本截前 200 条防止刷屏。参数上encodingutf-8-sig处理 BOM 头max(...)那行做长度保护样本上限按需调大。4. 过滤与堆栈让 ip-guard 类客户端的行为浮出水面4.1 过滤器的布尔组合与常见误配第 3 章讲的是单条规则和顺序这一节讲组合。Filter 对话框里没有括号没有 AND/OR 优先级全靠从头往下、命中即停这一条规则决定语义。想表达A 且 B只能靠 Exclude 先砍掉所有非 A 和非 B 的事件剩下的自然就是交集。比如要盯住 app.exe 对某个目录的访问失败。写法是三层先 Exclude 所有非 app.exe 的进程再 Exclude 所有不在该目录下的路径最后 Include 全部。听起来绕但它是唯一能表达交集的方式。常见误配有三种。第一种是把 Exclude 放在 Include 后面前面演示过等于没写。第二种是 Value 用了contains却忘了大小写路径在 Windows 上不区分大小写但过滤器里的匹配行为和你写的字符串形态有关路径写全比写片段稳。第三种是对 Result 列过早做 Include——结果列里 NAME NOT FOUND 在正常启动过程中大量出现先 Include 进来只会把真正的问题淹掉正确做法是先不限制 Result看完分布再说。还有一个容易被忽略的点过滤只影响显示不影响采集。也就是说过滤条件是事后可以改的只要你保存了 All events回放时重新配一遍过滤就行。这也是为什么保存时建议选 All events。4.2 Result 列才是重点ACCESS DENIED 与 NAME NOT FOUND 的语义差别事件列表里最该看的是 Result 列不是 Path 列。常见的几个值含义差别很大Result含义通常是不是问题SUCCESS调用成功不是ACCESS DENIED权限不足或被过滤驱动拒绝视上下文最值得追NAME NOT FOUND路径不存在大面积出现通常是正常探测REPARSE发生了重定向如目录联接一般不是但会误导路径判断FILE LOCKED WITH ONLY READERS有其他进程持读锁是常见于更新失败BUFFER OVERFLOW查询缓冲区不够返回所需长度多数是正常枚举行为判断标准不是有没有失败而是同一路径上的对比。同样一个配置文件进程 A 读是 SUCCESS进程 B 读是 ACCESS DENIED这就是要追的线索。反过来一个启动过程里出现几千条 NAME NOT FOUND多数是程序在按顺序试探多个可选路径——先试 System32再试 SysWOW64再试当前目录找不到就换下一个属于正常设计。真正值得停下来看一眼的组合是关键配置路径 NAME NOT FOUND 之后进程紧接着退出了或者某个 DLL 的 CreateFile 返回 ACCESS DENIED随后主进程退出。4.3 Stack 页签与进程树从一次拒绝追到一个模块procmon 只能告诉你谁被拒了告诉不了你谁拒的。这个信息在 Stack 页签里选中一条事件右键 Properties切到 Stack。默认情况下多半只能看到模块名加偏移比如xxx.sys 0x1a2b这种。想看函数名得在 Options Configure Symbols 里配符号路径让调试符号能从符号服务器拉下来。现场机器常常不能随便连外网这时候就退回看模块名这一层也够用——你要找的是这次调用链路上有没有第三方驱动。具体怎么用选一条 ACCESS DENIED 的 CreateFile 事件打开 Stack从上往下看调用来源。如果栈里出现的是目标软件自己的模块说明是它自己权限配置的问题如果栈中间夹着一个第三方内核驱动模块那就是这个驱动在这条链路上做了拦截或改写。ip-guard 这类终端管控客户端会挂文件、注册表、进程过滤驱动出现在栈里是正常的关键是看它出现的那几层对应什么动作。进程树Tools Process Tree解决的是另一个问题某个进程是谁拉起来的、什么时候退的、命令行参数是什么。软件启动后马上消失这类现象在事件列表里表现为 Process Create 紧跟一个 Process Exit把这两条对上再看 Exit Status往往比翻文件事件快十倍。5. 避坑清单五条踩过的坑和解法第一条抓了半天日志里全是 procmon 自己。现象是打开日志一看排在前面的全是 Procmon64.exe 的 CreateFile 和 RegQueryValue真正想看的进程被挤到几千行之后。 原因有两层procmon 界面刷新本身会产生事件另外未加任何过滤时系统里所有进程的活动都在往里灌。 解决是开抓之前先配一条Process Name is Procmon64.exe → Exclude再配一条目标进程的 Include然后才点放大镜。顺序别反。第二条保存下来打不开或者对方说你这日志不全。现象是文件发过去对方用 procmon 打开报格式错误或者打开之后只有几百条明显比现场看到的少。 原因通常是保存时格式选了 CSV 却用 procmon 去开或者保存范围选了 Events displayed using current filter把过滤掉的那部分直接丢了。 解决是回传一律用 PML保存范围选 All events真要给脚本用另存一份 CSV两份一起发。第三条复现完了才发现前半段事件没了。现象是日志的时间戳从中间某处开始前面的复现动作一条没有。 原因是内存缓冲到顶开始丢最旧的事件或者 Backing File 的上限设得太小滚动文件早被覆盖。 解决是开抓前进 Options Set Backing File指定一个剩余空间充足的盘上限给到 2 GB流程超过十几分钟的中途停一次另存分段抓。第四条时间对不上两条日志拼不起来。现象是 A 机器抓的日志和 B 机器抓的日志放在一起同一个动作的时间差了十几秒没法对齐。 原因有两个跨天时 CSV 里的 Time of Day 只有时分秒日期要看另一列两台机器的系统时钟本身没校准。 解决是对比时统一用完整的 Date Time 列抓取前把两台机器对一次时另外在日志里手动记一笔开始和结束的墙钟时间写在文件名里。第五条换台机器回放过滤条件全没了。现象是现场配好的那套过滤回到工位打开 procmon 发现是默认状态得重新配一遍还容易配错。 原因是过滤器跟着当前会话走不跟着日志文件走。 解决是配好之后在 Filter 菜单里把当前过滤另存成配置文件回放时先加载过滤再加载日志。这一步花十秒能省掉后面反复调参的半小时。6. 把一次抓取变成可复用证据命名、打点与回放6.1 三个让日志能被人接住的习惯第一是命名。日志文件名里至少要有日期、机器标识、目标进程、复现动作、记录人代号用下划线连起来别用空格。比如20240612_WKS0231_app_exe_login_crash_A.pml。这个习惯看着琐碎但当你要在十几份日志里找上周那台机器上登录闪退那次命名规范就是唯一的索引。第二是打点。开抓之后、正式复现之前让操作的人先做一个无害且唯一的动作比如点开目标软件的关于对话框再关掉。这个动作在时间轴上会留下一个非常干净的特征事件后面所有分析都从这个锚点往后数比对着绝对时间戳找起点可靠得多。血泪经验没有锚点的日志回看时你永远不确定复现到底是从第 37 秒还是第 41 秒开始的。第三是回放。拿到 PML 之后不要急着翻事件列表先按第 5 章第五条把过滤配置加载回来再 Tools Process Tree 看一遍进程的生灭顺序最后才进事件列表按 Result 列排序。这个顺序能保证你先看到骨架再填血肉不至于一上来就陷进十万条 CreateFile 里。回放步骤做什么看什么1加载过滤配置确认规则顺序没被改2打开 Process Tree进程生灭、命令行、退出码3事件列表按 Result 排序非 SUCCESS 的集中区域4对可疑事件开 Stack调用链上有没有第三方模块5导出关键片段另存时间窗口 当前过滤一个具体技巧找到可疑时间窗口之后用 Filter 里的Time of Day列加两条边界规则把窗口前后各留 2 秒其余全部 Exclude然后另存一份小日志。这份几百条的切片发给同事或厂商对方看得懂也不会被体量吓退。从那以后我每次开抓之前都会强制走一遍停、清、配、锚、抓五步哪怕只是查一个很小的权限问题。跳过任何一步最后都得用两倍时间补回来。希望帮到你。本文还有配套的精品资源点击获取