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）并交叉比对。
