When the buffers are full, the event tracer writes the event data to the log or the consumer application. If a consumer application requires real-time logging, the event tracer writes the event data to the consumer application in near real time. On a typical system, ETW's overhead is about 5 percent of CPU to log 20,000 events per second. The event tracer logs events in special binary files with an .etl extension. These binary files aren't human-readable, but you can use the tools I describe later to convert them into text, HTML, or comma-separated value (CSV) files.
The heart of the ETW subsystem is the provider. Providers can be user-mode applications or kernel-mode drivers. Providers are the source of event data—they're the applications that send events to the event tracer. So, if a developer is creating an application that performs transactions on a database, he or she would write a provider that posts events to the event tracer each time a transaction starts and stops. Providers are active only when a session has been created within the event tracer that calls that provider.
In Windows 2003, XP, and Win2K, Microsoft supplies out-of-the-box providers for various system services, including Active Directory (AD), Lightweight Directory Access Protocol (LDAP), Internet Information Services (IIS) 6.0, ASP.NET, Netlogon, and Local Security Authority (LSA). Microsoft also supplies an in-the-box Windows kernel provider for system-level operations, such as process creation and deletion, thread creation and deletion, disk I/O, file I/O, TCP and UDP traffic, page faults, registry I/O, executable image loads, and context switches. I concentrate mainly on the in-the-box providers in this article. You can also write your own providers. If you're interested in doing so, check out the Microsoft Developer Network's (MSDN's) event-tracing documentation at http://msdn.microsoft.com/library/en-us/perfmon/base/event_tracing.asp.
The controller application creates logging sessions, sets their starting parameters (e.g., buffer sizes, timestamp resolution), and starts and stops logging sessions at a scheduled time. Microsoft provides several out-of-the-box controller applications, which I discuss in the "ETW Tools" section.
The key characteristic about the ETW architecture is that each component (e.g., event tracer, controller application) works independently. The provider doesn't need to know about the event tracer, the controller application doesn't need to know about the provider, and so on. This architecture lets you easily use ETW-generated data for a variety of purposes. ETW also provides application developers with a great framework for testing their applications' impact on Windows systems without having to build a logging function themselves.
ETW Tools
In Windows 2003, XP, and Win2K, you can create, manage, and report on ETW sessions two ways: You can use the Microsoft Management Console (MMC) Performance Logs and Alerts snap-in, or you can use command-line utilities. In Windows 2003 and XP, the OS includes the command-line utilities. In Win2K, the command-line utilities are part of the Microsoft Windows 2000 Server Resource Kit and differ slightly from those in Windows 2003 and XP. In the context of the ETW architecture, the Performance Logs and Alerts snap-in and some of the command-line utilities are controller applications. Other command-line utilities provide the consumer application function.
XP's tools are basically the same as those in Windows 2003, except XP includes fewer out-of-the-box providers. So, although the following discussion mentions only the Windows 2003 tools, the discussion applies to XP as well.
Performance Logs and Alerts snap-in. If you start the Performance Logs and Alerts snap-in and navigate to the Trace Logs node, you can create a new trace session by right-clicking the node and selecting New Log Settings. After you give the new logging session a name, the session's Properties dialog box appears. On the General tab, you can choose the providers you want to use. Unless you're ready to sift through a huge amount of data, I recommend that you limit the number of providers you choose per session. For example, if you need to log kernel events and AD events, create two separate logging sessions. Trying to make sense of large amounts of trace data can be daunting. Later, if necessary, you can combine reports from two provider sessions with tools that Microsoft provides.
On the General tab, you can enable tracing on the metrics provided by the Windows kernel provider (i.e., the system provider) or other nonsystem providers that are registered on the system. For example, you can use the Windows kernel provider to enable network TCP/IP tracing, as Figure 2 shows. If you want to use nonsystem providers to enable tracing, you select the Nonsystem providers option, then click Add to select the providers. By clicking Provider Status, you can learn which providers are registered on the current system. Finally, both Windows 2003 and XP provide a Run As option that lets you run the trace from a user ID different from the one you're currently logged on as.
Register
