Windows容器无法采集Microsoft-Windows-Winsock-AFD ETW事件

你碰到的问题不属于ETW基础功能不兼容，本质是Windows容器的ETW会话隔离机制限制：从v1803开始开放的容器ETW能力，默认仅支持采集容器内用户态程序上报的ETW事件，你尝试采集的Microsoft-Windows-Winsock-AFD、Microsoft-Windows-TCPIP、Microsoft-Kernel-Network均为内核态网络栈挂载的ETW提供程序，这类事件默认不会流入容器内部创建的ETW追踪会话。
你目前捕获到的两个GUID为{9e814aad-3204-11d2-9a82-006008a86939}的事件是ETW会话自身的配置元数据事件，仅能说明你在容器内创建ETW会话的操作成功，无法证明目标提供程序的事件被正常订阅。

• 先检查容器的必要权限：在容器内执行whoami /priv，查看SeSystemProfilePrivilege权限是否处于启用状态。采集内核态ETW事件必须持有该权限，而mcr.microsoft.com/windows/servercore:ltsc2019默认启动的普通容器，该权限默认是禁用甚至未分配的。
• 检查提供程序注册可见性：在容器内执行logman query providers，查看输出列表中是否存在Microsoft-Windows-Winsock-AFD的注册项。内核态ETW提供程序的注册信息默认存放在主机系统注册表中，不会映射到容器的隔离注册表视图，就算你成功创建了追踪会话，容器内的ETW子系统也无法识别对应提供程序的事件规则，自然不会捕获有效事件。
• 确认版本匹配问题：你当前使用的是Windows 11主机搭配ltsc2019容器镜像，二者内核版本跨度大，就算权限配置正确，内核ETW事件的schema结构不匹配也会导致事件无法被正常解析、投递。

• 主机侧全局采集+进程ID过滤（推荐，稳定性最高）：直接在Windows主机侧创建针对目标网络提供程序的ETW全局追踪会话，采集全量网络事件后，通过进程ID关联过滤出目标容器的事件即可。注意容器内的进程ID是虚拟ID，你可以通过docker inspect <容器ID>拿到容器进程在主机侧的真实PID，再关联该进程树下的所有网络事件，不需要修改容器任何配置。
• 特权模式启动容器做兼容测试：启动容器时添加--privileged参数，同时将主机的HKLM\SYSTEM\CurrentControlSet\Control\WMI注册表分支映射到容器内，让容器内的ETW子系统能识别内核态提供程序的注册信息。注意这种方案需要容器镜像的内核版本和主机内核版本完全一致，跨版本（比如Win11配ltsc2019）依然会存在事件投递异常问题，建议替换为和主机版本匹配的ltsc2022镜像测试。
• 替换采集链路：如果你的核心需求是检测容器内进程的外连行为，可以放弃内核态ETW采集方案，改用容器内挂载WFP轻量过滤驱动、Hook用户态Winsock调用的方式实现，兼容性更好，不需要依赖主机侧配置。

补充说明：PerfView文档中提到的Windows容器ETW支持，仅覆盖用户态应用、用户态系统服务上报的ETW事件，并未承诺支持内核态系统组件的ETW事件采集，这部分隔离规则目前没有公开的官方文档说明，属于容器安全隔离的默认限制。

内容的提问来源于stack exchange，提问作者Tan-Linh Ha