《Sysinternals实战指南》进程和诊断工具学习笔记（8.15）：实战案例｜内存狂涨 / 句柄泄漏怎么查？用 VMMap + Handle + ListDLLs 三步定位
进程和诊断工具学习笔记（8.15）：实战案例｜内存狂涨 / 句柄泄漏怎么查？用 VMMap + Handle + ListDLLs 三步定位
- 1. 问题背景：内存狂涨和句柄泄漏不能靠猜
- 2. 先建立判断模型：三类问题不要混在一起
- 3. 第一步：用 VMMap 判断内存到底涨在哪
- 4. 第二步：用 Handle 判断是不是句柄泄漏
- 5. 第三步：用 ListDLLs 看进程里有没有外来模块
- 6. 把三步串成一条完整证据链
- 7. 现场处置建议：先取证，再恢复
- 8. 总结：资源泄漏排查要从“感觉题”变成“证据题”
1. 问题背景：内存狂涨和句柄泄漏不能靠猜
在 Windows 现场排障里，“某个进程内存突然冲到几个 GB”“服务跑久了越来越慢”“日志文件删不掉”“系统提示资源不足”这些问题非常常见。很多一线处理方式是重启服务、重启机器，短期看确实能恢复，但问题没有被解释清楚，下一次还会继续发生。
真正专业的排查，不是第一时间杀进程，而是先把现场证据留下来。因为内存狂涨、句柄泄漏、DLL 注入、资源锁定看起来都像“系统卡”，但根因完全不同。任务管理器只能告诉你“谁高”，不能告诉你“为什么高”。
这一篇的目标很明确：用 **VMMap + Handle + ListDLLs** 三个工具，把“我感觉它泄漏”变成“我能证明它在哪里泄漏”。
下面这张图展示的是本文的整体排查框架：先定位目标进程 PID，再分别从内存、句柄、模块三个角度采证，最后形成一条完整证据链。
从图中可以看出，这套方法不是单纯打开一个工具看数字，而是按顺序做判断。推荐先锁定 PID，再用 VMMap 看内存构成，用 Handle 看资源占用，用 ListDLLs 看模块污染。这样最后得出的结论才经得住开发、安全、领导三方追问。
不要一上来就 taskkill。进程一杀，内存状态、句柄状态、模块加载现场都会消失，你也就失去了最关键的证据。
2. 先建立判断模型：三类问题不要混在一起
现场最容易犯的错误，是把所有资源问题都叫“内存泄漏”。实际上，至少要分成三类看：内存泄漏、句柄泄漏、模块注入或第三方 DLL 造成的异常占用。
内存泄漏通常表现为 Private Bytes、Heap、Private Data 这类私有提交内存持续上涨。句柄泄漏则可能表现为句柄数量越来越多，文件、注册表、事件、互斥量等对象被重复打开却不关闭。模块注入则可能表现为进程中出现不属于业务自身的 DLL，后续资源消耗其实是这个外来模块引起的。
这个流程图的核心价值在于分层。VMMap 回答“内存涨在哪”，Handle 回答“谁占着资源不放”，ListDLLs 回答“进程里混进了谁”。三者结合后，结论才不会停留在表面。
推荐所有异常资源类工单都按这个三分法记录：内存证据、句柄证据、模块证据。
3. 第一步：用 VMMap 判断内存到底涨在哪
VMMap 的价值在于，它不会只告诉你“这个进程用了 3GB 内存”，而是把这 3GB 拆开告诉你：是 Private Bytes、Heap、Mapped File、Image、Stack，还是 GDI / USER 对象。
现场排查时，建议先用任务管理器或 `tasklist` 找到异常进程 PID，然后打开 VMMap 附加到该 PID。不要只按进程名判断，尤其是 `java.exe`、`w3wp.exe`、`chrome.exe` 这种多实例进程，按 PID 才不会查错对象。
tasklist /v | findstr /i "TargetApp.exe"这张图展示的是 VMMap 的快照对比：T0 和 T1 之间，Private Bytes 与 Heap 明显上升，而 Mapped File 与 GDI / USER 基本稳定。
从图中可以看出，问题不是“系统整体内存不够”，而是目标进程内部的私有提交和堆内存持续增长。这类证据比任务管理器截图更有价值，因为它已经把问题方向从“系统卡”压缩到了“进程自身分配内存持续上涨”。
如果 VMMap 里 Private Bytes / Private Data / Heap 从 T0 到 T1 持续上涨，并且没有明显回落，就可以初步判断为用户态内存泄漏嫌疑。此时你给开发的结论不应该是“内存高”，而应该是：
**目标进程的私有提交内存持续上涨，增长主要集中在 Heap / Private Data，疑似业务逻辑分配对象后未释放。**
推荐至少保存两次 VMMap 快照：T0 基线快照和 T1 增长快照。如果时间允许，再保存 T2，用趋势证明问题不是瞬时峰值。
只截一张“内存 3GB”的图，说服力不够。没有时间线，就很难证明它是泄漏，而不是正常缓存或短时峰值。
4. 第二步：用 Handle 判断是不是句柄泄漏
有些问题看起来像内存问题，其实是句柄问题。比如文件删不掉、日志无法轮转、U 盘弹不出、系统提示资源不足、程序越跑越慢但内存不一定特别夸张，这些都可能和句柄泄漏有关。
Handle.exe 可以枚举进程当前持有的对象句柄，包括 File、Key、Section、Mutant、Event、Thread 等。现场最常用的命令是按 PID 查看某个进程的句柄。
handle.exe -p 1234如果你已经知道某个文件删不掉，也可以直接反查是谁占着它。
handle.exe "D:\logs\service.log"下面这张图展示的是典型句柄泄漏现场：同一个日志文件被大量重复打开，File 句柄数量持续上涨，并且资源处于锁定状态。
从图中可以看出，这不是单个文件被正常占用，而是大量同类文件句柄反复出现。如果 File 句柄数量在几分钟内持续增加，就要怀疑代码里存在打开文件后没有 CloseHandle、没有释放 FileStream、日志组件未正确轮转等问题。
判断句柄泄漏时，不要只看一次输出。更稳妥的做法是隔 30 秒或 1 分钟采样一次，保存到文件，然后比较同类对象数量是否增长。
handle.exe -p 1234 > handle_T0.txt timeout /t 60 handle.exe -p 1234 > handle_T1.txt如果输出里同一个路径、同一个注册表键、同一个命名对象不断重复出现，你就可以把问题描述得非常具体：
**目标进程在持续持有 `D:\logs\service.log` 相关 File 句柄，句柄数量从 T0 到 T1 明显增加，疑似日志文件句柄未及时关闭。**
推荐把 Handle 输出和 VMMap 快照放在同一时间线里。这样可以判断内存增长是否伴随句柄增长。
Handle 支持关闭句柄，但这属于破坏性动作。生产环境优先停服务或回收进程，不要随便强关系统关键进程句柄。
5. 第三步：用 ListDLLs 看进程里有没有外来模块
如果 VMMap 显示内存增长，Handle 显示句柄异常，还不能急着把锅直接扣给主程序。因为有些资源泄漏不是 EXE 本体写出来的，而是第三方 DLL、插件、Hook 模块、安全代理、加密狗组件、广告劫持模块造成的。
ListDLLs 的作用，就是列出指定进程当前加载的 DLL 和模块路径。它能帮你确认：这个进程里到底混进了哪些模块。
listdlls.exe -p 1234 > modules_1234.txt排查时重点看三类异常：第一，模块路径是否来自奇怪目录；第二，模块是否未签名；第三，是否出现与业务无关的插件或 Hook DLL。
下面这张图展示的是 ListDLLs 的典型安全排查视角：正常系统 DLL 都来自 System32 或程序安装目录，而可疑 DLL 来自公共目录并且未签名。
从图中可以看出，`evilhook.dll` 这类模块最关键的问题不是名字吓人，而是加载路径可疑、签名状态异常，并且被注入到目标进程中。如果资源上涨时间点和某个 DLL 加载时间点高度吻合，就要把该 DLL 纳入嫌疑范围。
在企业桌面或服务器环境中，异常 DLL 的来源很多：浏览器插件、输入法插件、截图工具、DLP、安全代理、加密狗、打印插件、远程控制组件，都可能向目标进程注入模块。不要只盯业务代码本身。
推荐将 ListDLLs 输出与“健康机器”的模块清单做对比。差异模块往往就是排查突破口。
不要把完整 DLL 清单随意发到公网。模块路径可能暴露公司内部软件、插件、目录结构和安全组件信息。
6. 把三步串成一条完整证据链
真正能交付给开发、领导或安全团队的，不是一张截图，而是一条证据链。VMMap 证明哪类内存在涨，Handle 证明哪些资源没有释放，ListDLLs 证明进程中是否存在异常模块。三者拼起来，才能把“猜测”推进到“结论”。
这张图展示的是完整现场排障 SOP：从定位进程开始，依次采集 VMMap、Handle、ListDLLs 证据，最后形成结论。
从图中可以看出，SOP 的关键不是工具多，而是顺序正确。先定位进程，后采集证据；先判断资源类型，再定位可疑模块；先保存现场，再考虑重启或回收。
一份合格的资源异常初步报告，至少应包括这些内容：目标主机、进程名、PID、采样时间、VMMap 快照结论、Handle 句柄结论、ListDLLs 模块结论、初步根因判断、临时处置建议。
【告警时间】 YYYY-MM-DD HH:MM 【目标信息】 主机名： 进程名： PID： 业务影响： 【VMMap 结论】 Private / Heap 是否持续上涨： Mapped File 是否异常： 是否保存 T0 / T1 快照： 【Handle 结论】 句柄总数： 异常句柄类型： 重复资源路径： 是否持续增长： 【ListDLLs 结论】 是否存在异常模块： 模块路径： 签名状态： 是否与业务自身相关： 【初步判断】 - 疑似业务自身内存泄漏 - 疑似句柄泄漏 - 疑似第三方 DLL 注入或模块污染 - 需要进一步 ProcDump / Procmon / LiveKd 取证 【建议动作】 临时止血： 根因修复： 是否需要变更窗口：推荐将这个模板固化到团队知识库或应急手册里。值班同事按模板采集，你后续复盘时就不会面对一堆没有时间线、没有 PID、没有证据来源的截图。
7. 现场处置建议：先取证，再恢复
资源异常现场最容易出现两个极端：一种是直接重启，证据全丢；另一种是死盯工具，不敢恢复业务。正确做法应该是先快速采证，再根据影响程度选择临时止血。
如果业务已经严重不可用，可以采集最小证据包后重启服务。最小证据包至少包括：VMMap 快照、Handle 输出、ListDLLs 输出、任务管理器或 `tasklist` 的 PID 信息、采样时间。
tasklist /v > tasklist_snapshot.txt handle.exe -p 1234 > handle_1234_T0.txt listdlls.exe -p 1234 > listdlls_1234_T0.txt如果业务还能撑住，则建议继续采样 T1、T2，形成趋势证据。对于开发而言，“一直高”不如“每 5 分钟上涨 500MB”有价值；对于领导而言，“疑似”不如“有趋势截图和采样输出”有说服力。
不要为了追求完整证据而让生产系统继续恶化。如果内存已经逼近物理上限或句柄数异常巨大，应先完成最小证据采集，再按变更流程重启或切换。
推荐现场处置顺序：定位 PID → 采最小证据 → 判断业务风险 → 决定继续采样或临时恢复 → 后续交给开发/安全深入分析。
8. 总结：资源泄漏排查要从“感觉题”变成“证据题”
内存狂涨和句柄泄漏最怕模糊表达。比如“服务有点卡”“内存好像高”“可能是泄漏”，这些话不能推动问题解决。真正能推动开发修复、领导批准窗口、安全团队介入的，是证据。
这篇文章的核心方法可以压缩成三句话：**看内存用 VMMap，看资源占用用 Handle，看外来模块用 ListDLLs。**
VMMap 让你知道内存涨在哪；Handle 让你知道资源被谁占着不放；ListDLLs 让你知道进程里是否混入异常模块。三者组合起来，就能把“内存高 / 资源不足 / 文件占用 / 模块异常”这些现场问题拆成可验证、可复盘、可交付的证据链。
推荐把这套方法固化为企业内部资源异常 SOP，特别适用于服务器进程内存暴涨、桌面软件卡死、日志无法轮转、文件无法删除、疑似 DLL 注入等场景。
最后再强调一次：先取证，再回收。没有证据的重启，只是把问题延后；有证据的恢复，才是可复盘的运维。
🔝 返回顶部
点击回到顶部