ETW 无法直接显示 FileStream 托管层读写耗时，因其默认不采集 .NET IO 细粒度事件；需启用 Microsoft-Windows-DotNETRuntime/IO 提供程序或使用 dotnet-trace 工具捕获完整调用链。
ETW 事件里看不到 FileStream 的实际读写耗时？
因为 ETW 默认不采集托管堆栈和 .NET IO 方法的细粒度事件，FileStream.Read 这类调用会被归入内核 ZwReadFile 或 NtWriteFile，但你看到的只是系统调用入口，不是托管层发起点。想关联到具体 C# 代码行，必须开启 .NET Runtime provider 并启用 Microsoft-Windows-DotNETRuntime/IO 事件（.NET 5+）或 Microsoft-Windows-DotNETRuntime/ThreadPool/IO（旧版）。
实操建议：
- 用
dotnet-trace比直接用logman更可靠：它自动启用必要 provider，并支持按关键词过滤 IO 相关事件 - 启动 trace 时加
--providers Microsoft-DotNETCore-EventPipe::0x1000000000000000:4（对应 IO 事件，Level=4 表示含详细参数） - 别依赖
Windows Kernel Trace\DiskIO，它只反映物理层延迟，和你的File.Copy是否用了缓冲区、是否异步无关
为什么 File.ReadAllBytes 在 ETW 里显示单次大 IO，而 FileStream 分成多段？
ETW 记录的是内核发起的 IRP 请求，不是托管 API 调用次数。File.ReadAllBytes 底层通常走 CreateFile + ReadFile 一次性提交，所以 ETW 中表现为一个长耗时的 IRP_MJ_READ；而 FileStream 默认缓冲区 4KB，每次 Read 触发一次内核请求（除非启用了 UseAsync=true 且底层支持），ETW 就会看到一串短 IO。
关键区别：
-
File.ReadAllBytes的“快”是假象——它把所有开销压进一次系统调用，但内存分配、GC 压力全在托管侧，ETW 不体现 -
FileStream的分段 IO 在 ETW 中更真实，但要注意：如果开了Buffered=false，你会看到更多小 IO 和更高内核态切换开销 - 对比性能不能只看 ETW 中的“IO 次数”，得结合
Microsoft-Windows-DotNETRuntime/GC事件看内存压力
用 PerfView 分析时，File.Copy 的堆栈总停在 ntdll.dll!NtWriteFile？
这是正常现象。.NET 的 File.Copy 在目标文件存在时默认走 CopyFileEx Win32 API，它内部由系统决定是否使用内存映射或直接内核拷贝，托管堆栈在进入 CopyFileEx 后就断了。你不会看到 File.Copy → FileStream.Write 这样的链路。
排查方向：
- 确认是否启用了
copyFlags参数里的COPY_FILE_NO_BUFFERING—— 它会让 ETW 显示更少但更大的 IO，但要求对齐 64KB，否则失败并回退 - 检查源文件是否被其他进程锁住：ETW 中会出现
STATUS_SHARING_VIOLATION错误码，但 PerfView 默认不显示错误码，需在 Events View 中右键列头添加ErrorCode - 避免用
File.Copy复制大文件到网络路径——ETW 会暴露大量STATUS_PENDING状态，说明 SMB 层在重试，这不是你代码的问题，但容易误判为 IO 卡顿
自定义 ETW provider 记录 FileStream 构造和 Dispose 时间点有用吗？
没用。ETW 是内核级事件通道，自定义 provider 无法安全捕获托管对象生命周期（比如 FileStream 析构可能发生在 GC 线程上，且无栈信息）。硬要打点，反而会拖慢 IO 路径，尤其在高并发文件写入场景下。
真正有效的做法：
- 用
EventSource打点，但只记录关键业务节点：比如 “开始写入配置文件”、“写入完成耗时 234ms”，不记录每行Write - 把
FileStream创建和Dispose时间差作为“句柄持有时间”，配合 ETW 中的FileCreate/FileClose事件交叉验证是否泄漏 - 注意：.NET 6+ 的
FileStream默认启用Async，但 ETW 中的AsyncIOStart事件只在BeginRead类方法触发，ReadAsync不发该事件——这是已知限制，别因此怀疑自己配置错了
ETW 文件 IO 分析最易忽略的一点：你看到的“慢 IO”，80% 情况下不是磁盘问题，而是文件被防病毒软件实时扫描、或 NTFS 加密/压缩属性导致额外 CPU 开销——这些在 ETW 中表现为 ZwWriteFile 返回慢，但没有对应事件告诉你“杀软正在读这个文件”。得靠 Process Monitor 配合过滤 FileSystem 类型操作来交叉确认。
