进程和诊断工具速查手册（8.13）：VMMap / DebugView / LiveKd / Handle / ListDLLs 一页式现场排障清单

[进程和诊断工具速查手册（8.13）：VMMap / DebugView / LiveKd / Handle / ListDLLs 一页式现场排障清单](#进程和诊断工具速查手册（8.13）：VMMap / DebugView / LiveKd / Handle / ListDLLs 一页式现场排障清单)
- [1. 五个工具分别解决什么问题？](#1. 五个工具分别解决什么问题？)
- [2. 每个工具的核心命令怎么用（最小必要用法）](#2. 每个工具的核心命令怎么用（最小必要用法）)
- - [2.1 VMMap：抓进程的内存快照](#2.1 VMMap：抓进程的内存快照)
  - [2.2 DebugView：听进程"说话"，包括它卡死时的遗言](#2.2 DebugView：听进程“说话”，包括它卡死时的遗言)
  - [2.3 LiveKd：不重启就看内核的现场结构（高级用法）](#2.3 LiveKd：不重启就看内核的现场结构（高级用法）)
  - [2.4 Handle：谁占着文件不放？](#2.4 Handle：谁占着文件不放？)
  - [2.5 ListDLLs：看看进程"吃了什么奇怪的药"](#2.5 ListDLLs：看看进程“吃了什么奇怪的药”)
- [3. 标准故障场景 → 工具组合推荐（拿去当SOP）](#3. 标准故障场景 → 工具组合推荐（拿去当SOP）)
- - [场景 A：进程疯狂吃内存，服务器快被吃死了](#场景 A：进程疯狂吃内存，服务器快被吃死了)
  - [场景 B：文件删不了，一直说"正在被占用"](#场景 B：文件删不了，一直说“正在被占用”)
  - [场景 C：整台机器卡到怀疑驱动问题](#场景 C：整台机器卡到怀疑驱动问题)
  - [场景 D：怀疑外挂/植入/Hook](#场景 D：怀疑外挂/植入/Hook)
- [4. 风险提示（请不要忽视）](#4. 风险提示（请不要忽视）)
- [5. 统一"应急包"导出清单（推荐强制标准化）](#5. 统一“应急包”导出清单（推荐强制标准化）)
- [6. 这一页怎么用在团队里？](#6. 这一页怎么用在团队里？)
- - 最后一口气总结

进程和诊断工具速查手册（8.13）：VMMap / DebugView / LiveKd / Handle / ListDLLs 一页式现场排障清单

这一篇是第 8 章的"口袋卡片版"。

目的很直接：当现场机器已经卡得不行、老板在你身后盯着、客户在喊"别重启我们在跑业务"，你不可能翻几十页笔记慢慢找命令。

所以我把第 8 章的工具全部压缩成一个随拿随用的速查手册，重点回答三件事：

遇到某种典型故障 → 我该用哪个工具？
工具怎么跑？要保存哪些证据？
风险点在哪？千万别手抖把现场搞崩

你可以把这一篇直接塞到应急手册或者团队 Wiki 里。

1. 五个工具分别解决什么问题？

工具	主要作用	用在什么时候
VMMap	分析单个进程的内存使用结构（堆、映射文件、私有提交、图像等）	某进程内存狂涨 / "内存泄漏怀疑" / Out Of Memory 但还没崩
DebugView	抓调试输出（用户态 + 可选内核态），不改程序代码也能看日志	程序界面卡死但进程没死 / 现场重现不了日志 / 需要看程序"在想啥"
LiveKd	在不重启系统的情况下拿当前内核态的视角（线程栈、锁、驱动状态）	整台机器卡、蓝屏前兆、怀疑驱动/内核死锁、I/O 堵死
Handle	看"哪个进程正在占用这个文件/句柄/注册表键"并（高危！）可释放它	文件删不掉、日志无法旋转、U 盘弹不出、服务说"文件正在使用"
ListDLLs	列出某进程加载的全部模块（DLL），包括路径和基址	怀疑被注入/外挂/劫持；第三方 Hook；兼容性污染；异常 DLL 残留

可以这样理解：

占用资源不正常？→ Handle
内存不正常？→ VMMap
行为不正常？→ DebugView
驱动/系统不正常？→ LiveKd
成分不正常？→ ListDLLs

2. 每个工具的核心命令怎么用（最小必要用法）

下面是"直接抄过去就能跑"的最小命令套路。所有命令都应在管理员权限下执行（大多数情况下是必需的）。

2.1 VMMap：抓进程的内存快照

目标：某个进程内存飙到 8GB+，但你不知道它到底花在堆上还是内存映射上。

步骤：

以管理员身份运行 VMMap.exe
选择目标进程（比如 app.exe 或 java.exe)
观察几个关键字段：
- Private Bytes / Private Data：自己独占、最容易"炸内存"的那类
- Heap：经典的堆内存泄漏
- Mapped File：内存映射的文件越多，可能是在疯狂内存映射日志、缓存或大文件
点 Save / Save Snapshot 保存 .mvp 文件（这是快照，带走就能日后对比）

建议操作：

拍两张快照，间隔 1～2 分钟：
- leak_before.mvp
- leak_after.mvp
后面你可以在自己电脑上用 VMMap 打开 .mvp 对比增长趋势（不必一直远程连客户机器）

2.2 DebugView：听进程"说话"，包括它卡死时的遗言

用途：程序 UI 无响应，但没崩；日志系统没跑起来；开发说"我这边没问题啊"。

步骤：

打开 DbgView.exe（DebugView）
勾选顶部菜单里的：
- Capture Win32
- Capture Global Win32
- 如果怀疑驱动/内核 → 再勾 Capture Kernel
重现问题或等待卡顿
File -> Save... 导出日志，例如保存成 debugtrace.log

你会在日志里看到什么？

模块/线程初始化卡在哪
死锁前最后打印到 OutputDebugString 的警告
某些驱动报错（如果启了内核捕获）

风险：

几乎无侵入，适合第一时间做；属于"安全、不破坏现场"的取证。

2.3 LiveKd：不重启就看内核的现场结构（高级用法）

用途：整机卡成 PPT 播放器了，鼠标都快动不了；怀疑蓝屏前兆；某个驱动一直把 CPU 吃满。

典型行为：

运行 livekd.exe
接受符号协议（推荐提前准备符号路径，以便拿到可读的栈）
进入调试器提示符（WinDbg/KD 风格）

在调试器里可以跑比如：

text 复制代码

!process 0 1
!thread
!locks
!irpfind
!drvobj <drivername>

这类命令能回答：

哪些线程卡住了？
是否存在死锁？
是哪个驱动导致等待？
有没有疯狂 pending 的 I/O？

保存证据：

把这些命令的输出复制到 livekd_session.txt
发给内核/驱动同学，他们非常需要这个

风险提醒：

LiveKd 不会强制重启系统，这点很关键（一般是安全的）
但是它要求管理员/Debug 权限，普通用户跑不了
不要随手在内核调试器里做破坏性命令（比如强行修改内核对象），常规调查只读即可

2.4 Handle：谁占着文件不放？

用途：

"删不掉，说文件正在使用"
"日志切不了，rotating 失败"
"U盘弹不出：设备正忙"
"服务停不下来，说资源占用中"

常用命令：

cmd 复制代码

handle somefile.log

输出里你会看到：

哪个进程 (进程名 + PID)
用的是什么类型的句柄（File, Mutant, Key, Section, ...）
句柄编号（例如 0x00000054）

把这个输出重定向保存是非常重要的取证：

cmd 复制代码

handle somefile.log > handle_result.txt

进阶（高风险）

Handle 还可以"强制释放"句柄，类似"把别人手里的文件抢回来"，但这个动作有可能：

让那个进程瞬间崩掉
造成数据不完整 / 丢写入
破坏系统稳定性

原则：生产环境慎用；做之前一定留备份/取证。

2.5 ListDLLs：看看进程"吃了什么奇怪的药"

用途：

你怀疑有第三方 DLL 注入（外挂/广告/恶意 Hook）
进程表现古怪，不像官方版本
兼容性问题：线上跑的是不是你以为的那套 DLL？

命令示例：

cmd 复制代码

listdlls app.exe > modules_snapshot.txt

或者按 PID：

cmd 复制代码

listdlls -p 1234 > modules_snapshot.txt

输出里包含：

DLL 名称
加载基址
完整路径

看哪些点最关键？

非签名 DLL
位于奇怪路径（比如 %TEMP%、AppData\Roaming\RandomFolder、临时下载目录）
DLL 名字借壳（例如假冒系统 DLL：svch0st.dll 这类）

这份输出是取证级别证据，尤其在安全事件中非常关键。

3. 标准故障场景 → 工具组合推荐（拿去当SOP）

场景 A：进程疯狂吃内存，服务器快被吃死了

用 VMMap 拍两次快照（前/后） → 对比哪类内存涨
用 DebugView 抓一下该进程在说什么（比如"正在分配缓存..."）
用 ListDLLs 确认这个进程是不是被第三方模块勾住了

拿到三份证据后，你可以远程交给开发/内存分析同学，他们基本能定位方向（堆泄漏、缓存策略、第三方拦截、内存映射循环开文件等）。

场景 B：文件删不了，一直说"正在被占用"

handle full\path\to\that.file > handle_result.txt
确定是哪个进程+PID占用
决策：
- 能否安全停这个进程/服务？
- 如果这是生产服务，是否可以先复制日志再清理？
必要时（万不得已）才考虑强行释放句柄，动作前一定留证据和变更记录

场景 C：整台机器卡到怀疑驱动问题

DebugView（含内核捕获）看是否有驱动报错/警告
跑 LiveKd，导出 !thread / !locks / !irpfind 或类似信息
- 这个结果给内核/驱动/平台组是黄金信息
如果涉及磁盘 I/O 堵塞，也可以留下一份"哪个进程持有哪些句柄"的 handle > handle_all.txt 作为补充

场景 D：怀疑外挂/植入/Hook

listdlls target.exe > modules_snapshot.txt
看可疑 DLL 的路径、签名
如果这个进程同时在大量占用资源（文件/网络/日志），可以再配合：
- handle 看它都抓着什么资源
- VMMap 看它是不是占用异常类型的内存（比如反常的 Shared / Mapped File）

4. 风险提示（请不要忽视）

Handle 的强制关闭句柄 = 手术刀。能杀进程。别随便用在生产。
LiveKd 是强力工具，但对权限要求高；请避免"我试试乱敲命令"这种行为。
DebugView 捕获内核输出 在极高负载环境可能略有开销，但通常还是安全的。建议仅在必要时勾选。
现场数据往往包含敏感信息 （路径、用户名、进程名、密钥、内网结构、代码路径）。
打包发日志前，先按公司合规要求脱敏或限制范围。

5. 统一"应急包"导出清单（推荐强制标准化）

当你在生产环境处理疑难问题时，建议始终导回以下文件：

handle_result.txt
- 哪个 PID 占用哪个资源
vmmap_before.mvp / vmmap_after.mvp
- 进程内存两次快照
modules_snapshot.txt
- listdlls 输出，证明进程当前模块组成
debugtrace.log
- DebugView 捕获到的现场调试输出（用户态 + 内核态）
livekd_session.txt（如有）
- 从 LiveKd 拿到的线程栈、锁、驱动状态

把这五个文件打包给研发/平台/内核同学，基本就能让"远端专家"远程复原现场，而不用一直拉着产线机器在线诊断。

6. 这一页怎么用在团队里？

最实用的落地方式就是做两件事：

把这篇放到你的团队 Wiki / 应急手册 / 值班手册里

标注为「Windows 现场诊断包 - 快速版」。
提前发放 Sysinternals 工具合集（VMMap、DebugView、Handle、ListDLLs、LiveKd）
- 统一保存到一台可信的"维护工具盘"或内部共享
- 让一线同学拿到就是能跑，不用临时下载、临时申请

这样等到半夜生产"卡了但不能重启"，值班人不是慌，而是：

→ 10 分钟内按 SOP 出一个打包好的应急包，扔给后端/内核/安全同学，现场不乱。

最后一口气总结

VMMap 看"内存去哪了"
DebugView 听"程序怎么说"
LiveKd 问"内核在干嘛"
Handle 查"谁不放手"
ListDLLs 看"谁混进来了"
全部信息一键打包，回传分析，沉淀 SOP。

到这里，第 8 章的整套工具已经不只是"我会用"，而是"我能把它变成团队的标准动作"。这就是从个人排障到体系化应急响应之间的分界线。