Wow, what a year for tracing, what a month, what a week!
If you’re in the midst of what’s happening in tracing, your head is spinning with how much the teams have accomplished. If you aren’t in the midst of it, I suspect you’re either unaware or you feel lost.
Trust me, in the midst of the decade of change in tracing, this last week was the tipping point. In the last seven days, we’ve seen the release of Microsoft.Diagnostics.EventSource, Microsoft.Diagnostics.TraceEvent and the WPR/WPA announcement for Windows 8.1.
There’s a lot of work still to accomplish for a truly mature diagnostics story. But going forward I think the big questions are guidelines for EventSource style tracing, what consumers should look like for specific tasks, and alleviating pain points. This week the supporting tools became adequate.
It is nearly impossible to keep straight what component is contributing which key piece of the puzzle. In this post, I’ll summarize and provide what I think are the most important links. If I make a mistake, comment please and I’ll update. If I left out one of your favorite links, please add it in the comments.
At the end of the post, I’ll describe channels and manifests becaues I can’t find concise descriptions.
System.Diagnostics (except System.Diagnostics.Tracing)
· All usage of Trace and TraceSource classes should be reevaluated going forward
· Very fast, common, tracing subsystem
· Strongly typed events
· Component model with interface driven controllers, providers and consumers
· By implication independent core (Silverlight potential)
System.Diagnostics.Tracing.EventSource (.NET 4.5) (info here)
· Easy placement of your trace events into the ETW debug channel independent of System.Diagnostics overhead
· Strongly typed events available in .NET
· In-line manifests
· In-proc EventSource collection (not the common case)
· Alternate output to ETW allowing a natural logging experience during development that morphs to production ETW tracing via configuration (debug channel)
· Tools to test correctness of EventSource classes
Microsoft.Diagnostics.EventSource (info here)
· Adds EventSource support for alternate channels: including admin channel support which means the ability to write to the Event Log with strongly typed events
· Provides EventSource support in .NET 4.0
· Installed manifest support for EventSource (manifest creation and installer created as build step): allows manifest installation for Event Viewer support
· Build time validation of EventSource classes
WPA/WPR Support (info here)
· Contained in the Windows Assessment and Deployment Kit (Windows ADK) for Windows 8.1 Preview
· Support for in-line manifests in mainstream tools as controllers and consumers
Microsoft.Diagnostics.TraceEvent (info here)
· Out of proc (the common case) ETW support from within .NET
· Library to create ETW events (including EventSource/in-line manifests) controllers (start/stop)
· Library to ETW events (including EventSource/in-line manifests) consumers (filter, load, evaluate, display)
· While you may not use this directly, it’s a critical step in providing better tools, particularly for consuming ETW
A Few Definitions
If you’re not familiar with ETW, the discussion above may require a few definitions.
ETW supports four channels as the highest level of filtering breakdown according to target audience. The definitions from here:
Admin type channels support events that target end users, administrators, and support personnel. Events written to the Admin channels should have a well-defined solution on which the administrator can act. An example of an admin event is an event that occurs when an application fails to connect to a printer. These events are either well-documented or have a message associated with them that gives the reader direct instructions of what must be done to rectify the problem.
Operational type channels support events that are used for analyzing and diagnosing a problem or occurrence. They can be used to trigger tools or tasks based on the problem or occurrence. An example of an operational event is an event that occurs when a printer is added or removed from a system.
Analytic type channels support events that are published in high volume. They describe program operation and indicate problems that cannot be handled by user intervention.
Debug type channels support events that are used solely by developers to diagnose a problem for debugging.
The admin and diagnostics channels appear to be the most common. The debug channel is sometimes called the diagnostic channel.
To fulfill the goal of superfast tracing, ETW produces a binary stream containing a limited amount of human in-decipherable data. Strongly typed events cannot be used without a definition of the contents. This definition is contained in a manifest.
Historically this manifest was created as an XML document and installed onto the computer containing the ETW consumer. This model presented a host of issues, including being brittle, difficulties when multiple manifest versions existed on different production machines, and requiring complex installation. Some tools, including Event Viewer, support only installed manifests.
EventSource introduced in-line manifests. The manifest is simply another event in the ETW stream and is installed in memory only when it appears. This is a much more flexible model and will be important going forward.