Windows Internals 10.5：Event Tracing for Windows（ETW）——Windows 高性能事件追踪框架到底怎么用？

个人主页杨利杰YJlio❄️个人专栏《Sysinternals实战教程》 《Windows PowerShell 实战》 《WINDOWS教程》 《IOS教程》《微信助手》 《锤子助手》 《Python》 《Kali Linux》《那些年未解决的Windows疑难杂症》让复杂的事情更简单让重复的工作自动化Windows Internals 10.5Event Tracing for WindowsETW——Windows 高性能事件追踪框架到底怎么用1、Windows Internals 10.5Event Tracing for WindowsETW——Windows 高性能事件追踪框架到底怎么用2、我先给出一句话结论ETW 是 Windows 排障的“底层时间线”3、ETW 的完整事件流从事件产生到分析输出3.1 Provider事件提供者3.2 Controller控制器3.3 Trace Session追踪会话3.4 Buffer缓冲区3.5 Consumer事件消费者4、ETW 的核心组成与关键元数据为什么它比普通日志更适合排障4.1 为什么时间戳非常关键4.2 Activity ID 为什么重要5、ETW 能解决什么问题从桌面运维角度看最有价值的 5 类场景5.1 性能分析CPU、磁盘、内存、I/O 到底卡在哪里5.2 启动与关机追踪到底慢在哪个阶段5.3 驱动与内核问题定位蓝屏前发生了什么5.4 应用卡顿与假死分析不是崩溃也能查5.5 网络与系统行为追踪6、ETW 抓取与分析的标准流程别一上来就乱抓7、常用 ETW 工具与命令示例7.1 查看当前正在运行的 ETW 会话7.2 查看可用 Provider7.3 创建一个简单的 ETW 采集会话7.4 使用 WPR/WPA 做性能分析8、ETW 与事件查看器、ProcMon、性能监视器的区别9、企业桌面运维中的 ETW 使用建议9.1 哪些问题值得上 ETW9.2 ETW 采集前要先问 5 个问题9.3 建议沉淀的 SOP10、我给自己的自测题确认是否真正理解 ETW11、总结ETW 是把 Windows 问题从“感觉流”拉回“证据流”的关键工具1、Windows Internals 10.5Event Tracing for WindowsETW——Windows 高性能事件追踪框架到底怎么用读到Windows Internals 10.5 Event Tracing for WindowsETW这一节时我最大的感受是ETW 不是普通意义上的“日志功能”而是 Windows 平台内置的一套高性能、低开销、可结构化分析的事件追踪基础设施。如果说事件查看器更像“系统已经写好的日记本”那么ETW 更像一套正在运行的高速监控管道系统组件、驱动、服务、应用程序都可以把关键事件写进去然后由消费者实时读取或者保存成.etl文件后续再用 WPA、PerfView、xperf、tracerpt 等工具做深度分析。这张图适合作为整篇文章的总览图它把Provider、Controller、Session、Buffer、Consumer、ETL 文件这些核心对象串在了一起。理解 ETW关键不是先背命令而是先搞清楚这条事件数据流到底怎么走。我把 ETW 理解为Windows 内核和应用程序共同使用的一条“高性能事件高速公路”。事件不是随便写出来的文本而是带有时间、级别、关键字、任务、进程、线程等元数据的结构化记录。2、我先给出一句话结论ETW 是 Windows 排障的“底层时间线”ETW 的核心价值不是告诉我们“系统出错了”而是帮助我们还原“系统在某个时间点到底做了什么”。在企业桌面运维和 Windows Internals 学习中ETW 特别适合解决这类问题系统启动慢、登录慢、关机慢但普通日志看不出根因CPU、磁盘、内存、网络某一段时间异常飙高应用程序卡顿、假死、无响应但进程并没有直接崩溃驱动、服务、内核组件存在延迟、阻塞或异常调用需要把多个事件按时间线串起来判断真正的第一个异常点。注意ETW 不是“万能结论生成器”。它不会自动告诉你根因是什么它只是把更底层、更连续、更结构化的证据交给你。真正的分析能力来自三件事知道该采集哪些 Provider知道如何控制采集范围避免噪声过多知道如何把时间线、进程、线程、调用栈和资源占用关联起来。3、ETW 的完整事件流从事件产生到分析输出理解 ETW最重要的是先把它看成一条完整的数据流水线而不是一个孤立工具。从图中可以看到ETW 的事件流大致可以拆成 6 个环节系统组件/应用/驱动产生事件Provider 写入事件Trace Session 管理采集Buffer 暂存事件数据输出方式实时 Consumer 分析写入 ETL 文件实时监控/告警/诊断WPA/PerfView/xperf 离线分析3.1 Provider事件提供者Provider 是事件的来源。它可以是Windows 内核组件系统服务设备驱动应用程序.NET、IIS、SQL Server 等框架或平台组件自定义业务程序。Provider 负责把“发生了什么”写成 ETW 事件。例如磁盘 I/O、线程调度、网络连接、服务启动、应用异常、GC 行为等。排障时选对 Provider就相当于选对观察窗口。3.2 Controller控制器Controller 负责创建、启动、停止和配置 Trace Session。常见控制方式包括logmanxperfwprWindows 性能记录器图形界面自定义 ETW 控制程序它决定采集哪些 Provider、采集哪些级别、是否按关键字过滤、Buffer 多大、输出到哪里。3.3 Trace Session追踪会话Trace Session 是 ETW 采集的运行容器。可以把它理解成一次“录像任务”什么时候开始录录哪些对象录多长时间录到内存还是文件是否实时消费是否循环写入。3.4 Buffer缓冲区Buffer 是 ETW 高性能的关键之一。事件不是每产生一条就立刻落盘而是先进入内存缓冲区再根据策略被实时消费或写入.etl文件。这也是 ETW 能够支持高频事件采集的重要原因它尽量减少了事件写入对系统运行本身的影响。3.5 Consumer事件消费者Consumer 负责读取事件并处理它们。它可以实时消费也可以离线分析 ETL 文件。常见工具包括Windows Performance AnalyzerWPAPerfViewtracerptTraceView自定义分析程序4、ETW 的核心组成与关键元数据为什么它比普通日志更适合排障普通日志经常是“人能读懂的文本”而 ETW 更像是“机器能高效分析的结构化事件”。这也是它在性能分析、系统启动分析、驱动问题定位中非常重要的原因。一条 ETW 事件通常不只是包含一句描述而是携带大量元数据。元数据作用排障价值Event ID标识事件类型判断发生了什么事件Level表示严重程度区分信息、警告、错误、关键事件Keyword事件分类过滤按网络、磁盘、I/O 等主题筛选Task逻辑任务分类判断事件属于哪个功能流程Opcode操作类型区分 Start、Stop、Info 等阶段Timestamp时间戳还原事件发生顺序PID进程 ID定位哪个进程触发事件TID线程 ID定位哪个线程参与执行Activity ID活动 ID串联跨进程/跨线程操作链路4.1 为什么时间戳非常关键在 Windows 排障中很多人容易犯一个错误看到最后一个报错就以为它是根因。但实际排障中最后一个错误往往只是结果第一个异常点才更接近根因。ETW 的价值就在于它能帮助我们按时间顺序追踪事件链路用户感觉卡顿应用线程等待磁盘 I/O 延迟升高某驱动响应变慢系统表现为应用无响应如果只看现象用户会说“软件卡死了”如果看 ETW 时间线可能发现真正的异常点在磁盘、驱动或内核调度层。排障时不要只盯着最终报错要向前回溯时间线找最早出现的异常信号。4.2 Activity ID 为什么重要Activity ID 可以把一个逻辑操作串起来。比如一次用户登录、一次网络请求、一次服务启动可能涉及多个线程甚至多个进程。如果没有 Activity ID分析时只能看到碎片化事件有了 Activity ID就更容易把它们拼成一条链路。这就是 ETW 在复杂系统中强大的地方它不仅记录“点”还帮助我们还原“线”。5、ETW 能解决什么问题从桌面运维角度看最有价值的 5 类场景对于企业桌面支持工程师来说ETW 最有价值的地方不是“概念高级”而是它能把很多模糊问题变成可分析的证据链。5.1 性能分析CPU、磁盘、内存、I/O 到底卡在哪里典型问题用户反馈电脑突然卡顿任务管理器只能看到 CPU 高但不知道谁在触发磁盘占用高但无法判断是文件扫描、更新、索引还是第三方软件。ETW 可以帮助我们把资源占用和具体事件关联起来哪个进程在高频读写磁盘哪个线程消耗 CPU哪些调用栈耗时异常是否存在大量上下文切换是否存在驱动层 DPC/ISR 延迟。在性能问题中ETW 的重点不是看“平均值”而是看“时间线上的突刺”和“突刺发生时谁在执行”。5.2 启动与关机追踪到底慢在哪个阶段启动慢、登录慢、关机慢是桌面运维高频问题。ETW 可以把启动流程拆成更细的阶段固件/BIOS 阶段内核初始化阶段驱动加载阶段服务启动阶段用户登录阶段Explorer Shell 初始化阶段。这样就能避免一句“系统慢”带来的模糊判断。5.3 驱动与内核问题定位蓝屏前发生了什么蓝屏分析通常依赖 Dump但 ETW 可以补充 Dump 之前的行为上下文。例如某驱动加载后系统延迟升高DPC/ISR 时间异常某类硬件中断频繁网络或存储驱动出现异常等待。Dump 负责告诉我们“崩在哪里”ETW 更擅长补充“崩之前系统经历了什么”。5.4 应用卡顿与假死分析不是崩溃也能查很多应用问题不会直接生成崩溃日志而是表现为界面无响应点击后长时间等待某个操作一直转圈后台线程等待资源释放。这类问题用 ETW 可以分析UI 线程是否阻塞是否存在长时间同步等待是否有文件锁、网络等待、GC 暂停是否存在锁竞争或线程池耗尽。5.5 网络与系统行为追踪在安全排查或系统行为分析中ETW 也可以提供关键证据哪个进程建立了网络连接DNS 查询是否异常TCP/UDP 行为是否频繁文件、注册表、服务行为是否和网络行为存在时间关联。6、ETW 抓取与分析的标准流程别一上来就乱抓ETW 很强但也很容易被误用。最大的问题是采集范围太大最后生成一堆看不懂的事件。正确方式应该是先明确问题再选择 Provider再控制采集窗口。我建议把 ETW 分析流程固定成 6 步明确问题现象卡顿、启动慢、蓝屏、网络异常先说清楚选择合适 Provider系统、应用、驱动、网络、磁盘按场景选择创建 Trace Session用 logman、wpr、xperf 等工具配置采集抓取 ETL 日志尽量复现问题控制采集时间使用 WPA/PerfView 分析看时间线、调用栈、CPU、I/O、线程、网络输出结论和优化建议把证据链写进工单或 SOP。明确问题现象判断影响范围选择 Provider创建 Trace Session复现问题并抓取 ETLWPA/PerfView 分析形成证据链输出修复方案与验证结果不建议长时间无目标全量抓取 ETW。这样既可能影响性能也会让后续分析变成“大海捞针”。推荐做法是先用最小采集范围复现问题再根据初步结果扩大采集范围。7、常用 ETW 工具与命令示例ETW 不是只能通过图形界面使用。很多情况下命令行工具更适合标准化、自动化和远程排障。7.1 查看当前正在运行的 ETW 会话logman query-ets这个命令可以查看当前系统中正在运行的 ETW Trace Session。适用场景判断系统是否已有正在采集的会话避免重复采集排查某些安全软件或监控组件是否正在注册 ETW 会话。7.2 查看可用 Providerlogman query providers如果输出内容非常多可以配合关键字过滤logman query providers|findstr/iKernel Disk Network WMI7.3 创建一个简单的 ETW 采集会话下面命令只是演示思路实际排障时应按问题类型选择对应 Provider。# 创建 ETW 采集会话输出到 C:\Temp\Trace.etllogman create trace YJlio_ETW_Test-o C:\Temp\Trace.etl-ets# 停止并保存采集会话logman stop YJlio_ETW_Test-ets这里的重点不是让大家死记命令而是理解logman 可以作为 ETW 会话的控制器用于创建、启动、停止和查询 Trace Session。7.4 使用 WPR/WPA 做性能分析在性能分析场景中更常见的组合是WPR 负责采集 WPA 负责分析推荐思路用 WPR 选择 CPU、Disk I/O、File I/O、Networking、Boot 等场景复现问题保存.etl文件用 WPA 打开按时间线和资源维度分析。8、ETW 与事件查看器、ProcMon、性能监视器的区别很多初学者会把 ETW、事件查看器、ProcMon、性能监视器混在一起。它们确实都能“看系统”但观察角度不同。工具/机制主要观察对象适合场景特点事件查看器系统/应用/安全日志已记录事件查询易读但不一定连续ETW高性能结构化事件流性能、启动、内核、驱动、应用追踪低开销、时间线强、可深度分析ProcMon文件/注册表/进程/网络实时行为访问拒绝、文件锁、注册表异常操作级细节强噪声也大性能监视器性能计数器长期性能趋势监控适合看指标不适合还原完整事件链WPA/PerfViewETL 分析CPU、I/O、调用栈、GC、启动性能深度分析能力强我的理解是事件查看器看系统已经写好的“重点摘要”ProcMon看操作级别的“实时行为记录”性能监视器看指标变化趋势ETW WPA/PerfView看系统级时间线和结构化证据链。现场排障时建议先用轻量工具缩小范围再用 ETW 做深度证据链分析。9、企业桌面运维中的 ETW 使用建议在企业一线桌面支持场景中ETW 不一定每天都用但它非常适合沉淀为高级排障能力。9.1 哪些问题值得上 ETW我建议满足以下任一条件时就可以考虑 ETW问题可复现但普通日志无法解释用户反馈“卡、慢、假死”但任务管理器信息不够问题涉及启动、登录、关机、驱动、网络、应用响应需要给上级、厂商或研发提供证据需要形成标准化排障报告而不是只说“重装后好了”。9.2 ETW 采集前要先问 5 个问题问题是稳定复现还是随机出现问题发生在哪个时间段影响单台机器还是多台机器是否和更新、驱动、软件安装、策略变更有关采集后准备看什么指标或事件如果这 5 个问题都答不上来直接抓 ETW 很容易变成无效采集。9.3 建议沉淀的 SOP可以把 ETW 沉淀成以下几类 SOPWindows 启动慢 ETW 采集 SOP用户登录慢 ETW 采集 SOP应用卡顿/假死 ETW 采集 SOPCPU/磁盘异常 ETW 采集 SOP驱动延迟/DPC 问题 ETW 采集 SOPETL 文件交付厂商分析标准模板。10、我给自己的自测题确认是否真正理解 ETW读完这一节后我给自己留了几个问题用来判断自己是不是只记住了 ETW 这个名字而是真正理解它的机制。ETW 和事件查看器最大的区别是什么为什么 ETW 要设计 Provider、Session、Buffer、Consumer 这些对象.etl文件为什么适合做离线分析为什么性能问题不能只看最终报错而要回到时间线找第一个异常点Provider、Keyword、Level、PID、TID、Activity ID 分别在排障中起什么作用如果用户反馈“开机慢”你会先采集哪些 ETW 维度如果某应用无响应但没有崩溃ETW 能提供哪些补充证据如果能用自己的话把这些问题讲清楚说明你已经不是“知道 ETW 这个词”而是开始理解 ETW 的排障价值了。11、总结ETW 是把 Windows 问题从“感觉流”拉回“证据流”的关键工具这一节我的核心收获可以压缩成一句话ETW 是 Windows 平台提供的高性能事件追踪基础设施它通过 Provider、Trace Session、Buffer、Consumer 和 ETL 文件把系统行为记录成可分析的结构化时间线。对于桌面运维和 Windows Internals 学习来说ETW 的价值主要体现在三点它能把“卡、慢、假死、启动慢”这类模糊问题转化为可分析的事件链它能帮助我们找到第一个异常点而不是被最后一个报错误导它能配合 WPA、PerfView、xperf、logman 等工具形成可复盘的证据链。不要把 ETW 当成普通日志也不要把 ETW 当成自动诊断神器。它真正的定位是为高级排障提供系统级、结构化、低开销的观察能力。后续如果继续学习10.6 WNFWindows Notification Facility我会把它和 ETW 做一个对比ETW 更偏“事件追踪与分析”WNF 更偏“系统状态变化通知与订阅”。这两个机制放在一起理解会更容易看清 Windows 内部的事件驱动设计。 返回顶部点击回到顶部