原文链接
作者:Microsoft
译者:塔塔塔塔塔
这里概述了Microsoft在Event发生的开端到终端过程中提供的四种跟踪技术:TraceLogging,Manifest-based,WPP 和 MOF 。它解决了单个 Event 的有效负载和描述其结构体( Structure )的随附元数据,从而可以将 Event 解析为有意义的数据。当在选择适合项目的跟踪技术时,了解每个Event的过程是重要的。没有一种跟踪技术可以解决所有方案。
对于任何微软提供的跟踪技术,调用写命令(例如 基于清单的 EventWrite 或 用于 TraceLogging 的 TraceLoggingWrite),提供了一种用于将运行时的 Event 数据被合并成一个连续的二进制大型对象(binary blob) 称为Event有效载荷。这个与事件模式或事件元数据(下面讨论)是分开的,事件模式或事件元数据描述了用于解码工具的此二进制大型对象(binary blob) 的布局。究竟如何生成使 Event 发生的有效负载取决于所使用的跟踪技术,并最终取决于事件是经典(TraceEvent 风格)还是现代(EventWrite 风格)。
对于经典事件,将 EVENT_TRACE_HEADER 中的标志传递到 TraceEvent 中,该事件确定如何发生:
-如果 WNODE_FLAG_USE_MOF_PTR 被指定时,一个 MOF_FIELDS 数组参考在内存中的 EVENT_TRACE_HEADER 。ETW 运行时将按照这些字段中指定的方式连接 Event 数据,以形成 Event 有效负载。
-如果未指定 WNODE_FLAG_USE_MOF_PTR ,则Event有效负载由用户参考EVENT_TRACE_HEADER直接在内存中构造。
MOF和WPP都是经典的 Provider 。但WPP实施会为您解决所有这些问题。
对于非经典Event,将许多EVENT_DATA_DESCRIPTORS传递给 EventWrite 。ETW运行时将按照这些描述符中指定的方式连接Event数据,以形成 Event 有效负载。
Manifest-base 技术和 TraceLogging 技术通常都是现代的 Provider 。基于清单的情况下,如果让 mc.exe 为您生成(um or km switch)的日志记录代码时,有效载荷的生成将由您来处理。TraceLogging 的有效负载的生成始终由TraceLogging 处理。
最终结果是在运行时生成事件的有效负载。所有有效负载在本质上都是相似的,因为它们是仅包含特定事件的指定字段数据的二进制大型对象(Binary Blob),而与所使用的跟踪技术以及该跟踪技术支持的字段类型无关。没有 Event 元数据,Event 有效负载将变得毫无意义且难以理解。
然后,ETW 运行时的职责是将该 Event 的二进制大型对象( blob )从 Provider 传送到 Consumer ,将与它与其元数据重新关联并变为可解码的。ETW 运行时将添加一些额外的元数据,指示有效负载的情况,例如时间戳,线程ID和事件的关键字。此信息与事件如何在运行时中路由有关,并且对于理解解码时事件的标识和上下文也很有用。最终,它作为给 Consumer 的 EVENT_TRACE 或 EVENT_RECORD 的一部分出现。
根据使用哪种跟踪技术,事件元数据的过程是不同的,并且在比较每种技术时,它是最大的考虑因素之一。
Event 元数据由事件的创建者以 .mof 文件中特殊MOF架构的形式手工编写。编写的模式必须与记录的有效负载相匹配,以便 Provider 可以正确解码事件。Event 解码器要求使用 mofcomp.exe 在系统上注册 .mof 文件。有关发布MOF 架构的更多信息,请参见发布经典 Provider 的事件架构。
可以通过 tracepdb.exe在构建过程中, tracewpp.exe 将自动生成事件元数据并将其存储在二进制文件的 .pdb中。 可以通过 tracepdb.exe 从单独的 .tmf 文件提取此元数据。事件解码器通常需要 .pdb 或.tmf**文件。有关tracepdb.exe的更多信息,请参见Tracepdb概述,有关tracewpp.exe的更多信息,请参见 TraceWPP task。
事件定义是在.man文件中编写。事件清单通过清单编译器(mc.exe)运行,生成编译所需的头文件代码 以及几个.bin二进制资源文件。然后,必须将这些资源文件作为编译资源编译到二进制文件,并将生成的二进制文件放在进行解析基于清单的Provider 提供的Event的系统上。此外,必须使用 wevtutil.exe 将清单文件安装在系统上。最重要的是,在提供的 XML 元素中的 resourceFileName 和 messageFileName 属性必须正确标识放置资源文件的二进制文件的完整绝对路径。请注意,在清单安装时使用wevtutil.exe开关/ rf和/ mf可能会覆盖这些路径。未正确执行这些步骤的系统将无法解码来自此 Provider 的 Event 。因此, Event 解码器需要一个已安装的清单,还需要和资源文件绑定的二进制已安装在资源和消息文件路径指定的位置。有关发布更多 Manifest-based 的概要信息,请参见发布 Manifest-base Provider 的 Event 概要。
所有的 TraceLogging 事件都是自描述的。自动生成的 Event 解码到 Event 元数据 并以紧凑的二进制格式与有效载荷一起发送。 Event 解码器仅需要 TraceLogging event 并了解 TraceLogging 元数据格式。
那里有许多解码工具。但建议您尽可能使用TDH,因为它会使用统一的API解码所有跟踪技术。跟踪类型取决您对解码偏好,TDH可能需要显式配置。
TDH利用使用mofcomp.exe在系统上注册的MOF解码数据。有关更多信息,请参考 Publishing Your Event Schema for a Classic Provider。
TDH必须指向您要解码的WPP提供程序的 .pdb 文件或关联的 .tmf 。这可以通过调用TdhSetDecodingParameter来执行。否则,解码引擎将依赖于环境变量TRACE_FORMAT_SEARCH_PATH。
TDH利用通过wevtutil.exe在系统上注册的所有基于清单的提供程序。
TDH的最新版本可自动检测和解码TraceLogging事件,而无需其他步骤。