《Sysinternals实战指南》进程和诊断工具学习笔记（8.17）：LiveKd 实战——运行方式、常用参数、现场采集套路

🔥个人主页：杨利杰YJlio

❄️个人专栏：《Sysinternals实战教程》 《Windows PowerShell 实战》 《WINDOWS教程》 《IOS教程》

《微信助手》 《锤子助手》 《Python》 《Kali Linux》

《那些年未解决的Windows疑难杂症》

🌟让复杂的事情更简单，让重复的工作自动化

1. 为什么这一篇要讲 LiveKd 实战

前面我们已经知道，LiveKd 是 Sysinternals 工具链里非常硬核的一类工具。它不是普通的进程查看器，也不是常规日志工具，而是一个可以让我们在 Windows 系统仍然运行的情况下，进入内核态观察现场的诊断工具。

但只知道概念没有用。真正到生产现场，问题往往不是“LiveKd 是什么”，而是：**我怎么启动？用什么权限启动？到底是直接开 WinDbg，还是先导出 Dump？采完之后给谁看？哪些命令最值得先跑？**

这一篇就专门解决这些实战问题。我的目标不是把 LiveKd 讲成内核开发课程，而是把它整理成桌面运维、系统工程、应急响应人员都能落地使用的现场采集流程。

LiveKd 的核心价值，是在不重启、不蓝屏的前提下，尽量拿到当前系统的内核态现场。这类证据对排查非分页池暴涨、驱动卡死、系统顿卡、Hyper-V 来宾异常非常关键。

下面这张图展示的是 LiveKd 启动前最关键的准备事项，包括管理员权限、WinDbg/KD、符号访问和系统位数匹配。

从图中可以看出，LiveKd 不是一个“随手双击就完事”的工具。它接触的是内核现场，因此准备工作非常关键。建议每次现场使用前都先确认权限、调试器、符号和系统架构，准备好了再采集。

不要在生产机器上临时乱下载调试器、乱开内核工具、乱导出 Dump。LiveKd 是手术刀，不是普通体检工具。

2. 启动 LiveKd 前的基本操作习惯

LiveKd 直接和内核打交道，所以启动方式必须严谨。普通用户权限通常不够，至少需要本地管理员权限，部分场景下还建议使用 SYSTEM 权限控制台。

最基础的方式，是右键以管理员身份打开 CMD 或 PowerShell，然后进入 LiveKd 所在目录执行：

livekd.exe

如果目标环境权限比较严格，或者你需要更稳定地读取系统级对象，可以用 PsExec 拉起 SYSTEM 权限命令行：

psexec -s -i cmd.exe

然后在新弹出的 SYSTEM 命令行中运行：

livekd.exe

这里要注意，SYSTEM 权限不是为了“显得高级”，而是为了减少权限不足导致的采集失败。很多驱动、内核对象、系统线程、内核池信息，普通管理员权限也未必总能顺利读取。

第二个准备项是 WinDbg 或 KD。LiveKd 本身并不是完整的图形调试器，它更像是把当前系统伪装成一个可被调试器读取的目标，再把 WinDbg/KD 接上去。所以机器上最好提前准备好 Debugging Tools for Windows。

第三个准备项是符号。没有符号时，你看到的可能是一堆地址；有符号时，你才能看到函数名、结构体名、模块名和相对可读的调用栈。

推荐提前在运维分析机或标准工具目录中准备好 LiveKd、WinDbg、符号缓存路径，不要等事故发生后再临时拼环境。

如果你在正式生产系统上运行 LiveKd，请务必保留操作记录：谁运行、什么时候运行、为什么运行、导出了什么文件、文件保存在哪里。

这张流程图的重点不是复杂，而是提醒一个底线：LiveKd 不是第一反应工具，而是当普通工具看不到内核层问题时，用来向下穿透的一步。

3. LiveKd 的两种运行模式

现场使用 LiveKd 时，最重要的选择是：你要直接打开调试器当场看，还是只导出一个内核 Dump 带走分析。

下面这张图把两种模式做了清晰对比：左边是直接打开调试器，适合专家现场追问；右边是导出 Dump，适合一线先留证据、后续交接分析。

从图中可以看出，两种模式不是谁高级谁低级，而是使用目标不同。交互式调试适合现场有内核分析能力的人；导出 Dump 适合一线运维先固定证据，再交给内核、平台或厂商团队分析。

3.1 模式 A：直接打开调试器

如果你需要当场看内核结构、线程栈、内存池占用，可以让 LiveKd 直接打开 WinDbg 或 KD。

livekd.exe

部分环境下也可以使用带调试器模式的参数，例如：

livekd.exe -w

进入 WinDbg 后，你可以直接使用内核调试命令查看系统状态。这个模式的优势是可以连续追问：看到 Pool 异常，就继续查 Pool Tag；看到某个线程卡住，就继续查调用栈；看到某个驱动可疑，就继续查模块信息。

但缺点也明显：它要求操作者至少能看懂 WinDbg 的基本输出。否则你只是打开了一个非常强的窗口，却不知道该看哪里。

3.2 模式 B：只导出 Dump

如果你是一线运维或值班人员，我更推荐先使用导出 Dump 的方式。这样做更稳，也更符合企业应急流程。

livekd.exe -o C:\temp\live_snapshot.dmp

这个命令的意义是：把当前系统的内核状态保存成一个 Dump 文件，后续可以在分析机上用 WinDbg 打开。这样现场停留时间更短，风险更小，也更方便交接。

推荐一线优先策略：先 Dump 留证，再决定是否进行交互式分析。

不要在生产现场长时间乱敲不熟悉的内核调试命令。只读观察可以，修改内核状态、强行操作线程或对象非常危险。

4. WinDbg 里最值得先看的几类信息

当 LiveKd 成功接入 WinDbg 后，不建议上来就乱跑一堆命令。现场排查最怕“工具很强，思路很乱”。比较稳的做法是先看最关键的几类：进程、内存池、线程栈、I/O 请求和驱动模块。

下面这张图展示了 WinDbg 里最值得优先观察的几个方向。

从图中可以看出，LiveKd 接入 WinDbg 后，并不是只看一个指标，而是要把内核现场拆成几条主线。进程看全局对象，Pool 看内核内存，线程看卡顿，IRP 看 I/O 堆积，驱动模块看加载状态。

4.1 查看系统进程与线程

!process 0 1

这个命令用于查看系统中的进程对象和线程信息。它比任务管理器更底层，能帮助你确认是不是某个进程在内核层面还有异常残留。

典型用途是检查“幽灵进程”、异常长时间驻留的进程、或者某些用户态工具看不清楚的内核对象关联。

4.2 查看内核池使用情况

!poolused 2

这个命令在排查内核态内存泄漏时非常关键。很多时候系统内存狂掉，但任务管理器里所有用户态进程加起来都对不上，这时就要怀疑非分页池或分页池被驱动吃掉。

`!poolused 2` 可以按 Pool Tag 汇总内核内存使用情况。Pool Tag 往往能进一步映射到具体驱动或组件。

现场报告可以这样写：

当前系统用户态进程内存占用与总内存消耗不匹配。 LiveKd 采集后通过 !poolused 2 发现某 Pool Tag 占用异常增长， 初步判断问题在内核态驱动或过滤组件，而非业务进程本身。

4.3 查看线程栈和等待状态

!thread <ThreadAddress> kb

如果系统表现为顿卡、假死、I/O 长时间无响应，而 CPU 又不一定很高，可以重点看线程等待和调用栈。

`!thread` 能看线程对象状态，`kb` 能看调用栈。若调用栈长期卡在某个驱动函数、过滤回调或等待锁位置，就能形成比较有力的证据。

4.4 查看 I/O 请求堆积

!irpfind

这个命令适合磁盘、网络、驱动栈相关问题。如果大量 IRP 长时间未完成，说明问题可能在某个驱动层、过滤层或者设备栈中。

4.5 查看已加载驱动模块

lm t n

这个命令用于列出已加载模块。它适合检查是否存在陌生驱动、老版本驱动、异常安全组件、过滤驱动或第三方内核模块。

推荐现场只先跑最关键的三到五个命令，先拿证据，不要贪多。

如果你不确定某个 WinDbg 命令是否会修改状态，就不要在生产系统上执行。现场优先只读命令。

5. 现场采集 SOP：标准动作比临场猜测更重要

LiveKd 真正进入生产环境时，最重要的不是你记住多少命令，而是你有没有标准操作流程。没有 SOP 的内核工具使用，很容易变成“临场发挥”。这在高压现场非常危险。

下面这张图展示了一个推荐的现场采集流程：准备工位、先采 Dump、可选现场查看、打包证据、恢复现场。

从图中可以看出，标准动作的核心是“先留证据，再做分析”。Dump 是基本资产，WinDbg 输出是辅助证据，事件日志和机器信息是上下文，最后还要恢复现场。

5.1 步骤 0：准备工位

确认授权、磁盘空间、工具路径、管理员权限和输出目录。Dump 文件可能比较大，尤其是内核状态复杂或内存占用较高时，不要把文件直接扔到系统盘根目录。

建议提前创建目录：

mkdir C:\Temp\LiveKdEvidence

5.2 步骤 1：先采 Dump

这是现场最推荐的第一步。哪怕后面 WinDbg 打不开、符号没配好、现场时间不允许继续分析，你至少已经拿到了一个可以交付的内核现场快照。

livekd.exe -o C:\Temp\LiveKdEvidence\live_snapshot.dmp

建议文件名带上主机名和时间戳，例如：

livekd.exe -o C:\Temp\LiveKdEvidence\HOST01_20260520_1530_livekd.dmp

5.3 步骤 2：可选现场查看

如果现场时间允许，并且操作者能看懂基础 WinDbg 输出，可以启动交互式模式进行快速观察。

livekd.exe

进入 WinDbg 后优先跑以下命令：

!poolused 2 !process 0 1 lm t n

如果怀疑 I/O 卡死，再补：

!irpfind

如果已经定位到可疑线程，再看：

!thread <ThreadAddress> kb

5.4 步骤 3：打包证据

LiveKd 证据包不应该只有一个 dmp 文件。至少应包含 Dump、WinDbg 关键输出、系统版本、驱动列表、事件日志关键片段和操作记录。

可以配合 PsInfo、PsLogList 采集上下文：

psinfo -h -d > C:\Temp\LiveKdEvidence\system_info.txt psloglist -s -d 1 System > C:\Temp\LiveKdEvidence\system_event_1d.txt

如果要保证文件完整性，可以生成 Hash：

Get-FileHashC:\Temp\LiveKdEvidence\HOST01_20260520_1530_livekd.dmp-Algorithm SHA256|Out-FileC:\Temp\LiveKdEvidence\dump_sha256.txt

5.5 步骤 4：恢复现场

采集完成后关闭调试器窗口，确认没有遗留 SYSTEM 控制台，没有把 Dump 文件散落在不受控目录，没有留下临时工具和权限窗口。

推荐把 LiveKd 采集动作写进应急手册，形成固定模板，而不是每次靠个人经验。

不要采完 Dump 就忘了清理现场。Dump 可能包含敏感内存信息，必须按证据文件管理。

6. LiveKd 能解决哪些普通工具解决不了的问题

LiveKd 不应该替代任务管理器、Process Explorer、Procmon、VMMap、Handle 这些常规工具。它应该在普通工具已经无法解释问题时使用。

下面这张图总结了 LiveKd 的几个高价值场景：Nonpaged Pool 暴涨、系统顿卡但 CPU 不高、Hyper-V 宿主或来宾异常、不能重启但必须留证。

从图中可以看出，LiveKd 的定位不是日常巡检，而是系统级异常的深水区工具。它更适合回答“问题是不是在内核态、是不是某个驱动、是不是系统对象或内核池出了问题”。

6.1 Nonpaged Pool 暴涨

如果系统内存持续减少，但任务管理器里进程内存加起来对不上，这时候要怀疑内核态内存。常见原因包括驱动泄漏、过滤器异常、安全软件组件问题、存储或网络驱动缺陷。

这类问题用用户态工具很难直接看透，LiveKd 结合 `!poolused 2` 是非常关键的突破口。

6.2 系统顿卡但 CPU 不高

如果用户反馈系统卡顿、RDP 卡住、磁盘响应慢，但 CPU 并不高，普通工具往往会让人误判。真实原因可能是某个内核线程持锁、驱动回调阻塞、I/O 请求长期不返回。

这时需要看线程栈和 IRP 状态，而不是只盯 CPU 曲线。

6.3 Hyper-V 宿主 / 来宾异常

虚拟化环境的问题经常比较难分层。到底是宿主资源问题，还是来宾内部驱动、服务或过滤组件的问题？LiveKd 可以帮助我们从内核现场看线索，尤其适合虚拟机内部系统卡顿、I/O 异常和驱动冲突场景。

6.4 不能重启但必须留证

很多生产问题最麻烦的点不是不会查，而是不能重启。用户还在用，业务还在跑，现场稍纵即逝。LiveKd 的价值就是在这个窗口期先拿内核现场，让后续分析有材料。

LiveKd 最适合用于“普通工具解释不了，但又不能立刻重启”的疑难场景。

不要把 LiveKd 当成所有故障的第一工具。能用 Procmon、Process Explorer、VMMap、Handle 解决的问题，先用低风险工具解决。

7. 证据包应该怎么交付

LiveKd 采集出来的东西，如果只是扔一个 dmp 文件给别人，价值会打折。真正高质量的交付应该包括现场上下文、采集命令、关键输出和结论判断。

建议证据包目录结构如下：

LiveKdEvidence_HOST01_20260520/ ├─ HOST01_20260520_1530_livekd.dmp ├─ dump_sha256.txt ├─ windbg_key_output.txt ├─ system_info.txt ├─ system_event_1d.txt ├─ driver_list.txt └─ readme_analysis_note.txt

其中 `readme_analysis_note.txt` 可以写成这种格式：

【采集时间】 2026-05-20 15:30 【采集原因】 系统出现间歇性卡顿，用户态进程 CPU 和内存未发现明显异常， 怀疑内核态驱动或内核池异常。 【采集方式】 使用 LiveKd 导出内核现场 Dump： livekd.exe -o C:\Temp\LiveKdEvidence\HOST01_20260520_1530_livekd.dmp 【初步观察】 已采集 !poolused 2、!process 0 1、lm t n 输出。 后续建议重点查看 Nonpaged Pool、可疑第三方驱动模块和线程等待状态。 【注意事项】 Dump 文件可能包含敏感内存信息，仅限授权人员分析。

这个说明文件很重要。没有说明的 Dump，只是一坨二进制文件；有说明的 Dump，才是可复盘的证据。

推荐每次 LiveKd 采集都形成“Dump + Hash + 关键输出 + 说明文件”的四件套。

Dump 不要随意通过普通聊天工具外传，更不要上传到公开平台。它可能包含系统级敏感信息。

8. 小结：LiveKd 是线上内核态黑匣子采集器

这一篇我们把 LiveKd 从概念拉到了实战：如何启动、如何选择运行模式、WinDbg 里先看什么、现场如何采集、证据如何打包。

最关键的判断是：**LiveKd 不是日常工具，而是系统级疑难问题的内核态取证工具。**当普通工具只能告诉你“现象”，LiveKd 可以帮你往下看到“内核层面的状态”。

这篇可以压缩成几个结论：

第一，LiveKd 必须在高权限环境下使用，最好提前准备 WinDbg、符号路径和标准输出目录。

第二，一线现场优先导出 Dump，先留证据，再决定是否交互式分析。

第三，WinDbg 中优先看 `!poolused 2`、`!process 0 1`、`lm t n`，必要时再看线程栈和 IRP。

第四，LiveKd 特别适合处理 Nonpaged Pool 暴涨、系统顿卡但 CPU 不高、Hyper-V 异常、不能重启但必须留证的场景。

成熟的现场排障，不是工具越多越好，而是知道什么时候该用哪把刀。

如果你没有授权、没有空间、没有证据管理方式、没有分析能力，就不要贸然在生产环境运行 LiveKd。

把 LiveKd 用好，你就不再只能说“系统好像卡了、可能是驱动问题”。你可以拿出 Dump、Pool 证据、线程栈、驱动列表和事件日志，把问题从猜测推进到可分析、可交接、可复盘的状态。

🔝 返回顶部

点击回到顶部