c#无法直接解析windows预读文件（.pf），因其为微软未公开的内核私有二进制格式，且win10 1809后引入加密校验和导致逆向工具失效；应改用etw监听microsoft-windows-kernel-image的imageload事件获取实时、稳定、精简的进程映像加载数据。
Windows .pf 文件不是标准可读格式，C# 无法直接解析
Windows 预读文件（ntosboot-*.pf、layout.ini 关联的 *.pf）是内核私有二进制格式，微软从未公开其结构。所有声称“解析 .pf”的开源工具（如 prefetch-parser）实际都是逆向工程产物，且版本兼容性极差——Win10 1809 之后的 .pf 加入了加密校验和字段，旧解析器会直接报错或返回乱码。
所以别在 C# 里写 BinaryReader 去硬啃 C:\Windows\Prefetch\*.pf，大概率读出一堆 0x00 或触发 EndOfStreamException。真要分析启动行为，得绕开 .pf 本身。
用 ETW 替代 .pf：C# 中监听进程映像加载最可靠
Windows 启动时的文件加载行为（DLL 加载、EXE 依赖、路径解析）全程由 ETW（Event Tracing for Windows）记录，比 .pf 更实时、更完整、且格式稳定。C# 可通过 Microsoft.Diagnostics.Tracing NuGet 包接入：
- 安装包：
Install-Package Microsoft.Diagnostics.Tracing - 关键事件提供者：
Microsoft-Windows-Kernel-Image（含ImageLoad事件） - 必须以管理员权限运行，否则收不到内核级事件
- 避免用
TraceEventSession开全局 session，优先用TraceLogSession指定 provider 过滤，减少性能抖动
示例片段（监听当前进程及其子进程的 DLL 加载）：
using (var session = new TraceEventSession("ImageLoadSession"))
{
session.Source.Kernel.TraceImageLoad += e =>
{
if (e.ProcessName == "yourapp.exe") {
Console.WriteLine($"{e.TimeStamp}: {e.ImageName} loaded at {e.ImageBase:x}");
}
};
session.Source.Process(); // 阻塞等待
}为什么不用 ProcessMonitor + 日志转 CSV？
很多人想用 ProcMon（Sysinternals）抓启动日志再导入 C# 分析，但这条路在自动化场景下极易翻车：
-
ProcMon的.PML是压缩二进制，没有官方 .NET 解析库；第三方解析器（如PmlNet）不维护多年，对 Win11 路径 Unicode 处理错误 - 启动阶段大量短生命周期进程（如
svchost.exe子实例）会导致ProcMon日志爆炸式增长，单次启动轻松超 50MB，C#StreamReader逐行读 CSV 会卡死 -
ProcMon默认捕获所有操作（RegKey、FileIO），但你要的只是“哪个 DLL 被哪个进程在何时加载”，ETW 的ImageLoad事件字段精简、无冗余
如果非要用外部工具，建议改用 logman start + Kernel-Image provider 导出 .etl，再用 TraceEvent 读取——这才是和 C# 生态对齐的路径。
调试时容易漏掉的关键点
即使 ETW 方案跑通，仍有三个地方常被忽略，导致“明明启动了程序却没收到事件”：
- 目标进程必须在 ETW session 启动之后才创建；若想捕获系统启动全过程，需把监听逻辑做成 Windows Service 并设为
Automatic (Delayed Start) -
ImageLoad事件中e.ImageName是文件名（如kernel32.dll），不含路径；完整路径得查e.ProcessID对应的Process.StartInfo.FileName或用QueryFullProcessImageNameAPI 补全 - 某些 DLL（如
msvcrt.dll）由 loader 直接映射，不触发ImageLoad；此时需同时监听Microsoft-Windows-Kernel-Memory的PageFault事件交叉验证
预读文件本身只是 Windows 优化策略的副产品，真正影响启动速度的是映像加载链路。盯住 ETW 里的 ImageLoad 时间戳和调用栈，比反编译 .pf 实用得多。
