C#中ETW事件未出现在日志中的根本原因是provider注册、会话启用、事件筛选三者未严格对齐；常见漏点包括EventSource构造失败静默降级、provider名称大小写不匹配、未启用对应ETW会话或缺失内核转发配置。
直接说结论：C# 中 ETW 事件跟踪不是“开个开关就能看到所有代码行为”，它依赖 provider 注册、会话启用、事件筛选三者严格对齐；漏掉任一环，EventSource 写出的事件就根本不会落地到 .etl 文件里。
为什么 EventSource.Write 没有出现在 ETW 日志中
常见错误现象是：C# 代码调用了 log.Write("MyEvent")，但用 PerfView 或 WPA 打开 .etl 文件后完全搜不到该事件。
- 最常被忽略的是 provider 未注册成功——
EventSource构造函数抛异常或静态初始化失败时，Write调用会静默降级为 noop，不报错也不写事件 - 没启用对应 provider 的 ETW 会话：
logman start MySession -p "TraceLoggingProvider" -o trace.etl中的 provider 名必须与new EventSource("TraceLoggingProvider")完全一致（区分大小写） - Windows 默认禁用自定义 provider 的内核模式转发，需额外执行：
wevtutil im MyProvider.man（若有清单）或确保使用EventSource的 .NET 版本 ≥ 4.6.2（自动注册） - 调试时用
logman query providers确认 provider 是否在列表中；若显示 “Not Enabled”，说明会话未关联它
如何用 dotnet-trace 替代 logman 收集托管 ETW 事件
手动配 logman 容易漏掉 .NET Runtime provider，而 dotnet-trace 自动补全关键依赖，适合快速验证 C# 事件是否发出。
- 启动命令必须显式包含
--providers参数：dotnet-trace collect --providers Microsoft-DotNETCore-EventPipe::0x1000000000000000:4（0x1000000000000000是Microsoft-DotNETCore-EventPipe的固定 GUID，:4表示 Level=Verbose） - 如果只想收自定义
EventSource，加第二个 provider：--providers "TraceLoggingProvider":0x1000000000000000:4 -
dotnet-trace输出的是.nettrace，不是.etl；用PerfView Open直接打开即可，无需转换 - 注意：.NET 5+ 才支持
dotnet-trace的完整 provider 过滤；.NET Framework 项目只能用logman+PerfMonitor
ETW 事件里看不到 FileStream.Read 的托管堆栈怎么办
这是设计使然，不是配置错误。ETW 默认只记录内核态 IO 请求（如 ZwReadFile），FileStream.Read 属于托管层调用，不在默认采集范围。
- 想关联到 C# 行号，必须启用
Microsoft-Windows-DotNETRuntime/IOprovider（.NET 5+）或Microsoft-Windows-DotNETRuntime/ThreadPool/IO（.NET Framework） - 启用方式不是靠
EventSource，而是通过 ETW 会话控制：logman start IOTrace -p "Microsoft-Windows-DotNETRuntime/IO" -o io.etl - 即使启用了，也仅记录 IO 发起点（如
FileStream.Read入口），不记录后续 GC、内存拷贝等托管开销；要看完整链路，得结合Microsoft-Windows-DotNETRuntime/GC和ThreadPool事件交叉分析 - 别指望
File.ReadAllBytes在 ETW 中显示为多次调用——它底层调一次ReadFile，ETW 只记这一个长耗时 IRP，和你的缓冲区设置无关
真正容易被忽略的复杂点在于 provider 生命周期管理：EventSource 实例一旦构造失败，后续所有 Write 调用都无效，且无异常提示；而 provider 启用状态在进程重启后不会持久，每次都要重新 logman start。生产环境排查时，务必先确认 provider 是否处于 “Enabled” 状态，再查代码逻辑。
