个人主页杨利杰YJlio❄️个人专栏《Sysinternals实战教程》 《Windows PowerShell 实战》 《WINDOWS教程》 《IOS教程》《微信助手》 《锤子助手》 《Python》 《Kali Linux》《那些年未解决的Windows疑难杂症》让复杂的事情更简单让重复的工作自动化《Windows Sysinternals实战指南》5.9 Process Monitor 学习笔记Procmon 的自动化操作——命令行选项1. 为什么要把 Procmon 做成命令行自动化2. 什么时候应该用命令行而不是 GUI3. 常用命令行开关怎么理解3.1 /AcceptEula别让许可弹窗卡住脚本3.2 /LoadConfig加载团队 PMC 模板3.3 /BackingFile把事件写入 PML3.4 /Terminate安全停止而不是粗暴强杀4. 60 秒无人值守采集最常用的一键脚本4.1 CMD 版本4.2 这个脚本适合哪些问题5. 轮转切片采集长时间追踪也要控体积5.1 PowerShell 轮转示例5.2 为什么要切片5.3 计划任务落地建议6. PML 转 CSV适合统计不适合替代原始日志6.1 导出 CSV 常见失败原因7. 配置模板和命令行要分工清楚7.1 推荐三类模板8. 权限、体积和稳定性风险8.1 权限建议管理员运行8.2 体积Stack 和 Profiling 不要默认全开8.3 并发实例先停再启更稳8.4 日志目录不要放在高风险位置9. 常见问题与排查办法9.1 命令跑了但 PML 很小或为空9.2 EULA 弹窗阻塞无人值守9.3 CSV 导出失败9.4 路径包含空格导致失败9.5 计划任务运行无输出10. 团队落地清单把命令行变成标准工具包10.1 推荐工具包结构10.2 README 必须写清楚10.3 工单中怎么记录11. 总结命令行让 Procmon 从工具变成能力1. 为什么要把 Procmon 做成命令行自动化前面几篇已经讲过 Process Monitor 的事件模型、过滤器、高亮、Process Tree、PML 保存、Boot Logging、长时间追踪以及配置模板。到了这一篇Procmon 就不再只是一个手工点击的 GUI 工具而是可以进入脚本化、计划任务化、无人值守采集的阶段。在真实桌面支持现场很多问题并不会等你慢慢打开 GUI、选择过滤器、设置 Backing File。比如用户说 Outlook 加载项偶发消失企业微信启动偶尔卡 15 秒Explorer 登录后偶尔假死或者某台机器每天只有某个时间段出现高 IO。这类问题最怕“复现窗口短”。手工操作慢半拍现场就没了。命令行自动化的价值就是把这些动作提前固化加载统一配置、静默启动、写入 PML、等待指定时间、自动停止、必要时导出 CSV。这样用户或同事只需要运行一个脚本就能按统一口径完成采集。我的理解是Procmon GUI 适合交互式分析Procmon 命令行适合标准化取证。GUI 是显微镜命令行是自动采样器。这张图对应本文核心命令行自动化把“加载模板、写盘、停止采集、远程协助、定时采集”串成一条标准流程。2. 什么时候应该用命令行而不是 GUI不是所有 Procmon 场景都需要命令行。现场初步分析、手工过滤、看 Stack、看 SummaryGUI 仍然更直观。但只要进入重复采集、远程协助、批量部署、计划任务、长时间轮转就应该优先考虑命令行。场景推荐方式原因临时看一个应用访问了什么文件GUI交互式分析更快用户电脑远程采集 60 秒命令行脚本用户双击即可不需要理解 Procmon值守时自动抓日志命令行 计划任务可定时启动和停止长时间追踪并切片PowerShell /Terminate避免单个 PML 过大团队统一抓取口径/LoadConfig强制加载同一套 PMCPML 批量导出 CSV/OpenLog/SaveAs适合二次统计命令行自动化最适合解决两个问题一是减少人工操作二是保证证据口径一致。尤其是团队协作时如果每个人都用自己的过滤器抓日志那么后续复盘会非常混乱。命令行配合 .pmc 模板可以把过滤、高亮、列视图、时间显示和性能选项提前固化。不要把命令行理解成“更高级的玩法”。它真正解决的是可重复、可交接、可批量执行。对于企业桌面支持来说这一点很实际。你可以提前准备“60 秒无人值守采集脚本”“Outlook 加载项专项采集脚本”“Explorer 登录慢采集脚本”“长时间轮转采集脚本”。遇到问题时不用从零解释 Procmon 怎么点直接发脚本和操作说明即可。3. 常用命令行开关怎么理解Procmon 命令行参数并不多但每个参数都要理解边界。不同版本的 Procmon 可能存在细节差异现场使用时以本机版本帮助信息和实际测试结果为准。这里整理的是桌面支持和团队协作中最常用的一组。开关作用使用建议/AcceptEula首次运行自动接受许可无人值守脚本必须加/Quiet静默启动减少交互适合远程采集和计划任务/Minimized最小化启动避免影响用户操作/LoadConfig pmc加载配置模板团队标准化的核心/BackingFile pml直接写入 PML 文件长跑和无人值守必备/OpenLog pml打开已有 PML离线复盘使用/SaveAs 目标文件导出为 PML / CSV / XML按扩展名决定输出格式/Terminate停止当前 Procmon 实例并退出比强杀进程更安全这几个参数里最核心的是四个/LoadConfig、/BackingFile、/Terminate、/SaveAs。前两个负责采集后两个负责收束和导出。只要理解这四个参数大部分自动化场景就能搭起来。推荐组合/AcceptEula /Quiet /Minimized /LoadConfig /BackingFile。这个组合适合大多数无人值守采集。3.1/AcceptEula别让许可弹窗卡住脚本第一次运行 Procmon 时如果没有接受 EULA可能会弹出许可确认窗口。对于人工 GUI 使用这不是大问题但对于计划任务、远程脚本和无人值守采集这就是阻断点。procmon.exe /AcceptEula无人值守脚本必须加 /AcceptEula。不要假设目标电脑已经手工运行过 Procmon。3.2/LoadConfig加载团队 PMC 模板这个参数决定了采集口径。过滤器、高亮、列视图、是否启用 Drop Filtered Events、是否启用 Call Stacks通常都应该提前放进 .pmc 模板中。procmon.exe /LoadConfig D:\Procmon\Base.pmc命令行脚本不应该写一堆临时判断逻辑而应该只负责加载模板和指定日志路径。这样维护成本最低。3.3/BackingFile把事件写入 PMLBacking File 用于把采集事件写入 PML。长时间追踪、无人值守采集、远程复现都建议使用它。procmon.exe /BackingFile D:\ProcmonLogs\trace.pml日志路径建议放在非系统盘并提前确认磁盘空间。Procmon 采集本身不能成为新的故障源。3.4/Terminate安全停止而不是粗暴强杀/Terminate 的作用是向正在运行的 Procmon 实例发出停止并退出指令。它不是简单地 kill 进程因此更适合用于脚本收尾。procmon.exe /Terminate如果直接强杀 ProcmonPML 可能没有正常收束后续打开和分析可能受影响。自动化脚本里应优先使用 /Terminate。4. 60 秒无人值守采集最常用的一键脚本60 秒无人值守采集是最实用的模板之一。它适合远程让用户双击执行也适合一线同事快速抓取短窗口问题。脚本启动 Procmon加载团队模板写入 PML等待 60 秒后自动停止。4.1 CMD 版本echo off setlocal set PMC:\Tools\Sysinternals\procmon.exe set CFGD:\Procmon\Team-Default.pmc set LOGROOTD:\ProcmonLogs if not exist %LOGROOT% mkdir %LOGROOT% set TS%date:~0,4%-%date:~5,2%-%date:~8,2%_%time:~0,2%%time:~3,2% set TS%TS: 0% set OUT%LOGROOT%\pm_%TS%.pml %PM% /AcceptEula /Quiet /Minimized ^ /LoadConfig %CFG% ^ /BackingFile %OUT% timeout /t 60 /nobreak nul %PM% /Terminate echo. echo Procmon 日志已保存 echo %OUT% echo. pause这个脚本适合做成桌面支持工具包。用户只需要双击运行等待结束后把 PML 文件发回来即可。实际使用前要确认 Procmon 路径、PMC 路径和日志目录都存在。远程协助场景优先使用这种短采集脚本。它足够简单用户配合成本低。4.2 这个脚本适合哪些问题问题类型是否适合软件启动慢适合双击软件前运行脚本安装程序报错适合执行安装前运行脚本文件保存失败适合复现保存动作Outlook 加载项异常适合启动 Outlook 前运行脚本全天偶发卡顿不适合应该用轮转切片开机登录前问题不适合应该用 Boot Logging60 秒脚本不适合所有问题。窗口短、动作明确的问题适合发生时间不确定的问题要用长时间轮转。5. 轮转切片采集长时间追踪也要控体积如果问题不确定什么时候发生就不能只抓 60 秒。但长时间抓取也不能生成一个无限膨胀的大 PML。更稳的方式是轮转切片比如每 2 分钟、每 30 分钟或每小时生成一段 PML。5.1 PowerShell 轮转示例# Rotate-ProcmonTrace.ps1# 用途连续抓取 5 段每段 2 分钟$pmC:\Tools\Sysinternals\procmon.exe$cfgD:\Procmon\Longrun.pmc$dirD:\ProcmonLogsNew-Item-Force-ItemType Directory$dir|Out-Null1..5|ForEach-Object{$ts(Get-Date).ToString(yyyyMMdd_HHmmss)$pmlJoin-Path$dirpm_$ts.pml$pm/AcceptEula/Quiet/Minimized/LoadConfig$cfg/BackingFile$pmlStart-Sleep-Seconds 120 $pm/TerminateStart-Sleep-Seconds 5}这个脚本只是演示逻辑。真实生产环境建议用计划任务来控制 Start 和 Stop而不是把所有循环都写进一个长脚本。计划任务更适合失败恢复、权限控制和日志记录。5.2 为什么要切片切片的最大价值是把全天日志拆成多个可管理的时间段。用户说 14:20 卡顿你就优先打开 14:0015:00 的 PML而不是打开一个 20GB 的全天日志硬搜。09:00 PML10:00 PML11:00 PML12:00 PML13:00 PML异常时间窗轮转切片的目标不是抓更多而是让异常时间窗更容易被定位。5.3 计划任务落地建议任务触发方式动作Procmon_Start整点后 1 分钟加载 PMC 并写入新 PMLProcmon_Stop每小时整点/Terminate停止当前采集Procmon_Cleanup每天一次压缩或清理旧日志轮转采集前必须试跑。重点检查管理员权限、Procmon 路径、PMC 路径、日志目录和磁盘空间。6. PML 转 CSV适合统计不适合替代原始日志Procmon 的 PML 适合深度复盘CSV 适合 Excel、Power BI 或 Python 统计。两者角色不同。不要只导出 CSV 后就删除 PML。procmon.exe /OpenLog D:\logs\a.pml /SaveAs D:\logs\a.csv这个命令的含义是先打开已有 PML再把当前日志另存为 CSV。CSV 可以用于统计失败码、慢调用、路径访问频率、进程事件数量等。分析目标推荐格式查看 Process TreePML查看 Stack / DetailPML套用过滤模板复盘PMLExcel 透视表统计CSVPower BI 报表CSV失败码 TopNCSV慢调用 TopNCSVPML 是原始证据CSV 是统计视图。CSV 不能替代 PML。6.1 导出 CSV 常见失败原因如果导出 CSV 失败优先检查三个点PML 路径是否存在输出目录是否可写是否先使用了 /OpenLog。不要只写 /SaveAs它需要有当前打开的日志作为输入。procmon.exe /OpenLog D:\logs\case.pml /SaveAs D:\logs\case.csv正确思路是OpenLog 负责输入SaveAs 负责输出。7. 配置模板和命令行要分工清楚Procmon 自动化最容易写乱的地方是把所有逻辑都塞进脚本。更推荐的方式是让 .pmc 模板负责分析口径让命令行负责执行动作。也就是说过滤器、高亮、列视图、时间显示、Capture 类别、是否启用 Drop Filtered Events、是否启用 Call Stacks都应该放在 PMC 里。脚本只管加载哪个模板、写到哪个日志文件、多久停止。PMC 模板过滤 / 高亮 / 列视图 / 性能选项命令行脚本加载模板 / 写入 PML / 定时停止统一采集口径可复盘的证据链PMC 管“怎么抓”脚本管“什么时候抓、抓到哪里、什么时候停”。这个边界要清楚。7.1 推荐三类模板模板用途建议设置Base.pmc常规短时分析不 Drop不开 Profiling基础高亮Longrun.pmc长时间追踪强过滤关闭 Stack按需 DropDeepStack.pmc深度溯源开启 Stack只短时间使用不要用 DeepStack 模板跑全天采集也不要用 Longrun 模板做首次未知故障分析。模板选错日志不是太大就是证据不完整。模板不是越强越好而是要和问题阶段匹配。8. 权限、体积和稳定性风险Procmon 自动化看起来只是脚本问题实际涉及权限、驱动加载、日志体积、并发实例和安全软件扫描。现场不能只验证命令能不能运行还要验证它会不会稳定地产出可用 PML。8.1 权限建议管理员运行普通账户也能看到一部分事件但需要加载驱动、捕获更完整系统活动、做 Boot Logging 或涉及系统级细节时建议以管理员权限运行。远程发给用户执行的脚本也要说明需要右键管理员运行。权限不足时脚本可能看似运行了但抓到的证据不完整。这比直接失败更危险。8.2 体积Stack 和 Profiling 不要默认全开Capture Call Stacks 和 Profiling 对定位根因有帮助但会明显增加日志体积和开销。自动化采集尤其要克制。更稳的策略是先用 Base 或 Longrun 找到异常时间窗再用 DeepStack 短时间复抓。先低成本长跑锁定对象再高成本短抓确认调用链。8.3 并发实例先停再启更稳Procmon 多实例之间会有交互。轮转脚本里建议先 /Terminate 当前实例等待几秒再启动下一段采集。不要在旧实例还没收束时立即启动新实例。$pm/TerminateStart-Sleep-Seconds 5 $pm/AcceptEula/Quiet/Minimized/LoadConfig$cfg/BackingFile$pml8.4 日志目录不要放在高风险位置日志目录建议放在非系统盘并避免与数据库、虚拟机、编译缓存等高 IO 业务共盘。企业环境中如果安全软件持续扫描 PML也可能带来额外 IO需要按公司流程申请临时排除。自动化采集不是只写脚本还要把日志路径、权限和安全策略一起设计好。9. 常见问题与排查办法下面这些问题都是 Procmon 命令行自动化中经常遇到的。建议直接放进团队 README避免每次重复解释。9.1 命令跑了但 PML 很小或为空常见原因是模板过滤太严格、启用了 Drop Filtered Events、目标进程没有在采集窗口内产生事件或者采集时间太短。处理建议 1. 延长采集时间 2. 临时关闭 Drop Filtered Events 3. 放宽 Process Name / Path 过滤 4. 确认目标动作真的发生 5. 先用 GUI 短时验证模板是否有效PML 为空不一定是没问题也可能是你把证据过滤掉了。9.2 EULA 弹窗阻塞无人值守脚本里加 /AcceptEula。如果是计划任务还要确认运行账户是否第一次执行 Procmon。不同账户下的首次运行状态可能不同。9.3 CSV 导出失败确认命令格式是否是 /OpenLog /SaveAs同时确认输出目录可写。procmon.exe /OpenLog D:\logs\a.pml /SaveAs D:\logs\a.csv9.4 路径包含空格导致失败路径统一加双引号。尤其是 Program Files、用户目录、共享路径不能省略引号。C:\Tools\Sysinternals\procmon.exe /LoadConfig D:\Procmon\Config\Base.pmc9.5 计划任务运行无输出优先检查运行账户、最高权限、工作目录、脚本执行策略和日志目录权限。PowerShell 脚本建议在任务计划程序中明确指定 powershell.exe 和脚本路径。Program: powershell.exe Arguments: -ExecutionPolicy Bypass -File D:\Procmon\Start-ProcmonTrace.ps1计划任务排错时不要只看任务是否触发要看 PML 是否真的生成、是否能打开、是否包含目标事件。10. 团队落地清单把命令行变成标准工具包Procmon 命令行自动化最终应该沉淀成团队工具包而不是散落在个人电脑里的几个脚本。建议至少准备三类 PMC 模板和两个脚本。10.1 推荐工具包结构Procmon-AutoKit ├─ Config │ ├─ Base.pmc │ ├─ Longrun.pmc │ └─ DeepStack.pmc ├─ Scripts │ ├─ Collect-60s.cmd │ ├─ Rotate-ProcmonTrace.ps1 │ ├─ Convert-PML-To-CSV.cmd │ └─ Stop-Procmon.cmd ├─ Logs │ └─ README.md └─ README.md10.2 README 必须写清楚工具用途 适用场景 Procmon 路径 配置模板说明 是否启用 Drop Filtered Events 是否启用 Capture Call Stacks 日志保存位置 采集时长 如何停止 如何打包发给二线没有 README 的脚本工具包很快会变成新的维护负担。10.3 工单中怎么记录使用命令行自动化采集后工单里不要只写“已抓 Procmon”。应该写清楚脚本、模板、时间窗口和关键证据。【采集方式】 使用 Procmon 命令行自动化脚本 Collect-60s.cmd 进行无人值守采集。 【配置模板】 加载 Base.pmc未开启 Drop Filtered Events未开启 Profiling。 【采集时间】 2026-05-19 14:30 至 14:31。 【日志文件】 pm_20260519_143000.pml。 【关键证据】 目标进程 OUTLOOK.EXE 在启动阶段访问 Addins 注册表路径 出现多次 NAME NOT FOUND并伴随加载项 DLL 查询失败。 【后续动作】 建议对比正常机器 Addins 注册表项并检查加载项安装路径和策略状态。高质量工单要让别人知道你用什么模板抓的、抓了哪段、看到了什么、下一步查哪里。11. 总结命令行让 Procmon 从工具变成能力Procmon 的命令行能力本质上是把一次次手工操作固化成标准动作。它不是为了替代 GUI而是为了让采集过程可重复、可远程、可定时、可批量、可交接。本篇最重要的结论可以压缩成三句话第一/LoadConfig 负责统一模板口径第二/BackingFile 负责把现场写入 PML第三/Terminate 和 /SaveAs 负责安全收束与离线转换。从 Mark 式排障视角看自动化不是炫技而是减少人为变量让证据采集过程更稳定。后续处理 Outlook、Explorer、Teams、OneDrive、EDR、飞连、安装失败、启动慢、偶发卡顿等问题时建议把 Procmon 命令行脚本作为桌面支持工具包的一部分。先用 Base 模板做短时采集再用 Longrun 做轮转追踪最后用 DeepStack 做短时间深挖。这样 Procmon 才真正从“临时打开的工具”变成团队可以复用的排障能力。返回顶部
《Windows Sysinternals实战指南》5.9 Process Monitor 学习笔记:Procmon 的自动化操作——命令行选项
发布时间:2026/5/20 4:35:48
个人主页杨利杰YJlio❄️个人专栏《Sysinternals实战教程》 《Windows PowerShell 实战》 《WINDOWS教程》 《IOS教程》《微信助手》 《锤子助手》 《Python》 《Kali Linux》《那些年未解决的Windows疑难杂症》让复杂的事情更简单让重复的工作自动化《Windows Sysinternals实战指南》5.9 Process Monitor 学习笔记Procmon 的自动化操作——命令行选项1. 为什么要把 Procmon 做成命令行自动化2. 什么时候应该用命令行而不是 GUI3. 常用命令行开关怎么理解3.1 /AcceptEula别让许可弹窗卡住脚本3.2 /LoadConfig加载团队 PMC 模板3.3 /BackingFile把事件写入 PML3.4 /Terminate安全停止而不是粗暴强杀4. 60 秒无人值守采集最常用的一键脚本4.1 CMD 版本4.2 这个脚本适合哪些问题5. 轮转切片采集长时间追踪也要控体积5.1 PowerShell 轮转示例5.2 为什么要切片5.3 计划任务落地建议6. PML 转 CSV适合统计不适合替代原始日志6.1 导出 CSV 常见失败原因7. 配置模板和命令行要分工清楚7.1 推荐三类模板8. 权限、体积和稳定性风险8.1 权限建议管理员运行8.2 体积Stack 和 Profiling 不要默认全开8.3 并发实例先停再启更稳8.4 日志目录不要放在高风险位置9. 常见问题与排查办法9.1 命令跑了但 PML 很小或为空9.2 EULA 弹窗阻塞无人值守9.3 CSV 导出失败9.4 路径包含空格导致失败9.5 计划任务运行无输出10. 团队落地清单把命令行变成标准工具包10.1 推荐工具包结构10.2 README 必须写清楚10.3 工单中怎么记录11. 总结命令行让 Procmon 从工具变成能力1. 为什么要把 Procmon 做成命令行自动化前面几篇已经讲过 Process Monitor 的事件模型、过滤器、高亮、Process Tree、PML 保存、Boot Logging、长时间追踪以及配置模板。到了这一篇Procmon 就不再只是一个手工点击的 GUI 工具而是可以进入脚本化、计划任务化、无人值守采集的阶段。在真实桌面支持现场很多问题并不会等你慢慢打开 GUI、选择过滤器、设置 Backing File。比如用户说 Outlook 加载项偶发消失企业微信启动偶尔卡 15 秒Explorer 登录后偶尔假死或者某台机器每天只有某个时间段出现高 IO。这类问题最怕“复现窗口短”。手工操作慢半拍现场就没了。命令行自动化的价值就是把这些动作提前固化加载统一配置、静默启动、写入 PML、等待指定时间、自动停止、必要时导出 CSV。这样用户或同事只需要运行一个脚本就能按统一口径完成采集。我的理解是Procmon GUI 适合交互式分析Procmon 命令行适合标准化取证。GUI 是显微镜命令行是自动采样器。这张图对应本文核心命令行自动化把“加载模板、写盘、停止采集、远程协助、定时采集”串成一条标准流程。2. 什么时候应该用命令行而不是 GUI不是所有 Procmon 场景都需要命令行。现场初步分析、手工过滤、看 Stack、看 SummaryGUI 仍然更直观。但只要进入重复采集、远程协助、批量部署、计划任务、长时间轮转就应该优先考虑命令行。场景推荐方式原因临时看一个应用访问了什么文件GUI交互式分析更快用户电脑远程采集 60 秒命令行脚本用户双击即可不需要理解 Procmon值守时自动抓日志命令行 计划任务可定时启动和停止长时间追踪并切片PowerShell /Terminate避免单个 PML 过大团队统一抓取口径/LoadConfig强制加载同一套 PMCPML 批量导出 CSV/OpenLog/SaveAs适合二次统计命令行自动化最适合解决两个问题一是减少人工操作二是保证证据口径一致。尤其是团队协作时如果每个人都用自己的过滤器抓日志那么后续复盘会非常混乱。命令行配合 .pmc 模板可以把过滤、高亮、列视图、时间显示和性能选项提前固化。不要把命令行理解成“更高级的玩法”。它真正解决的是可重复、可交接、可批量执行。对于企业桌面支持来说这一点很实际。你可以提前准备“60 秒无人值守采集脚本”“Outlook 加载项专项采集脚本”“Explorer 登录慢采集脚本”“长时间轮转采集脚本”。遇到问题时不用从零解释 Procmon 怎么点直接发脚本和操作说明即可。3. 常用命令行开关怎么理解Procmon 命令行参数并不多但每个参数都要理解边界。不同版本的 Procmon 可能存在细节差异现场使用时以本机版本帮助信息和实际测试结果为准。这里整理的是桌面支持和团队协作中最常用的一组。开关作用使用建议/AcceptEula首次运行自动接受许可无人值守脚本必须加/Quiet静默启动减少交互适合远程采集和计划任务/Minimized最小化启动避免影响用户操作/LoadConfig pmc加载配置模板团队标准化的核心/BackingFile pml直接写入 PML 文件长跑和无人值守必备/OpenLog pml打开已有 PML离线复盘使用/SaveAs 目标文件导出为 PML / CSV / XML按扩展名决定输出格式/Terminate停止当前 Procmon 实例并退出比强杀进程更安全这几个参数里最核心的是四个/LoadConfig、/BackingFile、/Terminate、/SaveAs。前两个负责采集后两个负责收束和导出。只要理解这四个参数大部分自动化场景就能搭起来。推荐组合/AcceptEula /Quiet /Minimized /LoadConfig /BackingFile。这个组合适合大多数无人值守采集。3.1/AcceptEula别让许可弹窗卡住脚本第一次运行 Procmon 时如果没有接受 EULA可能会弹出许可确认窗口。对于人工 GUI 使用这不是大问题但对于计划任务、远程脚本和无人值守采集这就是阻断点。procmon.exe /AcceptEula无人值守脚本必须加 /AcceptEula。不要假设目标电脑已经手工运行过 Procmon。3.2/LoadConfig加载团队 PMC 模板这个参数决定了采集口径。过滤器、高亮、列视图、是否启用 Drop Filtered Events、是否启用 Call Stacks通常都应该提前放进 .pmc 模板中。procmon.exe /LoadConfig D:\Procmon\Base.pmc命令行脚本不应该写一堆临时判断逻辑而应该只负责加载模板和指定日志路径。这样维护成本最低。3.3/BackingFile把事件写入 PMLBacking File 用于把采集事件写入 PML。长时间追踪、无人值守采集、远程复现都建议使用它。procmon.exe /BackingFile D:\ProcmonLogs\trace.pml日志路径建议放在非系统盘并提前确认磁盘空间。Procmon 采集本身不能成为新的故障源。3.4/Terminate安全停止而不是粗暴强杀/Terminate 的作用是向正在运行的 Procmon 实例发出停止并退出指令。它不是简单地 kill 进程因此更适合用于脚本收尾。procmon.exe /Terminate如果直接强杀 ProcmonPML 可能没有正常收束后续打开和分析可能受影响。自动化脚本里应优先使用 /Terminate。4. 60 秒无人值守采集最常用的一键脚本60 秒无人值守采集是最实用的模板之一。它适合远程让用户双击执行也适合一线同事快速抓取短窗口问题。脚本启动 Procmon加载团队模板写入 PML等待 60 秒后自动停止。4.1 CMD 版本echo off setlocal set PMC:\Tools\Sysinternals\procmon.exe set CFGD:\Procmon\Team-Default.pmc set LOGROOTD:\ProcmonLogs if not exist %LOGROOT% mkdir %LOGROOT% set TS%date:~0,4%-%date:~5,2%-%date:~8,2%_%time:~0,2%%time:~3,2% set TS%TS: 0% set OUT%LOGROOT%\pm_%TS%.pml %PM% /AcceptEula /Quiet /Minimized ^ /LoadConfig %CFG% ^ /BackingFile %OUT% timeout /t 60 /nobreak nul %PM% /Terminate echo. echo Procmon 日志已保存 echo %OUT% echo. pause这个脚本适合做成桌面支持工具包。用户只需要双击运行等待结束后把 PML 文件发回来即可。实际使用前要确认 Procmon 路径、PMC 路径和日志目录都存在。远程协助场景优先使用这种短采集脚本。它足够简单用户配合成本低。4.2 这个脚本适合哪些问题问题类型是否适合软件启动慢适合双击软件前运行脚本安装程序报错适合执行安装前运行脚本文件保存失败适合复现保存动作Outlook 加载项异常适合启动 Outlook 前运行脚本全天偶发卡顿不适合应该用轮转切片开机登录前问题不适合应该用 Boot Logging60 秒脚本不适合所有问题。窗口短、动作明确的问题适合发生时间不确定的问题要用长时间轮转。5. 轮转切片采集长时间追踪也要控体积如果问题不确定什么时候发生就不能只抓 60 秒。但长时间抓取也不能生成一个无限膨胀的大 PML。更稳的方式是轮转切片比如每 2 分钟、每 30 分钟或每小时生成一段 PML。5.1 PowerShell 轮转示例# Rotate-ProcmonTrace.ps1# 用途连续抓取 5 段每段 2 分钟$pmC:\Tools\Sysinternals\procmon.exe$cfgD:\Procmon\Longrun.pmc$dirD:\ProcmonLogsNew-Item-Force-ItemType Directory$dir|Out-Null1..5|ForEach-Object{$ts(Get-Date).ToString(yyyyMMdd_HHmmss)$pmlJoin-Path$dirpm_$ts.pml$pm/AcceptEula/Quiet/Minimized/LoadConfig$cfg/BackingFile$pmlStart-Sleep-Seconds 120 $pm/TerminateStart-Sleep-Seconds 5}这个脚本只是演示逻辑。真实生产环境建议用计划任务来控制 Start 和 Stop而不是把所有循环都写进一个长脚本。计划任务更适合失败恢复、权限控制和日志记录。5.2 为什么要切片切片的最大价值是把全天日志拆成多个可管理的时间段。用户说 14:20 卡顿你就优先打开 14:0015:00 的 PML而不是打开一个 20GB 的全天日志硬搜。09:00 PML10:00 PML11:00 PML12:00 PML13:00 PML异常时间窗轮转切片的目标不是抓更多而是让异常时间窗更容易被定位。5.3 计划任务落地建议任务触发方式动作Procmon_Start整点后 1 分钟加载 PMC 并写入新 PMLProcmon_Stop每小时整点/Terminate停止当前采集Procmon_Cleanup每天一次压缩或清理旧日志轮转采集前必须试跑。重点检查管理员权限、Procmon 路径、PMC 路径、日志目录和磁盘空间。6. PML 转 CSV适合统计不适合替代原始日志Procmon 的 PML 适合深度复盘CSV 适合 Excel、Power BI 或 Python 统计。两者角色不同。不要只导出 CSV 后就删除 PML。procmon.exe /OpenLog D:\logs\a.pml /SaveAs D:\logs\a.csv这个命令的含义是先打开已有 PML再把当前日志另存为 CSV。CSV 可以用于统计失败码、慢调用、路径访问频率、进程事件数量等。分析目标推荐格式查看 Process TreePML查看 Stack / DetailPML套用过滤模板复盘PMLExcel 透视表统计CSVPower BI 报表CSV失败码 TopNCSV慢调用 TopNCSVPML 是原始证据CSV 是统计视图。CSV 不能替代 PML。6.1 导出 CSV 常见失败原因如果导出 CSV 失败优先检查三个点PML 路径是否存在输出目录是否可写是否先使用了 /OpenLog。不要只写 /SaveAs它需要有当前打开的日志作为输入。procmon.exe /OpenLog D:\logs\case.pml /SaveAs D:\logs\case.csv正确思路是OpenLog 负责输入SaveAs 负责输出。7. 配置模板和命令行要分工清楚Procmon 自动化最容易写乱的地方是把所有逻辑都塞进脚本。更推荐的方式是让 .pmc 模板负责分析口径让命令行负责执行动作。也就是说过滤器、高亮、列视图、时间显示、Capture 类别、是否启用 Drop Filtered Events、是否启用 Call Stacks都应该放在 PMC 里。脚本只管加载哪个模板、写到哪个日志文件、多久停止。PMC 模板过滤 / 高亮 / 列视图 / 性能选项命令行脚本加载模板 / 写入 PML / 定时停止统一采集口径可复盘的证据链PMC 管“怎么抓”脚本管“什么时候抓、抓到哪里、什么时候停”。这个边界要清楚。7.1 推荐三类模板模板用途建议设置Base.pmc常规短时分析不 Drop不开 Profiling基础高亮Longrun.pmc长时间追踪强过滤关闭 Stack按需 DropDeepStack.pmc深度溯源开启 Stack只短时间使用不要用 DeepStack 模板跑全天采集也不要用 Longrun 模板做首次未知故障分析。模板选错日志不是太大就是证据不完整。模板不是越强越好而是要和问题阶段匹配。8. 权限、体积和稳定性风险Procmon 自动化看起来只是脚本问题实际涉及权限、驱动加载、日志体积、并发实例和安全软件扫描。现场不能只验证命令能不能运行还要验证它会不会稳定地产出可用 PML。8.1 权限建议管理员运行普通账户也能看到一部分事件但需要加载驱动、捕获更完整系统活动、做 Boot Logging 或涉及系统级细节时建议以管理员权限运行。远程发给用户执行的脚本也要说明需要右键管理员运行。权限不足时脚本可能看似运行了但抓到的证据不完整。这比直接失败更危险。8.2 体积Stack 和 Profiling 不要默认全开Capture Call Stacks 和 Profiling 对定位根因有帮助但会明显增加日志体积和开销。自动化采集尤其要克制。更稳的策略是先用 Base 或 Longrun 找到异常时间窗再用 DeepStack 短时间复抓。先低成本长跑锁定对象再高成本短抓确认调用链。8.3 并发实例先停再启更稳Procmon 多实例之间会有交互。轮转脚本里建议先 /Terminate 当前实例等待几秒再启动下一段采集。不要在旧实例还没收束时立即启动新实例。$pm/TerminateStart-Sleep-Seconds 5 $pm/AcceptEula/Quiet/Minimized/LoadConfig$cfg/BackingFile$pml8.4 日志目录不要放在高风险位置日志目录建议放在非系统盘并避免与数据库、虚拟机、编译缓存等高 IO 业务共盘。企业环境中如果安全软件持续扫描 PML也可能带来额外 IO需要按公司流程申请临时排除。自动化采集不是只写脚本还要把日志路径、权限和安全策略一起设计好。9. 常见问题与排查办法下面这些问题都是 Procmon 命令行自动化中经常遇到的。建议直接放进团队 README避免每次重复解释。9.1 命令跑了但 PML 很小或为空常见原因是模板过滤太严格、启用了 Drop Filtered Events、目标进程没有在采集窗口内产生事件或者采集时间太短。处理建议 1. 延长采集时间 2. 临时关闭 Drop Filtered Events 3. 放宽 Process Name / Path 过滤 4. 确认目标动作真的发生 5. 先用 GUI 短时验证模板是否有效PML 为空不一定是没问题也可能是你把证据过滤掉了。9.2 EULA 弹窗阻塞无人值守脚本里加 /AcceptEula。如果是计划任务还要确认运行账户是否第一次执行 Procmon。不同账户下的首次运行状态可能不同。9.3 CSV 导出失败确认命令格式是否是 /OpenLog /SaveAs同时确认输出目录可写。procmon.exe /OpenLog D:\logs\a.pml /SaveAs D:\logs\a.csv9.4 路径包含空格导致失败路径统一加双引号。尤其是 Program Files、用户目录、共享路径不能省略引号。C:\Tools\Sysinternals\procmon.exe /LoadConfig D:\Procmon\Config\Base.pmc9.5 计划任务运行无输出优先检查运行账户、最高权限、工作目录、脚本执行策略和日志目录权限。PowerShell 脚本建议在任务计划程序中明确指定 powershell.exe 和脚本路径。Program: powershell.exe Arguments: -ExecutionPolicy Bypass -File D:\Procmon\Start-ProcmonTrace.ps1计划任务排错时不要只看任务是否触发要看 PML 是否真的生成、是否能打开、是否包含目标事件。10. 团队落地清单把命令行变成标准工具包Procmon 命令行自动化最终应该沉淀成团队工具包而不是散落在个人电脑里的几个脚本。建议至少准备三类 PMC 模板和两个脚本。10.1 推荐工具包结构Procmon-AutoKit ├─ Config │ ├─ Base.pmc │ ├─ Longrun.pmc │ └─ DeepStack.pmc ├─ Scripts │ ├─ Collect-60s.cmd │ ├─ Rotate-ProcmonTrace.ps1 │ ├─ Convert-PML-To-CSV.cmd │ └─ Stop-Procmon.cmd ├─ Logs │ └─ README.md └─ README.md10.2 README 必须写清楚工具用途 适用场景 Procmon 路径 配置模板说明 是否启用 Drop Filtered Events 是否启用 Capture Call Stacks 日志保存位置 采集时长 如何停止 如何打包发给二线没有 README 的脚本工具包很快会变成新的维护负担。10.3 工单中怎么记录使用命令行自动化采集后工单里不要只写“已抓 Procmon”。应该写清楚脚本、模板、时间窗口和关键证据。【采集方式】 使用 Procmon 命令行自动化脚本 Collect-60s.cmd 进行无人值守采集。 【配置模板】 加载 Base.pmc未开启 Drop Filtered Events未开启 Profiling。 【采集时间】 2026-05-19 14:30 至 14:31。 【日志文件】 pm_20260519_143000.pml。 【关键证据】 目标进程 OUTLOOK.EXE 在启动阶段访问 Addins 注册表路径 出现多次 NAME NOT FOUND并伴随加载项 DLL 查询失败。 【后续动作】 建议对比正常机器 Addins 注册表项并检查加载项安装路径和策略状态。高质量工单要让别人知道你用什么模板抓的、抓了哪段、看到了什么、下一步查哪里。11. 总结命令行让 Procmon 从工具变成能力Procmon 的命令行能力本质上是把一次次手工操作固化成标准动作。它不是为了替代 GUI而是为了让采集过程可重复、可远程、可定时、可批量、可交接。本篇最重要的结论可以压缩成三句话第一/LoadConfig 负责统一模板口径第二/BackingFile 负责把现场写入 PML第三/Terminate 和 /SaveAs 负责安全收束与离线转换。从 Mark 式排障视角看自动化不是炫技而是减少人为变量让证据采集过程更稳定。后续处理 Outlook、Explorer、Teams、OneDrive、EDR、飞连、安装失败、启动慢、偶发卡顿等问题时建议把 Procmon 命令行脚本作为桌面支持工具包的一部分。先用 Base 模板做短时采集再用 Longrun 做轮转追踪最后用 DeepStack 做短时间深挖。这样 Procmon 才真正从“临时打开的工具”变成团队可以复用的排障能力。返回顶部