LiveKernelDump 是 Windows 基于 ETW 事件流与压缩内存页的混合内核内存镜像，C# 无法直接解析因其格式不被 MiniDumpReadDumpStream、ClrMD 等支持，且头部含 ETL 元数据、页块经 LZ77 压缩；唯一可靠方式是通过 C# 调用 WinDbg Preview（dbgx.exe）命令行间接分析。
LiveKernelDump 是什么，为什么 C# 不能直接读
LiveKernelDump 文件（MEMORY.DMP 或 kernel.dmp）是 Windows 内核实时捕获的内存镜像，格式不是标准的 minidump 或 full dump，而是基于 ETW 事件流 + 压缩内存页的混合结构。C# 的 MiniDumpReadDumpStream、DbgHelp.dll 或 Microsoft.Diagnostics.Runtime（即 ClrMD）**完全不支持解析 LiveKernelDump**——它们只认用户态 minidump 或传统内核转储（KernelDump 类型）。试图用 File.ReadAllBytes 加载后硬解析，会立刻遇到未知签名、加密页头或 LZ77 压缩块，报错如 Invalid image format 或直接抛 AccessViolationException。
- LiveKernelDump 实际由
etwtrace引擎生成，头部含ETL元数据，内存页按PageList索引压缩存储 - 微软官方唯一支持工具是
WinDbg Preview（依赖dbghelp.dll10.0.26100+）和kd.exe，底层调用的是私有驱动级解析器 - C# 没有公开 API 能绕过这个限制；强行 P/Invoke
dbghelp.dll中未文档化函数风险极高，且新版 Windows 已移除部分导出符号
用 C# 调用 WinDbg 命令行做间接分析
可行路径是让 C# 启动 WinDbg Preview 的命令行模式（dbgx.exe），把分析逻辑交给它，再解析输出结果。这不是“纯 C# 解析”，但能实现在 C# 流程中自动化提取关键信息（如蓝屏代码、驱动栈、内存使用峰值）。
- 确保已安装
WinDbg Preview（Microsoft Store 版），路径通常为C:\Program Files\WindowsApps\Microsoft.WinDbg_*，需用where dbgx.exe找到真实位置 - 执行命令示例：
dbgx.exe -z "C:\path\to\LiveKernelDump.dmp" -c "!analyze -v; !vm; q" -lines，其中-c后是调试命令，-lines避免 ANSI 转义干扰文本解析 - 在 C# 中用
Process.Start启动，重定向StandardOutput，注意设置UseShellExecute = false和足够长的WaitForExit(60000)——LiveKernelDump 解析可能耗时 10–40 秒 - 输出里关键字段如
*** STOP: 0x0000003B、MODULE_NAME: dxgkrnl、IMAGE_NAME: dxgkrnl.sys可用正则提取，别依赖固定行号
从 ETL 视角提取原始事件（仅限部分场景）
如果 LiveKernelDump 是由 logman start + NT Kernel Logger 触发的（常见于性能诊断而非蓝屏），它本质是带内存页的增强型 ETL。此时可尝试用 C# 读取其 ETL 部分，跳过压缩内存区。
- 用
Microsoft.Diagnostics.Tracing.TraceEventNuGet 包加载文件：TraceLog.Create("dump.etl")—— 注意：LiveKernelDump 文件扩展名常为.dmp，但内部可能是 ETL 格式，需先用file命令或十六进制查看前 8 字节是否为434C4346（CLCF，ETL 签名） - 若确认是 ETL，可用
TraceEventSession.Source.Process()订阅KernelTraceEventParser事件，例如过滤PageFault、DiskIo、NetworkIp等，但**无法拿到任意进程的堆栈或物理内存内容** - 失败表现：打开时报
Invalid ETW trace header，说明该 dump 是纯内核镜像（非 ETL 混合），此路不通
真正想做内存对象遍历？放弃 C#，换语言或工具链
如果你的目标是类似 Windbg 中 !poolfind、!object、dt nt!_EPROCESS 这类深度内核对象分析，C# 在当前生态下没有稳定方案。ClRMD 不支持内核空间，DbgEng.dll 的托管封装（如 Microsoft.DbgEng）仅限 .NET 6+，且要求目标机器装对应版本 WinDbg，并存在符号路径、权限、架构匹配（x64 dump 必须用 x64 进程调用）等硬约束。
- 最现实的做法：用 C# 写调度器，调用
kd.exe -z dump.dmp -c "!process 0 0; !drvobj dxgkrnl; q"，把结果喂给正则或简单状态机解析 - 若必须嵌入分析逻辑，改用 Rust +
winapi调用DbgEng原生接口，或 Python +pykd（需安装完整 WinDbg） - 容易被忽略的一点：LiveKernelDump 默认不包含符号，
!analyze -v输出里的模块名常是UNKNOWN，必须手动设置.sympath srv*c:\symbols*https://msdl.microsoft.com/download/symbols并重跑
