Event tracing for Windows, or ETW is a type of dynamic logging system that was originally introduced in Windows 2000. Back in the days it was considered a form of black art just to enable a log, let alone intrepid the data that flows from it. Some years ago, version 4.x was introduced, somewhat simplifying the process. Enabling the system to create a log (or trace) still required you to know what options to enable from a command-line session. Let’s just say that it took a while to get used to working with the available tools. Lucky for those of us wanting to get started with gaining some insight into the inner workings of Windows, Microsoft released the Windows Assessment and Deployment Toolkit along with the release of Windows 8. Within this toolkit a brand new version of the “Windows Performance Toolkit” has been included. This toolkit consists out of the tools that enable you to capture and examine ETW data.
Before you dive into the bits and bytes of the Windows Performance Toolkit (WPT), spend a moment examining the way event tracing for Windows works from an architectural pint of view, just to get familiar with the terminology. Don’t worry I wont bore you to death!
Basically the whole ETW systems consists out of four basic elements. ETW Controllers. ETW Event Trace Providers, ETW Sessions and ETW Consumers. Just take a look at the picture below so get a visual representation on the subject.
- ETW Controller
- A ETW controller can be any application or process that can initiate, control and use ETW.
- ETW Event Trace Provider
- An event trace provider has the functionality and logic for capturing log data for a certain aspect of the operating system or specific part of an application.
- ETW Session
- When an ETW controller enables one or more ETW event trace providers a session is automatically created. Within this session you can control how much data is stored in memory, when the data is flushed to disk etc.
- ETW Consumer
- Once a session is created a consumer can use that session to display the generated data in real time or the data is stored in a file for later viewing.
Sounds easy, right? Still a little dazzled about the terminology? Let’s compare the above theoretical information with a real life example.
Just take a look at the picture below and imagine the house you see representing the Windows platform.
You as the owner of the house want to monitor what is going on in the garage, kitchen and the garden. To be able to do that you buy and install 3 IP cams in the before mentioned locations. After that you turn on your computer and install the appropriate application so you will be able to just sit behind your desk and on demand be able to see what’s happening in those locations. Sounds familiar? Let’s project that on how ETW works.
In this case the ETW Controller will be you, the owner of the house. When you start your application on your pc a process is created in which you control the amount of data that comes in by throttling the required bandwidth and set the screen resolution for all the screens. This can be considered as the configuration of the ETW session. Like mentioned above the ETW session can also be configured so it can handle the data as you see fit, exactly the same as your application configuration. Once you click the play button on your screen and enable the IP cam, data will be flowing into your pc. As the IP cams provide you with the required video (or data) these will be our ETW providers. Still with me? Great, lets take the final step!
Finally all screens on your computer are filled with beautiful live views of your house. Just take a moment and think about what you’re doing here. You’re consuming the data in real time! Sounds familiar? Thought so too! For long term or offline viewing you can probably configure your application to store the video stream for later viewing, the same applies to ETW. The data that flows from the session can be stored in a file so you can view it on a later date.
Once you stop viewing or storing the data and close the application, the IP cams are automatically turned off and the session is gone. The same process applies to ETW. You can dynamically enable or disable logging whenever you want to.
That’s really all there’s to it from a high level architectural overview of ETW.
Resource Monitor
If you have ever run into performance issues on your computer it’s very likely that at a certain point you’ve started and used the Windows Resource Monitor. This wonderful little tool was first introduced in 2007 and has been optimized ever since. What you perhaps don’t realize is that at it’s core the resource monitor uses the ETW system to capture and display data in real time. Let’s take a look, but wait!
You have to pay a little attention here. When you start the tool, you will notice a small delay when it’s building up the screen. At that very moment the resource monitors begins using the event tracing for windows system, enables a few event providers and creates an ETW session. Once that session is created live data is displayed on your screen. Just right click on the taskbar and start the task manager. Go to the performance tab (On Windows 8, expand by clicking on “more details” if not done previously) and click the resource monitor option at the bottom of the screen.
If you don’t want to go through all the steps by first opening task manager, just hit the Windows key and type “resmon.exe”. Without the “” obviously.
In the main screen of resource monitor you can actually see what event providers from the ETW system are used. CPU, Memory, Disk and Networking, which are considered the most basic elements in a system. more than 80% of issues related to performance problems are derived out of one of these four key areas. As I mentioned before, an ETW controller initiates and configures a ETW session, selects the appropriate ETW event trace providers and any ETW aware application can use data from that session. In the case of the resource monitor it’s actually using every aspect of ETW. It’s not just the controller, but is also consuming the data and displays it in real time. How cool is that!
Did you know that you could even do a deep(er) dive into what is actually configured in this session? It’s really not that hard! All you need to do is open up “Computer Management” and open the “Performance” node, expand “Data Collector Sets” – “Event Trace Sessions”. The latter must have a familiar sound by now.
As you can see, Windows does a lot of performance tracing by default. It can do so because the overhead of the ETW system is very low so you don’t really notice it at all.
If you want to see what’s actually configured in the Resource Monitor session you can simply open the session displayed at the end of the list, the one that starts with WDC. Right click and choose “Properties”. Here you can see what kind of buffer parameters are configures, how the trace session is used and what type of security is set on the session itself. One of the more interesting tabs related to this post is the “Trace Providers” tab. The event trace providers listed here are the once that the Resource Monitor enabled to start the whole session in the first place. Here you can see items as, kernel-disk, kernel-file, kernel-network and kernel process.
In the beginning of this post I mentioned that Event Tracing for Windows has been around since Windows 2000. At that time we only had one available event provider, the “Windows Kernel Trace” provider. When Microsoft released Windows XP in 2001 ,nothing was added to the operating system and till today that’s basically still the only inbox provider available on Windows XP. I say basically because applications can add additional event providers. In the next versions of Windows, Microsoft increased the number of available event providers to more than 800.
To get an overview of all installed event providers you can start the inbox ETW controller tool “logman.exe” and ask Windows to display all the installed (or registered) event providers. As a recommended practice when you’re measuring system performance, make sure that everything you use runs with administrator credentials, also known as an elevated process.
Once in an elevated command prompt type:
logman.exe query providers
A similar output like the one below will display an overview of all registered event trace providers on your system
Provider GUID
-------------------------------------------------------------------------------
.NET Common Language Runtime {E13C0D23-CCBC-4E12-931B-D9CC2EEE27E4}
ACPI Driver Trace Provider {DAB01D4D-2D48-477D-B1C3-DAAD0CE6F06B}
Active Directory Domain Services: SAM {8E598056-8993-11D2-819E-0000F875A064}
Active Directory: Kerberos Client {BBA3ADD2-C229-4CDB-AE2B-57EB6966B0C4}
Active Directory: NetLogon {F33959B4-DBEC-11D2-895B-00C04F79AB69}
ADODB.1 {04C8A86F-3369-12F8-4769-24E484A9E725}
ADOMD.1 {7EA56435-3F2F-3F63-A829-F0B35B5CAD41}
Application Popup {47BFA2B7-BD54-4FAC-B70B-29021084CA8F}
Application-Addon-Event-Provider {A83FA99F-C356-4DED-9FD6-5A5EB8546D68}
ATA Port Driver Tracing Provider {D08BD885-501E-489A-BAC6-B7D24BFE6BBF}
AuthFw NetShell Plugin {935F4AE6-845D-41C6-97FA-380DAD429B72}
BCP.1 {24722B88-DF97-4FF6-E395-DB533AC42A1E}
BFE Trace Provider {106B464A-8043-46B1-8CB8-E92A0CD7A560}
BITS Service Trace {4A8AAA94-CFC4-46A7-8E4E-17BC45608F0A}
Certificate Services Client CredentialRoaming Trace {EF4109DC-68FC-45AF-B329-CA2
825437209}
Certificate Services Client Trace {F01B7774-7ED7-401E-8088-B576793D7841}
Circular Kernel Session Provider {54DEA73A-ED1F-42A4-AF71-3E63D056F174}
Classpnp Driver Tracing Provider {FA8DE7C4-ACDE-4443-9994-C4E2359A9EDB}
Critical Section Trace Provider {3AC66736-CC59-4CFF-8115-8DF50E39816B}
DBNETLIB.1 {BD568F20-FCCD-B948-054E-DB3421115D61}
That concludes the first post and introduction into event tracing for Windows. The next post will be about installing additional tools and tacking a trace.