个人主页杨利杰YJlio❄️个人专栏《Sysinternals实战教程》 《Windows PowerShell 实战》 《WINDOWS教程》 《IOS教程》《微信助手》 《锤子助手》 《Python》 《Kali Linux》《那些年未解决的Windows疑难杂症》让复杂的事情更简单让重复的工作自动化《Windows Sysinternals实战指南》5.10 Process Monitor 学习笔记分析工具——从海量事件到可下手的证据1. 为什么要学 Procmon 的分析工具2. 分析工具的基本思路先看全局再下钻再溯源3. 五大汇总面板先用 TopN 找嫌疑对象3.1 Process Activity Summary先看哪个进程最忙3.2 File Summary看最热文件和路径3.3 Registry Summary看配置访问和注册表热点3.4 Network Summary看连接对象和失败分布3.5 Count Occurrences看错误码和操作分布4. 从 TopN 下钻把汇总结果带回主表4.1 推荐列视图4.2 Result 不是唯一判断标准4.3 Jump To从日志直接跳到资源位置5. Stack 调用栈从现象追到触发模块5.1 打开 Stack 的方式5.2 配置符号服务器5.3 Stack 应该看什么6. 三个高命中率排障配方6.1 无法保存或权限不足6.2 启动慢或登录卡顿6.3 应用偶发假死7. 最小工作流3 到 5 分钟压缩嫌疑面7.1 推荐证据四元组8. 证据导出与截图留痕8.1 建议保存哪些内容8.2 建议命名方式9. 常见误区与风险提醒9.1 Summary 只统计当前视图9.2 Stack 会增加体积和开销10. 如何写进工单和复盘11. 总结抓得多不如看得准1. 为什么要学 Procmon 的分析工具前面几篇已经讲过 Process Monitor 的事件模型、过滤器、高亮、Process Tree、PML 保存、Boot Logging、长时间追踪、配置模板和命令行自动化。到这里一个现实问题就出来了日志已经抓到了可是几十万条事件摆在眼前应该从哪里开始看很多人用 Procmon 卡在这一步。不是不会抓而是抓完以后只会按关键词搜索或者从第一行开始慢慢翻。这样做效率很低也容易被最后一个报错误导。真正高效的做法是先用 Procmon 内置的 Summary、Count、Stack 等分析工具把海量事件压缩成几个可下手的嫌疑点。我的理解是过滤器解决“少抓噪声”分析工具解决“从已抓日志里提炼证据”。两者不是替代关系而是前后配合。在企业桌面支持场景里这个能力非常实用。比如 Outlook 启动慢、Explorer 登录后卡顿、OneDrive 同步异常、Teams 加载慢、EDR 或 DLP 疑似拖慢系统这些问题抓到 PML 以后如果直接逐行翻日志很快就会失去方向。你需要先知道哪个进程最忙、哪个路径最热、哪个注册表键最可疑、哪个 Result 最集中再决定是否下钻到 Detail 和 Stack。这张图对应本文核心Procmon 分析工具的目标是把“海量事件”压缩成“可行动证据”。2. 分析工具的基本思路先看全局再下钻再溯源Procmon 的分析顺序不建议一上来就看 Stack也不建议一上来就找某个具体路径。更稳的顺序是三步先看全局再下钻再溯源。打开 PML查看 Summary 汇总锁定 TopN 进程 / 路径 / 错误码返回主表带过滤下钻查看 Result / Detail / Duration查看 Stack 调用栈形成证据结论第一步是全局视角。用 Process Activity Summary、File Summary、Registry Summary、Network Summary 和 Count Occurrences看谁最忙、谁读写最多、谁失败最多。第二步是下钻视角。双击 Summary 中的某一行回到主表只看某个进程、路径或注册表键相关事件。第三步是溯源视角。对关键失败或慢事件打开 Stack看具体是哪个模块、DLL、驱动或组件触发了操作。不要跳过全局视角直接看单条事件。单条事件可能很吓人但未必重要TopN 统计往往更接近问题主线。这个思路和 Mark 式排障是一致的先固定边界再看证据链最后验证假设。用户说“卡”这只是现象Process Summary 告诉你哪个进程最忙File Summary 告诉你哪个路径最热Count Occurrences 告诉你错误码分布Stack 才负责进一步回答“是谁触发的”。一句话Summary 负责缩小范围Count 负责看分布Stack 负责找来源。3. 五大汇总面板先用 TopN 找嫌疑对象Procmon 的 Tools 菜单下提供了多个 Summary 工具。它们的价值不是展示更多信息而是把分散在主表里的事件按不同维度聚合起来。对于几十万行日志来说Summary 是第一刀。3.1 Process Activity Summary先看哪个进程最忙Process Activity Summary 按进程聚合事件。它可以帮助你判断哪个进程事件量最大、读写最重、注册表操作最多、网络活动最集中。对于启动慢、登录慢、卡顿、高 IO 场景这是很好的第一入口。打开路径 Tools → Process Activity Summary常见操作是按 Operation Count、Read Bytes、Write Bytes、Total Bytes 排序先看 Top 5。双击某个进程后Procmon 会回到主界面并按该进程过滤。如果你不知道从哪里看先看 Process Activity Summary。它能快速告诉你“谁最吵”。3.2 File Summary看最热文件和路径File Summary 按文件路径聚合事件。它适合排查高 IO、文件反复打开、日志疯狂写入、配置文件被频繁读取、保存失败、文件被占用等问题。打开路径 Tools → File Summary建议优先按 Opens、Reads、Writes、Read Bytes、Write Bytes、Failures 排序。对于软件启动慢的问题File Summary 经常能直接暴露反复访问的配置文件、插件目录、缓存目录或网络路径。文件问题不要只看 Result。大量成功访问也可能是性能问题尤其要结合 Duration 和读写次数。3.3 Registry Summary看配置访问和注册表热点Registry Summary 按注册表 Key 聚合事件。它适合排查应用启动慢、配置缺失、加载项异常、策略生效异常、安装失败等问题。打开路径 Tools → Registry Summary比如 Outlook 加载项问题可以重点看 Office Addins、CLSID、HKCU/HKLM Software 分支。安装程序异常时可以看是否大量出现 ACCESS DENIED、NAME NOT FOUND 或 RegSetValue 失败。Registry Summary 很适合找“反复读写的配置点”。它能把主表里零散的注册表事件聚成一条线索。3.4 Network Summary看连接对象和失败分布如果当前 Procmon 版本支持 Network Summary可以用它查看进程连接的远端地址、端口、连接次数和失败情况。它不是抓包工具不能替代 Wireshark但可以回答“谁在连哪里是否失败”。打开路径 Tools → Network Summary在代理、证书验证、域控访问、远程路径、云服务连接异常场景中Network Summary 有一定价值。尤其是启动慢时如果发现某个进程在启动阶段反复连接某个远端地址并超时就应该进一步结合防火墙、代理和 DNS 继续验证。3.5 Count Occurrences看错误码和操作分布Count Occurrences 可以对当前视图里的某一列做分组统计。它最适合用来统计 Result、Operation、Process Name、Path 等字段。打开路径 Tools → Count Occurrences...比如你可以对 Result 做统计看 ACCESS DENIED、NAME NOT FOUND、SHARING VIOLATION、PATH NOT FOUND 谁最多也可以对 Operation 做统计看 CreateFile、RegOpenKey、RegSetValue、TCP Connect 哪类操作最集中。Count Occurrences 统计的是当前视图不是永远统计全量日志。先确认当前过滤范围再看统计结果。4. 从 TopN 下钻把汇总结果带回主表Summary 的作用不是停留在排行榜而是帮助你回到主表继续分析。看到 TopN 以后下一步要做的是下钻对某个进程、路径、注册表键或错误码建立过滤只看相关事件。很多 Summary 视图支持双击条目或右键筛选回到主表后只显示对应对象的事件。此时再结合 Result、Detail、Duration 和时间线才能判断它到底是不是关键问题。4.1 推荐列视图下钻分析时建议使用下面这组列Time of Day Process Name PID Operation Path Result Detail Duration这组列基本覆盖了“什么时候、谁、做了什么、对哪个对象、结果如何、细节是什么、耗时多久”。如果要看用户上下文可以再加 User、Session、Integrity。Procmon 主表不是所有列都越多越好。列太多反而影响阅读关键是能支撑证据链。4.2 Result 不是唯一判断标准很多人只看 Result这是不够的。比如 NAME NOT FOUND 在 DLL 搜索和配置探测里很常见未必是错误BUFFER OVERFLOW 多数情况下是长度探测也不一定是故障。性能问题更要看 Duration 和重复次数。字段重点看什么Result是否失败失败类型是什么DetailDesired Access、ShareMode、Disposition、Length、OptionsDuration是否明显高于同类事件Time of Day是否和用户反馈时间一致Path是否指向业务路径、配置路径、网络路径Process Name是否为目标进程或第三方组件单条 ACCESS DENIED 不一定是根因连续、高频、与故障时间重合的 ACCESS DENIED 才值得重点看。4.3 Jump To从日志直接跳到资源位置下钻到具体文件或注册表键后可以使用右键 Jump To。文件事件可以跳转到资源管理器位置注册表事件可以跳转到 Regedit 对应 Key。这个动作适合现场快速验证权限、路径是否存在、配置是否被写入。Jump To 的价值是把“日志线索”快速连接到“系统对象”。排障不是只看日志最终要回到对象本身。5. Stack 调用栈从现象追到触发模块Summary 和 Count 能告诉你哪里可疑但它们通常不能直接告诉你“是谁触发的”。要回答这个问题就需要 Stack。Stack 调用栈能把一个文件、注册表或网络操作还原到调用路径上帮助识别第三方 DLL、插件、驱动或安全组件。5.1 打开 Stack 的方式在主表中选中关键事件右键选择 Stack或者打开事件属性后查看 Stack 标签。如果采集时没有开启调用栈可能看不到完整栈信息。因此是否需要 Stack 要在采集前决定。主表事件 → 右键 → Stack...Stack 不是事后凭空生成的。如果采集时没有记录后续无法完整还原。5.2 配置符号服务器没有符号时Stack 里可能只有地址或不清晰的模块名。配置符号服务器后系统模块和部分调用路径会更容易读懂。Options → Configure Symbols常用符号路径如下srv*C:\Symbols*https://msdl.microsoft.com/download/symbols第一次解析会比较慢因为需要下载符号文件。后续命中本地缓存速度会明显提升。符号路径不是装饰项。要做调用栈溯源符号配置非常关键。5.3 Stack 应该看什么看 Stack 时不要被系统模块吓住。很多栈都会出现 ntdll、kernelbase、ntoskrnl 等系统模块这并不一定说明系统有问题。更关键的是在栈中识别非系统模块、第三方 DLL、插件、过滤驱动、安全软件组件。栈位置观察重点用户态栈顶哪个 DLL 或模块发起调用用户态中间层是否有插件、加载项、业务组件内核态路径是否有过滤驱动、安全驱动、加密驱动重复出现的模块是否每次失败都出现同一模块异常 Result 关联栈是否与 ACCESS DENIED / SHARING VIOLATION 同时出现Stack 的核心不是看懂每一帧而是找出“非系统、反复出现、与异常同步”的模块。6. 三个高命中率排障配方下面这三套配方适合直接放到团队 SOP 里。它们不是万能答案但能覆盖大量桌面支持场景。6.1 无法保存或权限不足现象通常是文件无法保存、提示权限不足、保存后内容丢失、临时文件无法重命名等。建议按下面顺序处理1. 打开 File Summary 2. 按 Write Failures / Write Bytes / Opens 排序 3. 回主表 Include 目标路径 4. 查看 Result 和 Detail 5. 重点看 Desired Access、ShareMode、Disposition 6. 对关键失败事件查看 Stack 7. Jump To 文件夹验证 NTFS 权限和占用状态如果 Result 是 SHARING VIOLATION重点不是“权限不足”而是共享模式冲突。要找先占用者。6.2 启动慢或登录卡顿启动慢和登录卡顿要先确认时间窗口再看最活跃的进程、路径和注册表键。1. 打开 Process Activity Summary 2. 找启动窗口内 Top 进程 3. 打开 File Summary 看热路径 4. 打开 Registry Summary 看热键值 5. Count Occurrences 统计 Result 6. 高亮 Duration 100ms 的事件 7. 对关键慢事件查看 Stack启动慢不是只看失败事件。很多启动慢是大量成功但高耗时的文件和注册表访问叠加出来的。6.3 应用偶发假死应用假死通常需要先用长时间轮转锁定异常时间窗然后在异常段 PML 里分析。1. 打开卡顿时间窗对应 PML 2. Process Activity Summary 找最忙进程 3. Count Occurrences 看错误码分布 4. File Summary 看是否疯狂写日志或锁争用 5. 按 Duration 排序找慢调用 6. 对慢事件或失败事件看 Stack 7. 禁用插件 / 安全组件 / 同步组件复测偶发假死最怕没有时间点。让用户记录卡顿发生时间是长时间追踪成功的前提。7. 最小工作流3 到 5 分钟压缩嫌疑面如果你面对一份陌生 PML不知道从哪里看可以直接照下面的最小工作流走。它适合大多数常规分析场景。打开 PMLProcess Activity Summary锁定 Top 1-3 进程回主表 Include 进程Count Occurrences 统计 Result / OperationFile / Registry Summary 找关键路径按 Duration / Result 下钻查看 Detail 与 Stack输出证据结论和处理建议这套流程的好处是不会一开始就陷入细节。你先看谁最忙再看失败和慢调用分布再看具体路径最后才看 Stack。顺序对了分析速度会明显提升。Procmon 分析要像漏斗先宽后窄先统计后细节先证据后结论。7.1 推荐证据四元组输出结论时不建议写成“怀疑某软件导致卡顿”。这种话太松。建议至少写成四元组进程 操作对象 异常结果/耗时 触发模块示例OUTLOOK.EXE 在启动阶段反复访问 HKCU\Software\Microsoft\Office\Outlook\Addins 出现多次 NAME NOT FOUND Stack 中可见第三方加载项模块参与调用。 建议核对加载项注册表项和 DLL 安装路径。能写成四元组说明你的结论已经从“感觉”进入“证据”。8. 证据导出与截图留痕分析工具得出的线索最终要能交给同事、领导、厂商或后续的自己复盘。因此导出证据很重要。不要只口头说“我看到了”。要保存过滤后的 PML、导出 CSV、保留关键 Summary 截图和 Stack 截图。8.1 建议保存哪些内容证据类型用途原始 PML保真留底后续可重新分析过滤后 PML便于同事快速复盘CSV做统计、汇报、Excel 分析Process Summary 截图说明哪个进程最忙File / Registry Summary 截图说明哪个路径或键最异常Count Occurrences 结果说明错误码分布Stack 截图说明触发模块或驱动README说明复现步骤、时间窗口、模板配置证据包的目标是让别人不用重新从海量日志里猜你的思路。8.2 建议命名方式Case-OutlookAddin-PC001-20260519-All.pml Case-OutlookAddin-PC001-20260519-Filtered.pml Case-OutlookAddin-PC001-20260519-ResultCount.csv Case-OutlookAddin-PC001-20260519-README.md命名里至少要包含场景、机器、时间和是否过滤。否则日志堆多以后很难知道哪个文件对应哪个问题。不要只发一张截图就说“已定位”。截图是证明材料不是完整证据链。9. 常见误区与风险提醒Procmon 分析工具虽然好用但误用也很常见。下面这些坑建议提前避开。误区风险正确做法不设过滤直接看 SummaryTopN 被系统噪声淹没先按目标进程或时间窗口过滤只看最后一个报错可能看到的是结果不是原因回到时间线找第一个异常点把 NAME NOT FOUND 都当故障误判正常探测行为看频率、上下文和是否影响流程忽略 Duration漏掉成功但很慢的事件性能问题必须看耗时没开 Stack 却想溯源模块事后无法还原完整调用链采集前决定是否开 Stack不配符号就下结论模块来源看不清先配置符号再判断只导出 CSV 删除 PML丢失深度复盘能力PML 必须保留开 Drop 后做取证过滤外事件不可恢复取证场景慎用 Drop最危险的不是看不懂日志而是看懂了一小部分就过早下结论。9.1 Summary 只统计当前视图这一点必须单独强调。Summary 和 Count 通常基于当前视图所包含的事件。如果你已经过滤掉了某些进程或路径Summary 看到的就不是全量系统活动而是过滤后的结果。看 Summary 前先问自己我现在看的到底是全量日志还是过滤后的视图9.2 Stack 会增加体积和开销Stack 非常有用但不适合所有长时间采集默认开启。更推荐的方式是第一轮不开 Stack先用 Summary 和 Duration 锁定嫌疑对象第二轮对嫌疑对象短时间开 Stack 复抓。先低成本缩范围再高成本追来源。10. 如何写进工单和复盘Procmon 分析完成后工单里不要只写“已通过 Procmon 分析”。这句话没有信息量。高质量工单要写清楚使用了哪个分析工具、看到了什么分布、锁定了哪个对象、下一步怎么验证。可以按下面模板写【问题现象】 用户反馈 xxx 应用启动慢 / 保存失败 / 偶发假死。 【采集方式】 使用 Procmon 采集问题复现窗口日志保存为 PML。 分析时使用 Process Activity Summary、File Summary、Count Occurrences 和 Stack。 【关键发现】 Process Activity Summary 显示 [进程名] 在异常时间窗内事件量最高。 File Summary 显示 [路径] 读写次数 / 写入字节 / 失败次数异常。 Count Occurrences 显示主要 Result 为 [ACCESS DENIED / NAME NOT FOUND / SHARING VIOLATION]。 关键事件 Stack 中可见 [模块名 / DLL / 驱动名] 参与调用。 【初步判断】 当前证据指向 [权限问题 / 文件占用 / 插件冲突 / 第三方安全组件 / 网络等待 / 配置缺失]。 【处理建议】 建议执行 [修复 ACL / 关闭占用进程 / 禁用加载项 / 加入白名单 / 对比正常机器 / 短时间开栈复抓]。 【验证结果】 处理后重新复现异常 Result 消失 / Duration 降低 / 目标路径访问恢复正常。工单结论要从“我感觉”变成“Summary 显示、Count 显示、Stack 显示”。如果证据不足不要硬写根因。可以写成当前 PML 显示某进程在异常窗口内对某路径存在高频访问和高耗时行为需通过禁用测试、正常机器对比或开 Stack 复抓进一步验证。相关性不是因果。Procmon 能帮你缩小嫌疑面但根因仍需要验证。11. 总结抓得多不如看得准Procmon 的分析工具是把日志噪声变成证据链的关键环节。只会抓日志还不够真正有价值的是能在几十万条事件中迅速找出 TopN 进程、热点路径、异常 Result、慢调用和触发模块。本篇最重要的结论可以压缩成三句话第一Summary 用来找全局热点不要一开始就逐行翻日志第二Count Occurrences 用来看错误码和操作分布避免被个别事件误导第三Stack 负责把现象追到模块但必须提前采集并配置符号。从 Mark 式排障视角看Procmon 分析工具的价值不是“多一个菜单功能”而是让你把 seemingly unexplained 的问题压缩到几个可验证对象上。后续遇到 Outlook、Explorer、Teams、OneDrive、EDR、飞连、安装失败、启动慢、偶发假死等问题时可以把本文的最小工作流作为固定动作打开 PML先看 Process Activity Summary再 Count Result再看 File/Registry Summary最后对关键事件看 Detail 和 Stack。这样你得到的不是一堆日志而是一条能写进工单、SOP 和博客复盘的证据链。返回顶部
《Windows Sysinternals实战指南》5.10 Process Monitor 学习笔记：分析工具——从海量事件到可下手的证据
个人主页杨利杰YJlio❄️个人专栏《Sysinternals实战教程》 《Windows PowerShell 实战》 《WINDOWS教程》 《IOS教程》《微信助手》 《锤子助手》 《Python》 《Kali Linux》《那些年未解决的Windows疑难杂症》让复杂的事情更简单让重复的工作自动化《Windows Sysinternals实战指南》5.10 Process Monitor 学习笔记分析工具——从海量事件到可下手的证据1. 为什么要学 Procmon 的分析工具2. 分析工具的基本思路先看全局再下钻再溯源3. 五大汇总面板先用 TopN 找嫌疑对象3.1 Process Activity Summary先看哪个进程最忙3.2 File Summary看最热文件和路径3.3 Registry Summary看配置访问和注册表热点3.4 Network Summary看连接对象和失败分布3.5 Count Occurrences看错误码和操作分布4. 从 TopN 下钻把汇总结果带回主表4.1 推荐列视图4.2 Result 不是唯一判断标准4.3 Jump To从日志直接跳到资源位置5. Stack 调用栈从现象追到触发模块5.1 打开 Stack 的方式5.2 配置符号服务器5.3 Stack 应该看什么6. 三个高命中率排障配方6.1 无法保存或权限不足6.2 启动慢或登录卡顿6.3 应用偶发假死7. 最小工作流3 到 5 分钟压缩嫌疑面7.1 推荐证据四元组8. 证据导出与截图留痕8.1 建议保存哪些内容8.2 建议命名方式9. 常见误区与风险提醒9.1 Summary 只统计当前视图9.2 Stack 会增加体积和开销10. 如何写进工单和复盘11. 总结抓得多不如看得准1. 为什么要学 Procmon 的分析工具前面几篇已经讲过 Process Monitor 的事件模型、过滤器、高亮、Process Tree、PML 保存、Boot Logging、长时间追踪、配置模板和命令行自动化。到这里一个现实问题就出来了日志已经抓到了可是几十万条事件摆在眼前应该从哪里开始看很多人用 Procmon 卡在这一步。不是不会抓而是抓完以后只会按关键词搜索或者从第一行开始慢慢翻。这样做效率很低也容易被最后一个报错误导。真正高效的做法是先用 Procmon 内置的 Summary、Count、Stack 等分析工具把海量事件压缩成几个可下手的嫌疑点。我的理解是过滤器解决“少抓噪声”分析工具解决“从已抓日志里提炼证据”。两者不是替代关系而是前后配合。在企业桌面支持场景里这个能力非常实用。比如 Outlook 启动慢、Explorer 登录后卡顿、OneDrive 同步异常、Teams 加载慢、EDR 或 DLP 疑似拖慢系统这些问题抓到 PML 以后如果直接逐行翻日志很快就会失去方向。你需要先知道哪个进程最忙、哪个路径最热、哪个注册表键最可疑、哪个 Result 最集中再决定是否下钻到 Detail 和 Stack。这张图对应本文核心Procmon 分析工具的目标是把“海量事件”压缩成“可行动证据”。2. 分析工具的基本思路先看全局再下钻再溯源Procmon 的分析顺序不建议一上来就看 Stack也不建议一上来就找某个具体路径。更稳的顺序是三步先看全局再下钻再溯源。打开 PML查看 Summary 汇总锁定 TopN 进程 / 路径 / 错误码返回主表带过滤下钻查看 Result / Detail / Duration查看 Stack 调用栈形成证据结论第一步是全局视角。用 Process Activity Summary、File Summary、Registry Summary、Network Summary 和 Count Occurrences看谁最忙、谁读写最多、谁失败最多。第二步是下钻视角。双击 Summary 中的某一行回到主表只看某个进程、路径或注册表键相关事件。第三步是溯源视角。对关键失败或慢事件打开 Stack看具体是哪个模块、DLL、驱动或组件触发了操作。不要跳过全局视角直接看单条事件。单条事件可能很吓人但未必重要TopN 统计往往更接近问题主线。这个思路和 Mark 式排障是一致的先固定边界再看证据链最后验证假设。用户说“卡”这只是现象Process Summary 告诉你哪个进程最忙File Summary 告诉你哪个路径最热Count Occurrences 告诉你错误码分布Stack 才负责进一步回答“是谁触发的”。一句话Summary 负责缩小范围Count 负责看分布Stack 负责找来源。3. 五大汇总面板先用 TopN 找嫌疑对象Procmon 的 Tools 菜单下提供了多个 Summary 工具。它们的价值不是展示更多信息而是把分散在主表里的事件按不同维度聚合起来。对于几十万行日志来说Summary 是第一刀。3.1 Process Activity Summary先看哪个进程最忙Process Activity Summary 按进程聚合事件。它可以帮助你判断哪个进程事件量最大、读写最重、注册表操作最多、网络活动最集中。对于启动慢、登录慢、卡顿、高 IO 场景这是很好的第一入口。打开路径 Tools → Process Activity Summary常见操作是按 Operation Count、Read Bytes、Write Bytes、Total Bytes 排序先看 Top 5。双击某个进程后Procmon 会回到主界面并按该进程过滤。如果你不知道从哪里看先看 Process Activity Summary。它能快速告诉你“谁最吵”。3.2 File Summary看最热文件和路径File Summary 按文件路径聚合事件。它适合排查高 IO、文件反复打开、日志疯狂写入、配置文件被频繁读取、保存失败、文件被占用等问题。打开路径 Tools → File Summary建议优先按 Opens、Reads、Writes、Read Bytes、Write Bytes、Failures 排序。对于软件启动慢的问题File Summary 经常能直接暴露反复访问的配置文件、插件目录、缓存目录或网络路径。文件问题不要只看 Result。大量成功访问也可能是性能问题尤其要结合 Duration 和读写次数。3.3 Registry Summary看配置访问和注册表热点Registry Summary 按注册表 Key 聚合事件。它适合排查应用启动慢、配置缺失、加载项异常、策略生效异常、安装失败等问题。打开路径 Tools → Registry Summary比如 Outlook 加载项问题可以重点看 Office Addins、CLSID、HKCU/HKLM Software 分支。安装程序异常时可以看是否大量出现 ACCESS DENIED、NAME NOT FOUND 或 RegSetValue 失败。Registry Summary 很适合找“反复读写的配置点”。它能把主表里零散的注册表事件聚成一条线索。3.4 Network Summary看连接对象和失败分布如果当前 Procmon 版本支持 Network Summary可以用它查看进程连接的远端地址、端口、连接次数和失败情况。它不是抓包工具不能替代 Wireshark但可以回答“谁在连哪里是否失败”。打开路径 Tools → Network Summary在代理、证书验证、域控访问、远程路径、云服务连接异常场景中Network Summary 有一定价值。尤其是启动慢时如果发现某个进程在启动阶段反复连接某个远端地址并超时就应该进一步结合防火墙、代理和 DNS 继续验证。3.5 Count Occurrences看错误码和操作分布Count Occurrences 可以对当前视图里的某一列做分组统计。它最适合用来统计 Result、Operation、Process Name、Path 等字段。打开路径 Tools → Count Occurrences...比如你可以对 Result 做统计看 ACCESS DENIED、NAME NOT FOUND、SHARING VIOLATION、PATH NOT FOUND 谁最多也可以对 Operation 做统计看 CreateFile、RegOpenKey、RegSetValue、TCP Connect 哪类操作最集中。Count Occurrences 统计的是当前视图不是永远统计全量日志。先确认当前过滤范围再看统计结果。4. 从 TopN 下钻把汇总结果带回主表Summary 的作用不是停留在排行榜而是帮助你回到主表继续分析。看到 TopN 以后下一步要做的是下钻对某个进程、路径、注册表键或错误码建立过滤只看相关事件。很多 Summary 视图支持双击条目或右键筛选回到主表后只显示对应对象的事件。此时再结合 Result、Detail、Duration 和时间线才能判断它到底是不是关键问题。4.1 推荐列视图下钻分析时建议使用下面这组列Time of Day Process Name PID Operation Path Result Detail Duration这组列基本覆盖了“什么时候、谁、做了什么、对哪个对象、结果如何、细节是什么、耗时多久”。如果要看用户上下文可以再加 User、Session、Integrity。Procmon 主表不是所有列都越多越好。列太多反而影响阅读关键是能支撑证据链。4.2 Result 不是唯一判断标准很多人只看 Result这是不够的。比如 NAME NOT FOUND 在 DLL 搜索和配置探测里很常见未必是错误BUFFER OVERFLOW 多数情况下是长度探测也不一定是故障。性能问题更要看 Duration 和重复次数。字段重点看什么Result是否失败失败类型是什么DetailDesired Access、ShareMode、Disposition、Length、OptionsDuration是否明显高于同类事件Time of Day是否和用户反馈时间一致Path是否指向业务路径、配置路径、网络路径Process Name是否为目标进程或第三方组件单条 ACCESS DENIED 不一定是根因连续、高频、与故障时间重合的 ACCESS DENIED 才值得重点看。4.3 Jump To从日志直接跳到资源位置下钻到具体文件或注册表键后可以使用右键 Jump To。文件事件可以跳转到资源管理器位置注册表事件可以跳转到 Regedit 对应 Key。这个动作适合现场快速验证权限、路径是否存在、配置是否被写入。Jump To 的价值是把“日志线索”快速连接到“系统对象”。排障不是只看日志最终要回到对象本身。5. Stack 调用栈从现象追到触发模块Summary 和 Count 能告诉你哪里可疑但它们通常不能直接告诉你“是谁触发的”。要回答这个问题就需要 Stack。Stack 调用栈能把一个文件、注册表或网络操作还原到调用路径上帮助识别第三方 DLL、插件、驱动或安全组件。5.1 打开 Stack 的方式在主表中选中关键事件右键选择 Stack或者打开事件属性后查看 Stack 标签。如果采集时没有开启调用栈可能看不到完整栈信息。因此是否需要 Stack 要在采集前决定。主表事件 → 右键 → Stack...Stack 不是事后凭空生成的。如果采集时没有记录后续无法完整还原。5.2 配置符号服务器没有符号时Stack 里可能只有地址或不清晰的模块名。配置符号服务器后系统模块和部分调用路径会更容易读懂。Options → Configure Symbols常用符号路径如下srv*C:\Symbols*https://msdl.microsoft.com/download/symbols第一次解析会比较慢因为需要下载符号文件。后续命中本地缓存速度会明显提升。符号路径不是装饰项。要做调用栈溯源符号配置非常关键。5.3 Stack 应该看什么看 Stack 时不要被系统模块吓住。很多栈都会出现 ntdll、kernelbase、ntoskrnl 等系统模块这并不一定说明系统有问题。更关键的是在栈中识别非系统模块、第三方 DLL、插件、过滤驱动、安全软件组件。栈位置观察重点用户态栈顶哪个 DLL 或模块发起调用用户态中间层是否有插件、加载项、业务组件内核态路径是否有过滤驱动、安全驱动、加密驱动重复出现的模块是否每次失败都出现同一模块异常 Result 关联栈是否与 ACCESS DENIED / SHARING VIOLATION 同时出现Stack 的核心不是看懂每一帧而是找出“非系统、反复出现、与异常同步”的模块。6. 三个高命中率排障配方下面这三套配方适合直接放到团队 SOP 里。它们不是万能答案但能覆盖大量桌面支持场景。6.1 无法保存或权限不足现象通常是文件无法保存、提示权限不足、保存后内容丢失、临时文件无法重命名等。建议按下面顺序处理1. 打开 File Summary 2. 按 Write Failures / Write Bytes / Opens 排序 3. 回主表 Include 目标路径 4. 查看 Result 和 Detail 5. 重点看 Desired Access、ShareMode、Disposition 6. 对关键失败事件查看 Stack 7. Jump To 文件夹验证 NTFS 权限和占用状态如果 Result 是 SHARING VIOLATION重点不是“权限不足”而是共享模式冲突。要找先占用者。6.2 启动慢或登录卡顿启动慢和登录卡顿要先确认时间窗口再看最活跃的进程、路径和注册表键。1. 打开 Process Activity Summary 2. 找启动窗口内 Top 进程 3. 打开 File Summary 看热路径 4. 打开 Registry Summary 看热键值 5. Count Occurrences 统计 Result 6. 高亮 Duration 100ms 的事件 7. 对关键慢事件查看 Stack启动慢不是只看失败事件。很多启动慢是大量成功但高耗时的文件和注册表访问叠加出来的。6.3 应用偶发假死应用假死通常需要先用长时间轮转锁定异常时间窗然后在异常段 PML 里分析。1. 打开卡顿时间窗对应 PML 2. Process Activity Summary 找最忙进程 3. Count Occurrences 看错误码分布 4. File Summary 看是否疯狂写日志或锁争用 5. 按 Duration 排序找慢调用 6. 对慢事件或失败事件看 Stack 7. 禁用插件 / 安全组件 / 同步组件复测偶发假死最怕没有时间点。让用户记录卡顿发生时间是长时间追踪成功的前提。7. 最小工作流3 到 5 分钟压缩嫌疑面如果你面对一份陌生 PML不知道从哪里看可以直接照下面的最小工作流走。它适合大多数常规分析场景。打开 PMLProcess Activity Summary锁定 Top 1-3 进程回主表 Include 进程Count Occurrences 统计 Result / OperationFile / Registry Summary 找关键路径按 Duration / Result 下钻查看 Detail 与 Stack输出证据结论和处理建议这套流程的好处是不会一开始就陷入细节。你先看谁最忙再看失败和慢调用分布再看具体路径最后才看 Stack。顺序对了分析速度会明显提升。Procmon 分析要像漏斗先宽后窄先统计后细节先证据后结论。7.1 推荐证据四元组输出结论时不建议写成“怀疑某软件导致卡顿”。这种话太松。建议至少写成四元组进程 操作对象 异常结果/耗时 触发模块示例OUTLOOK.EXE 在启动阶段反复访问 HKCU\Software\Microsoft\Office\Outlook\Addins 出现多次 NAME NOT FOUND Stack 中可见第三方加载项模块参与调用。 建议核对加载项注册表项和 DLL 安装路径。能写成四元组说明你的结论已经从“感觉”进入“证据”。8. 证据导出与截图留痕分析工具得出的线索最终要能交给同事、领导、厂商或后续的自己复盘。因此导出证据很重要。不要只口头说“我看到了”。要保存过滤后的 PML、导出 CSV、保留关键 Summary 截图和 Stack 截图。8.1 建议保存哪些内容证据类型用途原始 PML保真留底后续可重新分析过滤后 PML便于同事快速复盘CSV做统计、汇报、Excel 分析Process Summary 截图说明哪个进程最忙File / Registry Summary 截图说明哪个路径或键最异常Count Occurrences 结果说明错误码分布Stack 截图说明触发模块或驱动README说明复现步骤、时间窗口、模板配置证据包的目标是让别人不用重新从海量日志里猜你的思路。8.2 建议命名方式Case-OutlookAddin-PC001-20260519-All.pml Case-OutlookAddin-PC001-20260519-Filtered.pml Case-OutlookAddin-PC001-20260519-ResultCount.csv Case-OutlookAddin-PC001-20260519-README.md命名里至少要包含场景、机器、时间和是否过滤。否则日志堆多以后很难知道哪个文件对应哪个问题。不要只发一张截图就说“已定位”。截图是证明材料不是完整证据链。9. 常见误区与风险提醒Procmon 分析工具虽然好用但误用也很常见。下面这些坑建议提前避开。误区风险正确做法不设过滤直接看 SummaryTopN 被系统噪声淹没先按目标进程或时间窗口过滤只看最后一个报错可能看到的是结果不是原因回到时间线找第一个异常点把 NAME NOT FOUND 都当故障误判正常探测行为看频率、上下文和是否影响流程忽略 Duration漏掉成功但很慢的事件性能问题必须看耗时没开 Stack 却想溯源模块事后无法还原完整调用链采集前决定是否开 Stack不配符号就下结论模块来源看不清先配置符号再判断只导出 CSV 删除 PML丢失深度复盘能力PML 必须保留开 Drop 后做取证过滤外事件不可恢复取证场景慎用 Drop最危险的不是看不懂日志而是看懂了一小部分就过早下结论。9.1 Summary 只统计当前视图这一点必须单独强调。Summary 和 Count 通常基于当前视图所包含的事件。如果你已经过滤掉了某些进程或路径Summary 看到的就不是全量系统活动而是过滤后的结果。看 Summary 前先问自己我现在看的到底是全量日志还是过滤后的视图9.2 Stack 会增加体积和开销Stack 非常有用但不适合所有长时间采集默认开启。更推荐的方式是第一轮不开 Stack先用 Summary 和 Duration 锁定嫌疑对象第二轮对嫌疑对象短时间开 Stack 复抓。先低成本缩范围再高成本追来源。10. 如何写进工单和复盘Procmon 分析完成后工单里不要只写“已通过 Procmon 分析”。这句话没有信息量。高质量工单要写清楚使用了哪个分析工具、看到了什么分布、锁定了哪个对象、下一步怎么验证。可以按下面模板写【问题现象】 用户反馈 xxx 应用启动慢 / 保存失败 / 偶发假死。 【采集方式】 使用 Procmon 采集问题复现窗口日志保存为 PML。 分析时使用 Process Activity Summary、File Summary、Count Occurrences 和 Stack。 【关键发现】 Process Activity Summary 显示 [进程名] 在异常时间窗内事件量最高。 File Summary 显示 [路径] 读写次数 / 写入字节 / 失败次数异常。 Count Occurrences 显示主要 Result 为 [ACCESS DENIED / NAME NOT FOUND / SHARING VIOLATION]。 关键事件 Stack 中可见 [模块名 / DLL / 驱动名] 参与调用。 【初步判断】 当前证据指向 [权限问题 / 文件占用 / 插件冲突 / 第三方安全组件 / 网络等待 / 配置缺失]。 【处理建议】 建议执行 [修复 ACL / 关闭占用进程 / 禁用加载项 / 加入白名单 / 对比正常机器 / 短时间开栈复抓]。 【验证结果】 处理后重新复现异常 Result 消失 / Duration 降低 / 目标路径访问恢复正常。工单结论要从“我感觉”变成“Summary 显示、Count 显示、Stack 显示”。如果证据不足不要硬写根因。可以写成当前 PML 显示某进程在异常窗口内对某路径存在高频访问和高耗时行为需通过禁用测试、正常机器对比或开 Stack 复抓进一步验证。相关性不是因果。Procmon 能帮你缩小嫌疑面但根因仍需要验证。11. 总结抓得多不如看得准Procmon 的分析工具是把日志噪声变成证据链的关键环节。只会抓日志还不够真正有价值的是能在几十万条事件中迅速找出 TopN 进程、热点路径、异常 Result、慢调用和触发模块。本篇最重要的结论可以压缩成三句话第一Summary 用来找全局热点不要一开始就逐行翻日志第二Count Occurrences 用来看错误码和操作分布避免被个别事件误导第三Stack 负责把现象追到模块但必须提前采集并配置符号。从 Mark 式排障视角看Procmon 分析工具的价值不是“多一个菜单功能”而是让你把 seemingly unexplained 的问题压缩到几个可验证对象上。后续遇到 Outlook、Explorer、Teams、OneDrive、EDR、飞连、安装失败、启动慢、偶发假死等问题时可以把本文的最小工作流作为固定动作打开 PML先看 Process Activity Summary再 Count Result再看 File/Registry Summary最后对关键事件看 Detail 和 Stack。这样你得到的不是一堆日志而是一条能写进工单、SOP 和博客复盘的证据链。返回顶部
