perfview 默认不显示 FileStream 读写因未启用 kernel-io 提供器；需手动开启 fileio/diskio 事件，并配置 verbose clr 日志、线程池事件及符号调试，才能准确定位磁盘卡顿与 io 失真。
PerfView 捕获文件 IO 事件时为什么看不到 FileStream 读写？
因为默认 ETW 会话不开启 .NET 的 microsoft-windows-DotNETRuntime 提供器，更关键的是——文件 IO 的底层事件（如 FileIO/Read、FileIO/Write）来自 Windows 内核的 Microsoft-Windows-Kernel-IO，它默认被 PerfView 屏蔽了。
实操建议：
- 启动 PerfView 时加参数：
PerfView64.exe /KernelEvents:FileIO+DiskIO+Process+Thread+ImageLoad - 或在 PerfView GUI 中点击「Collect」→ 勾选「Kernel Events」→ 手动展开并勾选
FileIO和DiskIO - 避免只开
DotNETRuntime：它只能看到FileStream.Read这类托管调用栈，看不到磁盘实际排队、延迟、重试等瓶颈
C# 程序中哪些 IO 模式会让 ETW 文件事件“失真”？
ETW 的 FileIO 事件基于 IRP（I/O Request Packet）捕获，但某些路径会绕过它——不是代码写错了，是 Windows 自己优化掉了。
常见失真场景：
-
MemoryMappedFile：映射后读写走内存页错误处理，不会触发FileIO/Read事件，但会出现在PageFault或VirtualAlloc中 - 小文件 +
FileOptions.Asynchronous但未真正异步：如果线程池立刻完成（比如缓存命中），ETW 可能只记录FileIO/Read而无后续FileIO/ReadCompleted，时间戳看起来“零延迟” - 使用
Span<byte></byte>+FileStream.Read(Span<byte>)</byte>：.NET 6+ 会尝试零拷贝路径，部分情况下跳过内核 IO 跟踪点
如何从 PerfView 结果里快速定位真实磁盘卡顿？
别盯着「Hot Path」里最长的托管函数看——文件瓶颈往往藏在 FileIO/Read 和 DiskIO/Read 之间的延迟差里。
操作步骤：
- 在 PerfView「Events」视图中筛选
FileIO/Read→ 查看每条事件的Duration字段（单位 ns） - 再筛选
DiskIO/Read→ 对比同文件名、相近时间戳的Duration，若后者明显更大（比如 >10ms），说明是物理磁盘或存储驱动层拖慢 - 注意
FileIO/Read的Operation字段：值为0x0表示同步读，0x1表示异步；若大量0x0出现在高并发场景，说明没用对async/await或线程池被占满
ETW 分析时容易忽略的 .NET 特定陷阱
PerfView 解析 .NET 事件依赖 PDB 符号，但文件 IO 的关键上下文（比如哪个 FileStream 实例、路径字符串）默认不采集——得手动打开 GC 栈和字符串捕获。
必须做的配置：
- 收集时启用
/GCCollectOnly:true（避免 GC 干扰 IO 时间线）但同时加/ClrEventLevel:Verbose - 在
DotNETRuntime提供器中，务必勾选ThreadPoolWorkerThreadStart和ThreadPoolEnqueue：否则无法判断是 IO 等待还是线程饥饿 - 不要信任
FileName字段的完整性：ETW 默认只记录前 256 字节，长路径或 UNC 路径可能被截断，需结合FileIO/Read的FileObject地址 + 内存 dump 辅助确认
最麻烦的其实是符号加载——如果程序用了 AssemblyLoadContext.Unload 或 AOT 编译，PerfView 可能根本解析不出托管栈帧。这时候得回退到 Kernel-IO 层硬看，别指望 C# 方法名自动浮现。