个人主页杨利杰YJlio❄️个人专栏《Sysinternals实战教程》 《Windows PowerShell 实战》 《WINDOWS教程》 《IOS教程》《微信助手》 《锤子助手》 《Python》 《Kali Linux》《那些年未解决的Windows疑难杂症》让复杂的事情更简单让重复的工作自动化ProcDump 学习笔记6.6指定创建转储的条件CPU/内存/挂起/等待/次数1. 为什么要掌握 ProcDump 的触发条件2. 常见触发条件总览3. CPU 触发用 -c 和 -s 抓住持续高占用4. 内存触发用 -m 捕获内存上涨现场5. UI 挂起触发用 -h 抓窗口未响应6. 等待进程出现与限制次数-w 和 -n7. 五类常用模板现场可以直接套用7.1 高 CPU 模板7.2 内存上涨模板7.3 UI 卡死模板7.4 等待进程出现模板7.5 等待进程 CPU 条件模板8. 如何选择触发条件9. 常见问题与踩坑提醒9.1 为什么一直触发不到9.2 为什么触发太频繁9.3 为什么 Dump 体积太大9.4 为什么 UI 卡死但 -h 没抓到9.5 为什么服务进程权限不足10. 一键监控脚本模板11. 我的实战判断12. 小结1. 为什么要掌握 ProcDump 的触发条件在前面的内容里我们已经讲过 ProcDump 如何指定 Dump 保存路径和命名策略。但只知道“Dump 保存到哪里”还不够真正进入实战时更关键的问题是什么时候抓 Dump如果抓得太早进程还没进入异常状态Dump 里看不到关键现场如果抓得太晚进程可能已经恢复、退出或者问题已经被上层逻辑吞掉。ProcDump 的价值正是在于它可以根据 CPU、内存、窗口挂起、进程启动、异常等条件自动触发 Dump让我们不用一直盯着任务管理器等问题出现。Microsoft Learn 对 ProcDump 的定位也很明确它不仅可以用于 CPU 峰值时生成崩溃转储也支持挂起窗口监控、未处理异常监控并能基于系统性能计数器生成 Dump。换句话说它不是单纯的“手动抓 Dump 工具”而是一个可以嵌入脚本和排障流程的触发型诊断工具。:contentReference[oaicite:3]{index3}我的判断是ProcDump 的核心不是“抓 Dump”而是“在正确的时间抓 Dump”。触发条件选错抓到的 Dump 也可能只是噪音。2. 常见触发条件总览ProcDump 的触发条件很多但在企业桌面支持和应用排障场景里最常用的通常是这几类CPU 持续高占用、内存提交达到阈值、窗口未响应、等待进程启动、限制最大抓取次数。问题现象常用参数适合场景CPU 持续高占用-c-s死循环、热点函数、线程异常占用内存持续上涨-m内存泄漏、峰值内存现场UI 未响应-hWinForm、WPF、WinUI、传统桌面程序卡死进程还没启动-w服务、登录启动项、按需拉起程序防止无限抓取-n长时间值守、自动化采集、防止磁盘打满官方参数说明中-c 表示 CPU 阈值-s 表示写入 Dump 前需要连续满足条件的秒数-m 表示内存提交阈值-h 表示进程窗口不响应时写 Dump-n 表示写入 Dump 的数量上限-w 表示等待指定进程启动。:contentReference[oaicite:4]{index4}不要把触发条件理解成“原因判断”。CPU 高只是触发点不等于根因就是 CPU内存高只是触发点不等于一定是内存泄漏。Dump 只是现场证据根因还要靠后续 WinDbg、调用栈和上下文分析。3. CPU 触发用-c和-s抓住持续高占用CPU 触发是 ProcDump 最经典的使用场景。很多软件问题不是直接崩溃而是表现为“程序没死但 CPU 一直很高”。这类问题常见于死循环、线程忙等、异常重试、同步等待、插件冲突、第三方模块反复调用等场景。基础命令如下procdump -ma -c 80 -s 10 -n 1 1234 D:\Dumps\HotCPU这条命令的意思是当 PID 为 1234 的进程 CPU 使用率达到 80%并且连续保持 10 秒时生成一份完整 Dump保存到 D:\Dumps\HotCPU 目录。这里有三个参数要特别注意-c 80CPU 达到 80% 作为触发阈值-s 10持续 10 秒后才写 Dump-n 1最多只抓 1 份防止反复刷盘。官方文档中也给出了类似示例例如进程超过指定 CPU 使用率并持续若干秒后写入多份 Dump。:contentReference[oaicite:5]{index5}推荐做法CPU 问题不要只写 -c最好配合 -s。因为瞬时尖峰不一定有分析价值持续高占用才更接近真正的问题现场。补充说明如果你希望 CPU 判断按单核相对值处理官方提供了 -u 参数可与 -c 配合使用。这个点不要含糊写成“100% 就一定代表单核满载”不同观察口径会造成误解。:contentReference[oaicite:6]{index6}4. 内存触发用-m捕获内存上涨现场如果用户反馈软件越用越慢、运行几个小时后卡死、内存不断上涨或者某个服务进程提交内存持续增加就可以考虑使用 -m 触发 Dump。示例命令如下procdump -ma -m 4096 -n 3 MyApp.exe D:\Dumps\MemLeak这条命令表示当 MyApp.exe 的提交内存达到 4096MB 时生成完整 Dump最多抓 3 份保存到 D:\Dumps\MemLeak 目录。官方文档对 -m 的定义是当内存提交达到指定 MB 值时创建 Dump这意味着它关注的是 commit usage而不是你在任务管理器里随便看到的某一个“内存”列。:contentReference[oaicite:7]{index7}这里最容易犯的错误是阈值乱填。比如应用正常峰值就能到 3GB你直接设 4096MB 可能永远触发不到如果正常启动就已经 2GB你设 2048MB 可能刚启动就触发抓不到泄漏阶段。比较稳的做法是先观察一段时间例如用任务管理器、资源监视器、性能监视器或历史监控数据确认正常区间再把阈值设置在“接近问题出现前”的位置。实战建议内存问题优先抓多份 Dump而不是只抓一份。因为泄漏分析往往需要对比不同时间点的对象增长趋势。5. UI 挂起触发用-h抓窗口未响应很多桌面软件不是崩溃而是卡在界面上不动标题栏显示“未响应”。这类问题通常和 UI 线程阻塞、同步等待、主线程长时间执行耗时任务、消息泵卡住有关。可以使用 -h 参数procdump -ma -h -n 1 notepad.exe D:\Dumps\UIHang这条命令表示当 notepad.exe 的窗口出现未响应时抓取一份完整 Dump。官方说明中-h 的触发条件是进程存在挂起窗口即窗口至少 5 秒没有响应窗口消息。这个定义和 Windows / 任务管理器对窗口挂起的判断一致。:contentReference[oaicite:8]{index8}这也说明了它的边界-h 适合 GUI 程序不适合没有窗口消息泵的后台服务或纯控制台进程。如果是服务进程卡死但没有窗口界面不要硬套 -h。这时更应该从 CPU、内存、性能计数器、线程状态或异常触发入手。不要把“用户感觉卡”直接等同于 -h 能触发。只有窗口进入未响应状态-h 才更可靠。6. 等待进程出现与限制次数-w和-n有些进程不是一直运行的而是用户登录后才启动、服务按需拉起、任务计划触发后短暂出现。你如果手动等它启动很容易错过现场。这个时候就要用 -w。示例命令如下procdump -ma -w MyService.exe -c 70 -s 10 -n 2 D:\Dumps\SvcHot这条命令表示ProcDump 先等待 MyService.exe 出现进程启动后继续监控当 CPU 达到 70% 并持续 10 秒时抓 Dump最多抓 2 份。官方说明中-w 的作用是当指定进程尚未运行时等待它启动-n 则用于限制写入 Dump 的数量达到数量后 ProcDump 退出。:contentReference[oaicite:9]{index9}-w 条件 -n 输出目录 是很适合一线排障的组合。它能解决“进程还没出现”和“Dump 无限增长”两个问题。注意如果你要监控的是反复退出又重启的进程单次 ProcDump 会话未必覆盖你想要的所有轮次。必要时要用外层批处理、计划任务或服务化脚本做循环包装。7. 五类常用模板现场可以直接套用下面这些命令模板可以作为排障起点。注意它们不是万能命令而是“按现象选触发条件”的基础模板。7.1 高 CPU 模板procdump -ma -c 80 -s 10 -n 1 PID或进程名 D:\Dumps\HotCPU适合进程 CPU 长时间高占用的场景。后续分析重点放在线程栈、热点线程、循环调用和第三方模块。7.2 内存上涨模板procdump -ma -m 4096 -n 3 PID或进程名 D:\Dumps\MemLeak适合内存持续增长、运行一段时间后变慢、疑似泄漏的场景。建议抓多份用于对比对象增长。7.3 UI 卡死模板procdump -ma -h -n 1 GUI进程名 D:\Dumps\UIHang适合窗口显示“未响应”的桌面程序。后续重点查看主线程栈是否阻塞在同步调用、IO、锁等待或第三方插件中。7.4 等待进程出现模板procdump -ma -w MyService.exe -e -n 1 D:\Dumps\ServiceCrash适合服务或按需启动进程。这里示例中用了 -e 作为异常触发异常类触发会在后续单独展开。7.5 等待进程 CPU 条件模板procdump -ma -w MyService.exe -c 70 -s 10 -n 2 D:\Dumps\SvcHot适合进程启动后快速进入高 CPU 的问题。比手动等进程出现再敲命令更稳。8. 如何选择触发条件选触发条件时不要先问“哪个参数厉害”要先问“用户看到的现象是什么”。这是排障思路不是参数背诵。用户反馈问题主要现象是什么CPU持续高内存持续涨窗口未响应进程还没启动不确定或偶发-c -s -n-m -n-h -n-w 其他条件先观察再设阈值如果是高 CPU优先考虑 -c -s如果是内存上涨优先考虑 -m如果是窗口未响应优先考虑 -h如果进程还没出现先用 -w 等待如果需要控制风险始终配合 -n。这里的底层逻辑是现象决定触发条件触发条件决定抓取时机Dump 再用于解释根因。别反过来。不要因为会用某个参数就把所有问题都套进去。那不是排障是工具崇拜。9. 常见问题与踩坑提醒9.1 为什么一直触发不到最常见原因是阈值设置不合理。CPU 阈值太高、持续秒数太长、内存阈值超过实际峰值都会导致 ProcDump 一直等待。处理方法很简单先观察实际曲线再调整阈值。不要凭感觉写 80%、4096MB、10 秒。现场数据比经验值更可靠。9.2 为什么触发太频繁如果 CPU 阈值太低、没有设置 -s或者内存阈值接近正常运行值就会反复触发。解决方法是提高阈值、增加持续时间并配合 -n 限制最大抓取次数。9.3 为什么 Dump 体积太大-ma 是完整 Dump信息最全但体积也最大。官方文档说明 -ma 包含所有 Image、Mapped 和 Private 内存也包含进程、线程、模块、句柄、地址空间等元数据。:contentReference[oaicite:10]{index10}如果磁盘空间有限可以考虑 -mp。官方说明中MiniPlus Dump 通常比 Full Dump 小但仍保留较多分析信息不过 CLR 进程可能因调试限制转为 Full Dump。:contentReference[oaicite:11]{index11}9.4 为什么 UI 卡死但-h没抓到可能原因是目标程序没有标准 GUI 窗口、窗口消息泵状态不符合挂起判断或者用户感受到的“卡”并没有进入 Windows 认为的未响应状态。此时要换思路改用 CPU、内存、性能计数器或手动抓取。9.5 为什么服务进程权限不足对服务、系统进程、高权限进程抓 Dump 时建议使用管理员控制台运行 ProcDump。否则可能附加失败或无法写入 Dump 文件。现场交付脚本时建议固定做三件事检查管理员权限、创建 Dump 目录、限制最大抓取次数。10. 一键监控脚本模板下面给一个偏实战的 BAT 模板适合对某个进程做 CPU 高占用监控。你可以根据现场情况改应用名、阈值、持续时间和输出目录。echo off setlocal :: 基础配置 set APP_NAMEMyApp.exe set DUMP_DIRD:\Dumps\HotCPU set CPU_THRESHOLD80 set SECONDS10 set MAX_DUMPS3 :: 检查管理员权限 whoami /groups | find S-1-16-12288 nul if errorlevel 1 ( echo [!] 请以管理员身份运行此脚本。 pause exit /b 1 ) :: 创建 Dump 目录 if not exist %DUMP_DIR% ( mkdir %DUMP_DIR% ) :: 检查目录可写 echo test %DUMP_DIR%\write_test.tmp 2nul if errorlevel 1 ( echo [!] Dump 目录不可写%DUMP_DIR% pause exit /b 1 ) del %DUMP_DIR%\write_test.tmp nul 2nul echo [] 正在监控进程%APP_NAME% echo [] CPU 阈值%CPU_THRESHOLD%%% echo [] 持续时间%SECONDS% 秒 echo [] 最大 Dump 数量%MAX_DUMPS% echo [] Dump 输出目录%DUMP_DIR% echo. procdump -ma -c %CPU_THRESHOLD% -s %SECONDS% -n %MAX_DUMPS% %APP_NAME% %DUMP_DIR% echo. echo [] ProcDump 已退出请检查 Dump 目录。 pause endlocal如果你要改成 UI 挂起触发可以把最后一行替换为procdump -ma -h -n 1 %APP_NAME% %DUMP_DIR%如果你要改成内存阈值触发可以替换为procdump -ma -m 4096 -n 3 %APP_NAME% %DUMP_DIR%这类脚本的价值不是复杂而是把现场容易漏掉的检查项固定下来权限、目录、可写性、次数限制。11. 我的实战判断ProcDump 的触发条件真正考验的不是你记住了多少参数而是你能不能把用户描述翻译成系统对象和可验证条件。用户说“软件卡”你要继续问是 CPU 高还是 UI 未响应是内存一直涨还是启动后一段时间才异常是进程已经运行还是进程偶尔才出现这些问题问清楚以后参数自然就出来了。如果现场信息不足我不建议一上来就堆复杂参数。先用任务管理器、资源监视器或性能计数器观察基本趋势再决定触发条件。否则你抓到的 Dump 很可能不是问题现场只是某个正常运行瞬间。比较稳的顺序是先观察现象再选择触发条件再控制 Dump 数量最后用 WinDbg 分析调用栈。最不建议的做法是用户说卡你直接丢一个命令用户说慢你直接抓完整 Dump用户说偶发你不设 -n 长期挂着。这样不是专业是给现场制造新风险。12. 小结这一篇的核心结论很明确ProcDump 的触发条件决定了 Dump 的价值。抓 Dump 不是目的抓到“问题发生当时的现场”才是目的。常用参数可以这样记:: CPU 持续高占用 procdump -ma -c 80 -s 10 -n 1 进程 D:\Dumps\HotCPU :: 内存达到阈值 procdump -ma -m 4096 -n 3 进程 D:\Dumps\MemLeak :: UI 窗口未响应 procdump -ma -h -n 1 GUI进程 D:\Dumps\UIHang :: 等待进程出现后再监控 procdump -ma -w 进程名 -c 70 -s 10 -n 2 D:\Dumps\WaitAndCapture如果只带走一句话那就是CPU 用 -c -s内存用 -m窗口未响应用 -h进程未启动用 -w长时间监控必须加 -n。把触发条件、输出目录、Dump 类型、次数限制组合好ProcDump 才能真正从“临时工具”变成“可复用的排障武器”。 返回顶部点击回到顶部