个人主页杨利杰YJlio❄️个人专栏《Sysinternals实战教程》 《Windows PowerShell 实战》 《WINDOWS教程》 《IOS教程》《微信助手》 《锤子助手》 《Python》 《Kali Linux》《那些年未解决的Windows疑难杂症》让复杂的事情更简单让重复的工作自动化进程和诊断工具学习笔记8.17LiveKd 实战——运行方式、常用参数、现场采集套路1. 为什么这一篇要讲 LiveKd 实战2. 启动 LiveKd 前的基本操作习惯3. LiveKd 的两种运行模式3.1 模式 A直接打开调试器3.2 模式 B只导出 Dump4. WinDbg 里最值得先看的几类信息4.1 查看系统进程与线程4.2 查看内核池使用情况4.3 查看线程栈和等待状态4.4 查看 I/O 请求堆积4.5 查看已加载驱动模块5. 现场采集 SOP标准动作比临场猜测更重要5.1 步骤 0准备工位5.2 步骤 1先采 Dump5.3 步骤 2可选现场查看5.4 步骤 3打包证据5.5 步骤 4恢复现场6. LiveKd 能解决哪些普通工具解决不了的问题6.1 Nonpaged Pool 暴涨6.2 系统顿卡但 CPU 不高6.3 Hyper-V 宿主 / 来宾异常6.4 不能重启但必须留证7. 证据包应该怎么交付8. 小结LiveKd 是线上内核态黑匣子采集器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请务必保留操作记录谁运行、什么时候运行、为什么运行、导出了什么文件、文件保存在哪里。否是发现系统级异常是否已授权先走应急/变更审批管理员或 SYSTEM 控制台确认 WinDbg/KD 可用确认符号路径可用运行 LiveKd选择模式交互式 WinDbg 分析导出内核 Dump 留证这张流程图的重点不是复杂而是提醒一个底线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\LiveKdEvidence5.2 步骤 1先采 Dump这是现场最推荐的第一步。哪怕后面 WinDbg 打不开、符号没配好、现场时间不允许继续分析你至少已经拿到了一个可以交付的内核现场快照。livekd.exe -o C:\Temp\LiveKdEvidence\live_snapshot.dmp建议文件名带上主机名和时间戳例如livekd.exe -o C:\Temp\LiveKdEvidence\HOST01_20260520_1530_livekd.dmp5.3 步骤 2可选现场查看如果现场时间允许并且操作者能看懂基础 WinDbg 输出可以启动交互式模式进行快速观察。livekd.exe进入 WinDbg 后优先跑以下命令!poolused 2 !process 0 1 lm t n如果怀疑 I/O 卡死再补!irpfind如果已经定位到可疑线程再看!thread ThreadAddress kb5.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如果要保证文件完整性可以生成 HashGet-FileHashC:\Temp\LiveKdEvidence\HOST01_20260520_1530_livekd.dmp-Algorithm SHA256|Out-FileC:\Temp\LiveKdEvidence\dump_sha256.txt5.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 证据、线程栈、驱动列表和事件日志把问题从猜测推进到可分析、可交接、可复盘的状态。 返回顶部点击回到顶部