Are there other ways of consuming EventSource based ETW events aside from EventTrace based tools?

Jun 15, 2013 at 8:24 PM
Edited Jun 15, 2013 at 8:25 PM
Hi, I only began digging into ETW for the past few days, so please pardon any stupid questions.

My goal is to analyze the performance of a Modern Win8 App by consuming its ETW events. My initial understand of how ETW works is that the App developer would instrument the code using the Event Tracing(ETW)API, publish a manifest describing the events, the consumer then register the manifest using "wevtutil", and can subsequently turn on and log the ETW events using a variety of tools(i.e. xperf).

I then found out that the Win8 App uses the new EventSouce class to instrument ETW events. From what I have gathered, there doesn't seem to be an explicit manifest. Instead the manifest is sent as a "Known Event". Thus only consumers that know how to process the manifest embedded in this "Known Event", such as the EventTrace library(PerfMonitor, PerfView), can log EventSource events properly. Is my understanding correct?

I am leveraging my work from an existing automation project. It already uses a library to consume traditional manifest events(EtwProcessor, an internal tool) registered with Windows. I know using EventTrace library is always an option, but is it possible to configure EventSource ETW events in such a way that a manifest based tools can access them?

Jun 17, 2013 at 6:45 PM
First I should mention that the version of Windows Performance Analyzer (WPA) to be given out at the BUILD conference this month has support for parsing EventSource events. Thus users familiar with that tool can use EventSources with good fidelity.

As you know, normally ETW providers have to be 'registered' with operating system using the wevtutil tool, and which point standard windows parsers (the TDH library) work to decode the events. EventSources do not do this registration because it is logistically problematic for some scenarios (you can't be admin or you want to be XCOPY deployable). Instead EventSources log their manifest to the event stream.

But Evensource' ARE just normal ETW providers (with a manifest), you just need to do the registration yourself. EventSource has a method 'GenerateManifest' which generates an ETW manifest for the EventSource. If you compile this manifest into a DLL and register it with wevtutil, then the EventSource will work with all existing tools (it is just another provider).

We have a utility called 'EventRegister' that I will likely be blogging about in the next couple of months that does this in a nice way (you run it on your DLL and it generates the manifest registers with wevtutil).

We also have reusable C++ NATIVE code which I call 'DynamicManifestManager' that you can easily add to your existing TDH based parser that will watch for EventSource manifests and register them with the TDH library so that the TDH library 'just works' with EventSources. This allows you to avoid skipping the manifest registration step (This is in fact what WPA does to support EventSource).

If you are interested in either of these and can't wait until I blog about it in the next month or so, send me e-mail at and I can provide either EventRegister or DynamicManifestManager.

Jun 18, 2013 at 3:02 AM
Thanks Vance, I sent you an email earlier today.
Aug 26, 2013 at 6:58 PM