c# ETW (Event Tracing for Windows) 和 .NET 事件探查并发问题

ETW采集.net并发事件时看不到ThreadPoolWorkerThreadStart等，因需显式启用0x800（ThreadPool）关键字；dotnet-dump与ETW交叉验证依赖时间戳对齐和线程ID关联；EventSource丢事件是因默认采样限流；ThreadPoolWorkerThreadStart的ManagedThreadId恒为0，需通过OSThreadId关联Thread/Start事件获取。

ETW 采集 .NET 并发事件时，为什么看不到 ThreadPoolWorkerThreadStart 或 ThreadPoolEnqueue？

因为这些事件默认被禁用——.NET 运行时（CoreCLR / .NET 5+）的 ETW provider（microsoft-windows-DotNETRuntime）需显式启用「ThreadPool」关键字（keyword），否则即使开启 EventSource 级别，线程池相关事件也不会发出。

实操建议：

• 使用 dotnet-trace 时加 --providers Microsoft-windows-DotNETRuntime:0x0000000000000800（十六进制 0x800 对应 ThreadPool 关键字）
• 用 logman 启动 ETW session 时，provider 配置中必须包含 keywords=0x800，例如：

  logman start mytrace -p "Microsoft-Windows-DotNETRuntime" "0x800" -o trace.etl -ets

• 在 C# 中用 EventListener 订阅时，重写 OnEventSourceCreated 并对 eventSource.Name == "Microsoft-Windows-DotNETRuntime" 调用 EnableEvents(eventSource, EventLevel.Verbose, (EventKeywords)0x800)

dotnet-dump 和 ETW 日志怎么交叉验证锁竞争？

ETW 提供时间线上的高密度事件（如 MonitorEnterStart/MonitorEnterStop、ThreadPoolWorkerThreadStart），但不记录托管堆对象地址；而 dotnet-dump 只能捕获某一时刻的快照。二者需靠「时间戳对齐 + 线程 ID 关联」来定位。

关键操作点：

• 采集 ETW 时务必启用 EventSource 的 timestamp 字段（默认开启），并用 perfview 或 TraceEvent 库解析出纳秒级时间戳
• 触发 dump 前，先在代码中插入 System.Diagnostics.Debug.WriteLine($"DUMP_POint: {DateTime.UtcNow:O} Thread={Thread.CurrentThread.ManagedThreadId}");，让日志与 dump 时间锚定
• 用 dotnet-dump analyze 查看 clrstack -all，比对线程 ID 和 ETW 中 ManagedThreadId 字段（注意：ETW 事件里的 ThreadId 是 OS 线程 ID，需通过 !threads 或 dumpheap -stat 中的线程对象反查对应关系）

为什么 EventSource 自定义事件在并发压测下丢失严重？

不是丢，是被限流了。.NET 的 EventSource 默认启用「采样丢弃（sampling discard）」机制：当事件速率超过阈值（约 10k/s），后续事件会被静默丢弃，且不报错。

缓解方式：

• 构造 EventSource 时传入 EventSourceSettings.EtwSelfDescribingEventformat 以外的选项（如 EventSourceSettings.None），但这会禁用 ETW 自描述格式，需手动维护 manifest
• 改用异步缓冲模式：在 WriteEvent 前先写入 ConcurrentQueue，再由独立线程批量调用 WriteEventCore，降低单次调用开销
• 生产环境慎用 EventLevel.LogAlways，优先用 EventLevel.Informational + 条件过滤（例如只在 Monitor.IsEntered(obj) 为 true 时才记录争用）

用 TraceEvent 库解析 ETW 时，ThreadPoolWorkerThreadStart 的 ManagedThreadId 字段总是 0？

这是 .NET Runtime provider 的已知行为：该事件在 CoreCLR 中不填充 ManagedThreadId 字段（仅填充 ClrInstanceID 和 OSThreadId）。你得靠 OSThreadId 关联 Windows ETW 的 ThreadID，再结合 ThreadStart 事件中的托管线程 ID 推断。

可行路径：

• 同时订阅 Microsoft-Windows-DotNETRuntime/Thread/Start（事件 ID 260）和 ThreadPoolWorkerThreadStart（事件 ID 290），两者共享同一 OSThreadId
• 在 Thread/Start 事件中提取 ManagedThreadId，缓存到 Dictionary（key = OSThreadId），后续遇到 ThreadPoolWorkerThreadStart 就查表
• 注意：此映射仅在该线程生命周期内有效；线程退出后需清理缓存，否则内存泄漏

实际排查并发瓶颈时，最易被忽略的是 ETW 事件的时间精度与 GC 暂停的干扰——比如 MonitorEnterStop 时间戳可能落在一次 GCStart 之后，导致你以为是锁等待，其实是 GC 抢占。务必打开 GC 关键字（0x1）并交叉比对。