While most Windows developers know of Event Tracing for Windows (ETW) as a logging and tracing mechanism, many administrators have never heard of it. Simply put, ETW includes event logging and tracing capabilities provided by the operating system. Implemented in the kernel, it traces events in user mode applications, the operating system kernel and kernel-mode device drivers.
Event Tracing for Windows is used by a number of core OS components and some third-party applications to provide event logging and tracing. Although it required access to a checked build of Windows to gather ETW information when first released with Windows 2000, more recent versions provide built-in tools with normal (free) Windows builds.
Getting started with Event Tracing for Windows
When diagnosing and troubleshooting Windows Server issues, it seems there is never too much data. The admin is always looking for additional details on what is going on with various components to pinpoint the problem. As such, there are a number of tools like Process Monitor, Process Explorer, Performance Monitor (Perfmon) and Performance Analysis for Logs (PAL) that dig considerably deeper than the event log, but there are times when we need to dig even further down than that.
ETW allows additional instrumentation for gathering data that would not otherwise be available and has a number of advantages. For example:
*
it uses per-processor kernel buffers from a non-paged pool that are not impacted by application crashes or hangs
*
it uses very low CPU overhead
*
it’s available for x86, x64 and IA64 architectures
*
it can enable and disable tracing without rebooting or restarting applications
Event Tracing for Windows may seem like a great tool, but using it is another issue since there is no GUI or user guide. It also requires a few preliminary steps just to produce output that can be used for analysis.
In order to provide useful output you need a consumer. The consumer built in to Windows Server is Tracerpt.exe. As you can imagine, there are a number of flags for Tracerpt to provide specific output formats, so it’s important to become familiar with the Tracerpt and Logman utilities that are native in Windows Server 2003 and up, as well as Windows 7 and Vista.
It’s also important to understand the architecture for ETW. As you can see in Figure 1, the controllers are used to start and stop a tracing session. The tool used to do this in Windows Server 2003 and 2008 is Logman.exe.
Windows Server 2003 also contains a handful of event providers that return specific events, including the following Active Directory-related providers:
* Active Directory: Core
* Active Directory: Kerberos
* Active Directory: SAM
* Active Directory: NetLogon
For instance, specifying Active Directory: Kerberos as a provider will only return Kerberos-specific events.
Event providers differ between Windows versions, however. For example, Windows Server 2003 has 22 providers, while Windows 2008 has 387. This gives more power to the trace and offers more granularities. Yet when it comes to LDAP traffic, the Active Directory: Core provider appears to give the same detail for either Windows version.
You can also combine event providers into a single trace. Since Kerberos authentication was involved in the example above, I used the Active Directory: Kerberos and the Active Directory: Core providers and applied the Logman option-pf, as shown in the following example:
Logman Create Trace CoreKerb –pf c:\etw\input.txt –o c:\etw\coreKerb
For more info refer the link