简介Process Monitor是微软Sysinternals出品的系统级实时监控工具可全面捕获文件系统、注册表、进程与线程活动。这份docx使用说明正是围绕这一工具撰写面向IT运维人员、系统管理员及需要排查IPGuard/ip-guard客户端异常的技术工程师重点解决软件冲突、权限不足和系统卡顿等问题的定位难题。资源包仅含1个docx文档整体大小84KB篇幅紧凑适合快速查阅。文中用八个步骤清晰串联了使用流程采集前先关闭目标程序、启动时清空事件、按进程名或路径设置筛选条件、重现问题后停止捕获并将结果保存为EVtx文件供后续分析。已有696人学习下载对于正在学习系统监控或处理ip-guard相关故障的读者能够直接获得从捕获、筛选到分析、优化的完整操作思路省去自己摸索的时间。1. 装了管控软件后业务系统偶发无响应Process Monitor 日志抓了一堆却找不到根因报错几乎没有弹窗就是进程僵住、界面卡死、文件明明在却提示被占用——这类问题一旦牵扯到终端上的管控类客户端我这里统称“管控客户端”排查难度会上一个台阶。很多人第一反应是拿起 Process Monitor 一顿猛抓抓完打开一看好几万行事件在疯狂刷屏根本没有“目标软件”什么事Filters 加上去又过滤不干净最后发出去的日志又大又乱分析的人连从哪下手都不知道。这种翻车我在排障里见过太多次。Process Monitor 确实是定位这类系统级冲突最顺手的工具但它默认开机就在捕获不会自动帮你聚焦到“某个进程在某时刻做了什么”。如果操作顺序不对——没先停采、没清空、没设过滤——抓回来的就是一份没人能看懂的黑匣子数据。这篇笔记按采集前的清理、过滤器收敛、保存验证、避坑清单、快速定位五个环节写照着走一遍基本能把“到底是谁拦了谁”这个根因用证据钉死。2. 采集前必须做“停止→清空→待命”这一步不做后面分析全是黑匣子先别说分析了很多人第一步就走歪点开 Process Monitor 就直接让同事“你操作一下吧”。它默认打开那一刻就开始实时捕获系统事件你准备鼠标、点菜单、切窗口的动作全被记录再加上后台几十个进程在读写文件、注册表、网络端口一分钟就能刷出十几万行。等同事把问题重现完你一停日志文件几百 MB打开之后界面卡到拖不动想加过滤条件都费劲。所以标准姿势一定是**先把捕获停掉、把旧事件清空、确认事件计数为 0再让员工开始重现问题。**这一步不花两分钟却决定后面分析是“精准取证”还是“大海捞针”。2.1 默认实时捕获是最容易忽略的坑还没开始操作日志已经刷了几万行Process Monitor 的工具栏上那个放大镜图标就是捕获开关。图标上没有红叉说明“正在捕获”图标上出现一个红叉代表“已停止捕获”。很多第一次用的人以为放大镜就是“看一眼”的意思压根没注意到它一直在后台记录。另外一个容易被忽略的点Process Monitor 用的是内核驱动事件回调记录粒度非常细。进程启动、线程创建、文件打开、注册表读取、网络连接、进程退出全都会往里灌。哪怕你开着它什么都不做光一个系统空闲状态下的 svchost 后台任务每分钟都能产生上千条事件。在这种量级下你想靠肉眼滚列表找“目标进程的异常行为”基本等于在垃圾堆里找一枚别针。2.2 先点放大镜停止再清空事件按这几个按钮顺序不能反习惯性的操作顺序是这样记成一个三步口令停止 → 清空 → 待命。具体动作如下。点击工具栏的放大镜图标使它变成“带红叉”的状态这就是停止捕获。然后点击菜单栏的Edit - Clear Display或者直接按快捷键CtrlX把当前界面上已经显示的事件全部清空。清空之后看界面底部状态栏的事件计数确认已经归零。# 操作顺序GUI 操作按顺序执行 1. 点击工具栏放大镜图标确认图标上出现红叉 # 停止捕获 2. 按 CtrlX 或 Edit - Clear Display # 清空当前显示的事件 3. 观察状态栏确认事件计数为 0 # 进入待命状态这里有个细节清空的是“显示缓冲”不是“停止捕获”。如果你没先点红叉就按CtrlX新事件还会源源不断进来等于白清。反过来先停再清界面就停在“0 条事件”的干净状态等员工开始操作后才会有第一条记录。顺序反了是新手最常见的踩坑没有之一。2.3 首次启动弹的那些确认框许可协议、驱动加载、重置提示分别怎么处理第一次打开 Process Monitor 通常会弹几个提示很多人不敢点或者直接关了导致驱动没加载成功后面抓不到内核层事件。常见归类如下第一个是许可协议确认点同意或接受就好命令行启动时也可以带/accepteula参数跳过这一步第二个是“是否加载内核驱动”的权限确认要选允许否则工具只能看到部分用户态事件很多 ACCESS DENIED 不会出现第三个是清空事件时可能出现的“是否重置显示/丢弃未保存数据”提示这种情况下点确定即可——它其实就是把当前界面上那些还没保存的旧事件清掉重新计数。另外如果弹窗里给了“是否启动时自动开始捕获”之类的开关建议把它关掉让它保持“打开但不采集”的待命状态。这样每次用之前你只需要按 2.2 那三步走一遍就好不用每次去猜它当前到底是在捕还是没在捕。这一步做到位后面的过滤器才有意义。3. 过滤器是 Process Monitor 的命用进程名、路径、结果把千万行压缩成几十行日志抓回来怎么用核心全在过滤。Process Monitor 本身提供了非常细的过滤维度进程名、路径、结果、操作类型、PID、会话 ID甚至包括某个函数的调用栈。如果不设过滤直接看全量日志信息量太大反而等于没有信息而过滤器设得太宽比如只按“进程名包含 exe”这种条件又等于没设。这一章就是把过滤器拆开讲清楚先圈定进程再盯结果字段最后把条件存成文件复用。3.1 先按进程名圈定目标而不是全局逮鱼排查业务软件与管控客户端的冲突时第一层过滤永远应该是“进程名”。比如业务软件的主进程、辅助进程、管控客户端的主进程和它拉起的守护进程先把它们圈出来。打开Filter - Filter...逐行添加条件然后点Add加入列表。我这里给一份可以直接抄的过滤器规则进程名替换成你环境里实际的名称即可。# Process Monitor 过滤器设置Filter - Filter - 逐行添加为“包含”条件 Process Name is 业务软件主进程.exe # 只保留业务软件本身的事件 Process Name is 管控客户端主进程.exe # 保留管控进程观察它做了什么 Process Name is not svchost.exe # 排除系统服务刷屏可选 Path contains C:\Program Files\业务安装目录 # 按路径缩小范围这段规则的含义是只要事件满足其中任意一条就会被显示。Process Name 用is做精确匹配进程名不确定的时候可以用contains做模糊匹配Path 用contains命中目录前缀适合排查某个安装目录下的文件读写。这里有个实用技巧可以先开着全量采集一分钟然后在列表里右键目标进程的任意一行选Include xxx.exe它会自动把该进程名填进过滤器比手敲不容易错。3.2 Result 字段才是证据核心盯着 ACCESS DENIED 和 NAME NOT FOUND进程名圈定之后还要再压一层。真正能说明问题的往往不是“做了什么”而是“做的时候失败了”。Process Monitor 每条事件都有一个 Result 字段最常见的几个值SUCCESS表示成功ACCESS DENIED表示权限不足或路径被拦截NAME NOT FOUND表示目标不存在BUFFER OVERFLOW表示缓冲区不够通常在注册表查询时出现。排查软件冲突和权限问题最值得盯的就是ACCESS DENIED和NAME NOT FOUND。前者通常指向权限拦截、文件被占用、管控软件设置了对某目录的保护后者指向安装包或业务软件在找某个依赖文件但找不到。组合过滤表达式可以这样配# 只显示失败类事件快速定位被拦的关键路径 Result is ACCESS DENIED # 权限被拒/被管控客户端拦截 Result is NAME NOT FOUND # 依赖文件缺失或路径被重定向 Operation is ReadFile # 只看文件读操作 Operation is RegSetValue # 只看注册表写操作适合找配置篡改注意这里的逻辑关系同一列内多个is条件是“或”跨字段之间是“并且”。也就是说上面四行组合出来的效果是结果等于 ACCESS DENIED 或 NAME NOT FOUND并且操作类型是 ReadFile 或 RegSetValue。这样过滤完通常就剩几百条按时间排一下出错时间窗里发生了什么一目了然。3.3 把过滤条件存成 .pmc团队复用口径一致配好一套过滤器别每次重敲。在Filter菜单里选Save Filters...会把当前条件保存成后缀为.pmc的过滤器文件。下次采集前用Load Filters...载入或者命令行启动时直接带上过滤器文件就能保证整个排查小组用的是同一套口径。下面是字段的速查表配置过滤器时对照着填就行字段常见取值典型用途Process Name进程名可用 is/contains圈定业务软件、管控客户端进程Path文件/注册表路径按目录、文件、注册表项收敛OperationReadFile/WriteFile/RegSetValue具体看哪一类系统动作ResultSUCCESS/ACCESS DENIED/NAME NOT FOUND只看成功或只看失败PID进程 ID区分同名进程、定位具体实例一旦把.pmc文件发给做分析的同事大家看的就是同一批被筛选出来的事件不会再出现“一个说看到拒绝、一个说没看到”的对不齐。这个习惯排查越急越有用。4. 重现与保存从红叉停采到导出 PML/CSV四步一步都别省前面的准备工作做完工具已经处于“待命”状态。接下来就是真正的取证环节让员工重现问题然后精准地停止采集并保存。这一步容易出两种错一种是员工重现问题时不克制东点西点把日志重新搞浑一种是采集完保存时选错了格式或范围发出去之后才发现关键事件没被存进去。4.1 让员工重现实操只做会触发问题的那一步别附带多余操作给员工的操作口令可以简化成一句话关闭目标软件 → 确认工具状态是“已停止捕获、事件 0” → 打开目标软件 → 只做会出错的那个操作 → 停下。针对管控客户端场景通常会先让员工做一次平时正常的操作再做一次触发异常的操作两次中间加个几秒间隔方便你在时间轴上区分正常与异常。这里特别要提醒让员工操作前先跟他讲清楚“不要为了演示去试其他功能不要边操作边跟你解释”。因为 Process Monitor 记录的是全系统事件哪怕他在等待界面弹窗时多点了两下右键菜单、切了下窗口这些都会产生额外事件。操作步骤越少后期定位误差越小。如果员工说“问题偶尔才出现”那就让他反复做同一个动作每次停顿 5 秒捕获一段时间后再统一停止。操作完成后点击工具栏上那个“带红叉的放大镜”停止捕获。此时界面停在最后一屏事件但注意界面上能看到的事件并不等于保存下来的事件下一步保存才是关键。4.2 保存格式怎么选PML、CSV、EVTx 各干各的活点击File - Save或工具栏保存按钮会弹出保存格式选择。不同后缀对应不同用途别默认一路下一步就完了。格式特点适用场景PMLProcess Monitor 原生格式保留完整事件信息可随时重新打开继续过滤首选分析格式保留原始证据CSV文本表格可直接用数据处理脚本读取要导给同事用其他工具统计时用EVTx兼容事件日志格式便于与其他事件日志工具衔接需要交给审计或跨工具平台处理时保存时把文件名写到问题相关的命名比如业务软件_卡死_时间戳.pml比默认的 log 文件名靠谱很多。另外有个建议如果当场同时拉了多个进程优先存 PMLCSV 适合过滤干净之后的一段小数据不适合保存小几 GB 的全量事件否则处理起来很痛苦。保存路径上也有个细节不要把日志存在被管控客户端监控的目录下以免“采集物证的工具自身又被监控软件干扰”。4.3 保存时的“三看”验证事件数、文件大小、能不能打开保存这件事我在实际排查中被坑过好几次所以现在每次都按“三看”来验收。第一看保存前看一眼工具底部的事件计数确认不是 0保存时如果弹窗问保存范围选“所有事件”而不要选“当前显示的事件”——后者在过滤条件生效时存下来的可能只有几十行等于把证据扔了。第二看保存完成后在资源管理器里看文件大小PML 日志通常至少几 MB 到几百 MB小于 1 MB 时就要怀疑只保存了过滤后的局部数据。第三看双击生成的 PML 文件确认 Process Monitor 能正常打开并且事件行数和停采时界面上的计数一致。# 保存后打开验证的常用做法 1. 停采后确认事件计数 0 2. File - Save格式选 PML保存范围选“All events” 3. 在资源管理器中确认文件大小正常 4. 双击重新打开对比底部计数是否一致如果打开后只有 0 条不要急着截图发日志先回去把保存范围改成“所有事件”重新导一次。这个验证动作不到三十秒却能让分析师少对着空文件骂一句脏话。5. 避坑Process Monitor 采集日志最常见的几个翻车点这一章不是理论是实打实的踩坑记录。下面每条都是“现象 → 原因 → 解决”的结构你可以直接对照自己的情况套用。5.1 采集环境类日志几个 GB 打开卡死 / 没清空就开抓现象采集了二十分钟日志文件好几个 GBProcess Monitor 打开后界面无响应加过滤条件也一样卡。或者更夸张的明明还没开始操作日志已经有几万条分析时发现全是系统进程刷屏。原因第一种是没设过滤就开始采集还把网络、注册表、文件系统全勾上了事件量直接爆掉第二种是没先点红叉停采、没清空工具从启动那一刻起就一直在记录准备阶段的动作全录进去了。解决这是习惯问题不是工具问题。每次采集前强制走“停止 → 清空 → 确认事件为 0”三步如果只是要快速定位某个场景可以用命令行限定采集时长和输出文件大小。下面这个命令是我常用的兜底方案适合远程让同事执行# 分布式采集场景限定运行时长避免日志变成巨型文件 procmon.exe /accepteula /backingfile D:\trace\issue\.pml /runtime 120 /quiet # /accepteula 自动同意首次许可协议避免进程卡在弹窗 # /backingfile 指定保存路径文件名可加时间戳方便区分 # /runtime 120 最多采集 120 秒后自动停止防止忘记停采 # /quiet 最小化运行不弹出主界面适合让同事无脑执行5.2 过滤与分析类加了过滤还是搜不到 / ACCESS DENIED 死活不出现现象过滤器明明设了“进程名 is 业务软件.exe”打开日志却一条该进程的事件都没有或者明显感觉软件被文件写权限拦截了但日志里遍寻不到 ACCESS DENIED。原因过滤路径和实际路径对不上。比如过滤条件写的是完整目录Path contains C:\Program Files\某软件但实际运行时它读的是C:\Users\用户名\AppData\Roaming\某软件不同用户名的机器路径不一样自然一条都命中不了。至于找不到 ACCESS DENIED通常是结果列没显示出来——Process Monitor 的列表列是可以在列头右键自定义的默认布局有时没把 Result 列放出来或者过滤条件写的是Result is not SUCCESS反而把 SUCCESS 之外的值全过滤光了。解决路径过滤尽量只写固定的进程名不写完整绝对路径如果是看注册表先用一次全量采集确认实际路径再改规则。列没显示时右键列头勾选 Result 和 Path 两列排在最前面。想看失败事件时直接用这个组合Result is ACCESS DENIED加上Process Name is 目标进程.exe不要用“不等于成功”这种反向写法很容易误伤。调整过滤器之后如果界面上事件没变记得重开一次文件或者用菜单里的Reset Display重置视图让它按新条件重新渲染。5.3 保存与交接类导出的日志是空文件 / 团队对不上口径现象把 PML 文件打包发给同事对方打开只有几行或者干脆 0 行同一个问题两个人拉出来的日志结论完全不一样一个说看到删除操作一个说根本没看到。原因一是保存时没注意把范围选成“所有事件”只保存了当时界面上过滤后的那几十行二是没统一过滤条件各自按自己的理解去采集一个圈了进程、一个圈了路径最后看到的事件集合完全不同。解决保存时先看底部计数大于 0再在保存对话框里确认范围是All events文件发出去之前自己双击打开验证一遍。团队一起排查时把.pmc过滤器文件和采集步骤一并发给所有人谁采都可以但口径必须一致。发文件时最好保留原始 PML不要只发导出的 CSV——CSV 丢掉了部分系统级别细节后期想往下钻堆栈就做不到了。6. 快速定位拿到一份采集日志三分钟找到可疑事件先不急着一条条翻。把日志拖进 Process Monitor 后第一步是调整视图顺序点击Result列头让ACCESS DENIED排到最上面。红叉标记在列表里非常显眼一眼就能扫到失败事件集中在哪个进程、哪个路径上。如果 Result 列没显示右键列头勾上即可。这一步能把“可疑事件”从几千条压缩成一屏。第二步用时间线框定时间窗。Process Monitor 界面上方的横条是时间线视图窗口操作时日志体积巨大横向拖拽时间轴只框住出错的那几十秒。然后按CtrlL打开过滤器在 Process Name 条件里加上在这个时间窗内动作最频繁的进程立刻就能看到是谁在关键时间点不停读写。如果嫌一条条看太慢直接在可疑行上双击右侧会弹出该事件的调用栈能看出这个行为是从哪个模块里发起——这通常就是管控客户端注入的钩子或业务软件自身的逻辑。第三步善用 Mark 高亮。遇到一条明显有嫌疑的事件按CtrlM打上高亮标记接着继续扫。排查完回看时所有标记过的事件会从一堆黑白数据里跳出来方便把证据串成时间线。这比截图一堆日志靠谱得多——截图看不出顺序Mark 能保留原始事件位置。从那以后我每次采集前都会强制自己走一遍“停采 → 清空 → 设过滤 → 确认计数为 0 → 才让同事动手”的流程保存完先打开验证有数据再交付。这套动作多花五分钟省掉的返工时间却是按小时算的。希望这段排错笔记能帮到你也祝你在下次日志分析里三分钟就命中那个真正的问题。本文还有配套的精品资源点击获取 
长河君 · 2026/10/17 22:45:20 · 阅读 1.2k Process Monitor排障实战：停采清空+过滤器三分钟定位根因
简介Process Monitor是微软Sysinternals出品的系统级实时监控工具可全面捕获文件系统、注册表、进程与线程活动。这份docx使用说明正是围绕这一工具撰写面向IT运维人员、系统管理员及需要排查IPGuard/ip-guard客户端异常的技术工程师重点解决软件冲突、权限不足和系统卡顿等问题的定位难题。资源包仅含1个docx文档整体大小84KB篇幅紧凑适合快速查阅。文中用八个步骤清晰串联了使用流程采集前先关闭目标程序、启动时清空事件、按进程名或路径设置筛选条件、重现问题后停止捕获并将结果保存为EVtx文件供后续分析。已有696人学习下载对于正在学习系统监控或处理ip-guard相关故障的读者能够直接获得从捕获、筛选到分析、优化的完整操作思路省去自己摸索的时间。1. 装了管控软件后业务系统偶发无响应Process Monitor 日志抓了一堆却找不到根因报错几乎没有弹窗就是进程僵住、界面卡死、文件明明在却提示被占用——这类问题一旦牵扯到终端上的管控类客户端我这里统称“管控客户端”排查难度会上一个台阶。很多人第一反应是拿起 Process Monitor 一顿猛抓抓完打开一看好几万行事件在疯狂刷屏根本没有“目标软件”什么事Filters 加上去又过滤不干净最后发出去的日志又大又乱分析的人连从哪下手都不知道。这种翻车我在排障里见过太多次。Process Monitor 确实是定位这类系统级冲突最顺手的工具但它默认开机就在捕获不会自动帮你聚焦到“某个进程在某时刻做了什么”。如果操作顺序不对——没先停采、没清空、没设过滤——抓回来的就是一份没人能看懂的黑匣子数据。这篇笔记按采集前的清理、过滤器收敛、保存验证、避坑清单、快速定位五个环节写照着走一遍基本能把“到底是谁拦了谁”这个根因用证据钉死。2. 采集前必须做“停止→清空→待命”这一步不做后面分析全是黑匣子先别说分析了很多人第一步就走歪点开 Process Monitor 就直接让同事“你操作一下吧”。它默认打开那一刻就开始实时捕获系统事件你准备鼠标、点菜单、切窗口的动作全被记录再加上后台几十个进程在读写文件、注册表、网络端口一分钟就能刷出十几万行。等同事把问题重现完你一停日志文件几百 MB打开之后界面卡到拖不动想加过滤条件都费劲。所以标准姿势一定是**先把捕获停掉、把旧事件清空、确认事件计数为 0再让员工开始重现问题。**这一步不花两分钟却决定后面分析是“精准取证”还是“大海捞针”。2.1 默认实时捕获是最容易忽略的坑还没开始操作日志已经刷了几万行Process Monitor 的工具栏上那个放大镜图标就是捕获开关。图标上没有红叉说明“正在捕获”图标上出现一个红叉代表“已停止捕获”。很多第一次用的人以为放大镜就是“看一眼”的意思压根没注意到它一直在后台记录。另外一个容易被忽略的点Process Monitor 用的是内核驱动事件回调记录粒度非常细。进程启动、线程创建、文件打开、注册表读取、网络连接、进程退出全都会往里灌。哪怕你开着它什么都不做光一个系统空闲状态下的 svchost 后台任务每分钟都能产生上千条事件。在这种量级下你想靠肉眼滚列表找“目标进程的异常行为”基本等于在垃圾堆里找一枚别针。2.2 先点放大镜停止再清空事件按这几个按钮顺序不能反习惯性的操作顺序是这样记成一个三步口令停止 → 清空 → 待命。具体动作如下。点击工具栏的放大镜图标使它变成“带红叉”的状态这就是停止捕获。然后点击菜单栏的Edit - Clear Display或者直接按快捷键CtrlX把当前界面上已经显示的事件全部清空。清空之后看界面底部状态栏的事件计数确认已经归零。# 操作顺序GUI 操作按顺序执行 1. 点击工具栏放大镜图标确认图标上出现红叉 # 停止捕获 2. 按 CtrlX 或 Edit - Clear Display # 清空当前显示的事件 3. 观察状态栏确认事件计数为 0 # 进入待命状态这里有个细节清空的是“显示缓冲”不是“停止捕获”。如果你没先点红叉就按CtrlX新事件还会源源不断进来等于白清。反过来先停再清界面就停在“0 条事件”的干净状态等员工开始操作后才会有第一条记录。顺序反了是新手最常见的踩坑没有之一。2.3 首次启动弹的那些确认框许可协议、驱动加载、重置提示分别怎么处理第一次打开 Process Monitor 通常会弹几个提示很多人不敢点或者直接关了导致驱动没加载成功后面抓不到内核层事件。常见归类如下第一个是许可协议确认点同意或接受就好命令行启动时也可以带/accepteula参数跳过这一步第二个是“是否加载内核驱动”的权限确认要选允许否则工具只能看到部分用户态事件很多 ACCESS DENIED 不会出现第三个是清空事件时可能出现的“是否重置显示/丢弃未保存数据”提示这种情况下点确定即可——它其实就是把当前界面上那些还没保存的旧事件清掉重新计数。另外如果弹窗里给了“是否启动时自动开始捕获”之类的开关建议把它关掉让它保持“打开但不采集”的待命状态。这样每次用之前你只需要按 2.2 那三步走一遍就好不用每次去猜它当前到底是在捕还是没在捕。这一步做到位后面的过滤器才有意义。3. 过滤器是 Process Monitor 的命用进程名、路径、结果把千万行压缩成几十行日志抓回来怎么用核心全在过滤。Process Monitor 本身提供了非常细的过滤维度进程名、路径、结果、操作类型、PID、会话 ID甚至包括某个函数的调用栈。如果不设过滤直接看全量日志信息量太大反而等于没有信息而过滤器设得太宽比如只按“进程名包含 exe”这种条件又等于没设。这一章就是把过滤器拆开讲清楚先圈定进程再盯结果字段最后把条件存成文件复用。3.1 先按进程名圈定目标而不是全局逮鱼排查业务软件与管控客户端的冲突时第一层过滤永远应该是“进程名”。比如业务软件的主进程、辅助进程、管控客户端的主进程和它拉起的守护进程先把它们圈出来。打开Filter - Filter...逐行添加条件然后点Add加入列表。我这里给一份可以直接抄的过滤器规则进程名替换成你环境里实际的名称即可。# Process Monitor 过滤器设置Filter - Filter - 逐行添加为“包含”条件 Process Name is 业务软件主进程.exe # 只保留业务软件本身的事件 Process Name is 管控客户端主进程.exe # 保留管控进程观察它做了什么 Process Name is not svchost.exe # 排除系统服务刷屏可选 Path contains C:\Program Files\业务安装目录 # 按路径缩小范围这段规则的含义是只要事件满足其中任意一条就会被显示。Process Name 用is做精确匹配进程名不确定的时候可以用contains做模糊匹配Path 用contains命中目录前缀适合排查某个安装目录下的文件读写。这里有个实用技巧可以先开着全量采集一分钟然后在列表里右键目标进程的任意一行选Include xxx.exe它会自动把该进程名填进过滤器比手敲不容易错。3.2 Result 字段才是证据核心盯着 ACCESS DENIED 和 NAME NOT FOUND进程名圈定之后还要再压一层。真正能说明问题的往往不是“做了什么”而是“做的时候失败了”。Process Monitor 每条事件都有一个 Result 字段最常见的几个值SUCCESS表示成功ACCESS DENIED表示权限不足或路径被拦截NAME NOT FOUND表示目标不存在BUFFER OVERFLOW表示缓冲区不够通常在注册表查询时出现。排查软件冲突和权限问题最值得盯的就是ACCESS DENIED和NAME NOT FOUND。前者通常指向权限拦截、文件被占用、管控软件设置了对某目录的保护后者指向安装包或业务软件在找某个依赖文件但找不到。组合过滤表达式可以这样配# 只显示失败类事件快速定位被拦的关键路径 Result is ACCESS DENIED # 权限被拒/被管控客户端拦截 Result is NAME NOT FOUND # 依赖文件缺失或路径被重定向 Operation is ReadFile # 只看文件读操作 Operation is RegSetValue # 只看注册表写操作适合找配置篡改注意这里的逻辑关系同一列内多个is条件是“或”跨字段之间是“并且”。也就是说上面四行组合出来的效果是结果等于 ACCESS DENIED 或 NAME NOT FOUND并且操作类型是 ReadFile 或 RegSetValue。这样过滤完通常就剩几百条按时间排一下出错时间窗里发生了什么一目了然。3.3 把过滤条件存成 .pmc团队复用口径一致配好一套过滤器别每次重敲。在Filter菜单里选Save Filters...会把当前条件保存成后缀为.pmc的过滤器文件。下次采集前用Load Filters...载入或者命令行启动时直接带上过滤器文件就能保证整个排查小组用的是同一套口径。下面是字段的速查表配置过滤器时对照着填就行字段常见取值典型用途Process Name进程名可用 is/contains圈定业务软件、管控客户端进程Path文件/注册表路径按目录、文件、注册表项收敛OperationReadFile/WriteFile/RegSetValue具体看哪一类系统动作ResultSUCCESS/ACCESS DENIED/NAME NOT FOUND只看成功或只看失败PID进程 ID区分同名进程、定位具体实例一旦把.pmc文件发给做分析的同事大家看的就是同一批被筛选出来的事件不会再出现“一个说看到拒绝、一个说没看到”的对不齐。这个习惯排查越急越有用。4. 重现与保存从红叉停采到导出 PML/CSV四步一步都别省前面的准备工作做完工具已经处于“待命”状态。接下来就是真正的取证环节让员工重现问题然后精准地停止采集并保存。这一步容易出两种错一种是员工重现问题时不克制东点西点把日志重新搞浑一种是采集完保存时选错了格式或范围发出去之后才发现关键事件没被存进去。4.1 让员工重现实操只做会触发问题的那一步别附带多余操作给员工的操作口令可以简化成一句话关闭目标软件 → 确认工具状态是“已停止捕获、事件 0” → 打开目标软件 → 只做会出错的那个操作 → 停下。针对管控客户端场景通常会先让员工做一次平时正常的操作再做一次触发异常的操作两次中间加个几秒间隔方便你在时间轴上区分正常与异常。这里特别要提醒让员工操作前先跟他讲清楚“不要为了演示去试其他功能不要边操作边跟你解释”。因为 Process Monitor 记录的是全系统事件哪怕他在等待界面弹窗时多点了两下右键菜单、切了下窗口这些都会产生额外事件。操作步骤越少后期定位误差越小。如果员工说“问题偶尔才出现”那就让他反复做同一个动作每次停顿 5 秒捕获一段时间后再统一停止。操作完成后点击工具栏上那个“带红叉的放大镜”停止捕获。此时界面停在最后一屏事件但注意界面上能看到的事件并不等于保存下来的事件下一步保存才是关键。4.2 保存格式怎么选PML、CSV、EVTx 各干各的活点击File - Save或工具栏保存按钮会弹出保存格式选择。不同后缀对应不同用途别默认一路下一步就完了。格式特点适用场景PMLProcess Monitor 原生格式保留完整事件信息可随时重新打开继续过滤首选分析格式保留原始证据CSV文本表格可直接用数据处理脚本读取要导给同事用其他工具统计时用EVTx兼容事件日志格式便于与其他事件日志工具衔接需要交给审计或跨工具平台处理时保存时把文件名写到问题相关的命名比如业务软件_卡死_时间戳.pml比默认的 log 文件名靠谱很多。另外有个建议如果当场同时拉了多个进程优先存 PMLCSV 适合过滤干净之后的一段小数据不适合保存小几 GB 的全量事件否则处理起来很痛苦。保存路径上也有个细节不要把日志存在被管控客户端监控的目录下以免“采集物证的工具自身又被监控软件干扰”。4.3 保存时的“三看”验证事件数、文件大小、能不能打开保存这件事我在实际排查中被坑过好几次所以现在每次都按“三看”来验收。第一看保存前看一眼工具底部的事件计数确认不是 0保存时如果弹窗问保存范围选“所有事件”而不要选“当前显示的事件”——后者在过滤条件生效时存下来的可能只有几十行等于把证据扔了。第二看保存完成后在资源管理器里看文件大小PML 日志通常至少几 MB 到几百 MB小于 1 MB 时就要怀疑只保存了过滤后的局部数据。第三看双击生成的 PML 文件确认 Process Monitor 能正常打开并且事件行数和停采时界面上的计数一致。# 保存后打开验证的常用做法 1. 停采后确认事件计数 0 2. File - Save格式选 PML保存范围选“All events” 3. 在资源管理器中确认文件大小正常 4. 双击重新打开对比底部计数是否一致如果打开后只有 0 条不要急着截图发日志先回去把保存范围改成“所有事件”重新导一次。这个验证动作不到三十秒却能让分析师少对着空文件骂一句脏话。5. 避坑Process Monitor 采集日志最常见的几个翻车点这一章不是理论是实打实的踩坑记录。下面每条都是“现象 → 原因 → 解决”的结构你可以直接对照自己的情况套用。5.1 采集环境类日志几个 GB 打开卡死 / 没清空就开抓现象采集了二十分钟日志文件好几个 GBProcess Monitor 打开后界面无响应加过滤条件也一样卡。或者更夸张的明明还没开始操作日志已经有几万条分析时发现全是系统进程刷屏。原因第一种是没设过滤就开始采集还把网络、注册表、文件系统全勾上了事件量直接爆掉第二种是没先点红叉停采、没清空工具从启动那一刻起就一直在记录准备阶段的动作全录进去了。解决这是习惯问题不是工具问题。每次采集前强制走“停止 → 清空 → 确认事件为 0”三步如果只是要快速定位某个场景可以用命令行限定采集时长和输出文件大小。下面这个命令是我常用的兜底方案适合远程让同事执行# 分布式采集场景限定运行时长避免日志变成巨型文件 procmon.exe /accepteula /backingfile D:\trace\issue\.pml /runtime 120 /quiet # /accepteula 自动同意首次许可协议避免进程卡在弹窗 # /backingfile 指定保存路径文件名可加时间戳方便区分 # /runtime 120 最多采集 120 秒后自动停止防止忘记停采 # /quiet 最小化运行不弹出主界面适合让同事无脑执行5.2 过滤与分析类加了过滤还是搜不到 / ACCESS DENIED 死活不出现现象过滤器明明设了“进程名 is 业务软件.exe”打开日志却一条该进程的事件都没有或者明显感觉软件被文件写权限拦截了但日志里遍寻不到 ACCESS DENIED。原因过滤路径和实际路径对不上。比如过滤条件写的是完整目录Path contains C:\Program Files\某软件但实际运行时它读的是C:\Users\用户名\AppData\Roaming\某软件不同用户名的机器路径不一样自然一条都命中不了。至于找不到 ACCESS DENIED通常是结果列没显示出来——Process Monitor 的列表列是可以在列头右键自定义的默认布局有时没把 Result 列放出来或者过滤条件写的是Result is not SUCCESS反而把 SUCCESS 之外的值全过滤光了。解决路径过滤尽量只写固定的进程名不写完整绝对路径如果是看注册表先用一次全量采集确认实际路径再改规则。列没显示时右键列头勾选 Result 和 Path 两列排在最前面。想看失败事件时直接用这个组合Result is ACCESS DENIED加上Process Name is 目标进程.exe不要用“不等于成功”这种反向写法很容易误伤。调整过滤器之后如果界面上事件没变记得重开一次文件或者用菜单里的Reset Display重置视图让它按新条件重新渲染。5.3 保存与交接类导出的日志是空文件 / 团队对不上口径现象把 PML 文件打包发给同事对方打开只有几行或者干脆 0 行同一个问题两个人拉出来的日志结论完全不一样一个说看到删除操作一个说根本没看到。原因一是保存时没注意把范围选成“所有事件”只保存了当时界面上过滤后的那几十行二是没统一过滤条件各自按自己的理解去采集一个圈了进程、一个圈了路径最后看到的事件集合完全不同。解决保存时先看底部计数大于 0再在保存对话框里确认范围是All events文件发出去之前自己双击打开验证一遍。团队一起排查时把.pmc过滤器文件和采集步骤一并发给所有人谁采都可以但口径必须一致。发文件时最好保留原始 PML不要只发导出的 CSV——CSV 丢掉了部分系统级别细节后期想往下钻堆栈就做不到了。6. 快速定位拿到一份采集日志三分钟找到可疑事件先不急着一条条翻。把日志拖进 Process Monitor 后第一步是调整视图顺序点击Result列头让ACCESS DENIED排到最上面。红叉标记在列表里非常显眼一眼就能扫到失败事件集中在哪个进程、哪个路径上。如果 Result 列没显示右键列头勾上即可。这一步能把“可疑事件”从几千条压缩成一屏。第二步用时间线框定时间窗。Process Monitor 界面上方的横条是时间线视图窗口操作时日志体积巨大横向拖拽时间轴只框住出错的那几十秒。然后按CtrlL打开过滤器在 Process Name 条件里加上在这个时间窗内动作最频繁的进程立刻就能看到是谁在关键时间点不停读写。如果嫌一条条看太慢直接在可疑行上双击右侧会弹出该事件的调用栈能看出这个行为是从哪个模块里发起——这通常就是管控客户端注入的钩子或业务软件自身的逻辑。第三步善用 Mark 高亮。遇到一条明显有嫌疑的事件按CtrlM打上高亮标记接着继续扫。排查完回看时所有标记过的事件会从一堆黑白数据里跳出来方便把证据串成时间线。这比截图一堆日志靠谱得多——截图看不出顺序Mark 能保留原始事件位置。从那以后我每次采集前都会强制自己走一遍“停采 → 清空 → 设过滤 → 确认计数为 0 → 才让同事动手”的流程保存完先打开验证有数据再交付。这套动作多花五分钟省掉的返工时间却是按小时算的。希望这段排错笔记能帮到你也祝你在下次日志分析里三分钟就命中那个真正的问题。本文还有配套的精品资源点击获取