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<t></t>，再由独立线程批量调用
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<int int></int>（key = OSThreadId），后续遇到
ThreadPoolWorkerThreadStart就查表 注意：此映射仅在该线程生命周期内有效；线程退出后需清理缓存，否则内存泄漏
实际排查并发瓶颈时，最易被忽略的是 ETW 事件的时间精度与 GC 暂停的干扰——比如
MonitorEnterStop时间戳可能落在一次
GCStart之后，导致你以为是锁等待，其实是 GC 抢占。务必打开
GC关键字（
0x1）并交叉比对。
