ETW Central

Over the last few years I’ve written over forty blog posts that discuss ETW/xperf profiling. I’ve done this because it’s one of the best profilers I’ve ever used, and it’s been woefully undersold and under documented by Microsoft. My goal has been to let people know about this tool, make it easier for developers and users to record ETW traces, and to make it as easy as possible for developers to analyze ETW traces.

Some of those posts have aged poorly, and the rest are hidden amongst the 160+ posts (really? wow) I’ve written. The purpose of this page is to be a central hub that links to the ETW/xperf posts that are still relevant. Also, I’ve updated many of the older posts to reflect changes in the ETW toolset (technically known as the Windows Performance Toolkit). For convenience this page is accessible as

The most important post describes how to record ETW traces. This is important because ETW traces can be recorded on one machine, and analyzed on another. This means that your customers or relatives can record ETW traces and then you can analyze them. Remote diagnosis of issues is a wonderful superpower. The article describing how to record an xperf/ETW trace can be found here – share it with those who have performance problems:

Xperf Basics: Recording a Trace (the ultimate easy way)

Once you’ve got a trace you need to analyze it (or share it with someone who can). The most comprehensive resource I’ve created for learning how to analyze ETW traces is the series of three videos I created in 2014. More information and links to the videos can be found here:

ETW Training Videos Available Now

For more details, or if you don’t want to watch videos, there are many tutorial blog posts available, listed here in rough order of importance:

Doing precise analysis of an ETW trace requires knowing exactly what the many columns in the tables mean. Some of those table columns are documented in these blog posts, updated in 2016 for the latest version of WPA:

ETW investigation write-ups:

Some of my favorite blog posts are those that tell a tale of noticing some software that I use being slow, recording a trace, and figuring out the problem. In most cases this let me come up with a workaround, and in many cases the (ridiculously!) detailed bug reports or the attention the posts drew led to the problems being fixed.

Many of the articles linked to below have not yet been updated. It’s an ongoing process but I think it’s worth publishing this now without waiting for all of the updates to finish.

I’ve categorized the investigations by what product was investigated. And, as a reminder, with the exception of the fractal software investigation all of these are looking at problems in software that I don’t work on.

Visual Studio and VC++ code-gen:

Windows Performance Toolkit (profiling the profiler!):


Windows Live Photo Gallery:

Western Digital driver (initially thought to be Windows):


Obsolete posts

Some of the blog posts are now completely obsolete and are listed here only for historical interest:


About brucedawson

I'm a programmer, working for Google, focusing on optimization and reliability. Nothing's more fun than making code run 10x faster. Unless it's eliminating large numbers of bugs. I also unicycle. And play (ice) hockey. And sled hockey. And juggle. And worry about whether this blog should have been called randomutf-8.
This entry was posted in uiforetw, xperf and tagged , , , , . Bookmark the permalink.

42 Responses to ETW Central

  1. Pingback: Summarizing Xperf CPU Usage with Flame Graphs | Random ASCII

  2. Pingback: UIforETW – Windows Performance Made Easier | Random ASCII

  3. Pingback: Xperf Analysis Basics | Random ASCII

  4. Pingback: Exporting Arbitrary Data from xperf ETL files | Random ASCII

  5. Pingback: The New WPA Xperf Trace Viewer–New Bugs and Old | Random ASCII

  6. Pingback: WPA–Xperf Trace Analysis Reimagined | Random ASCII

  7. Pingback: Process Tree from an Xperf Trace | Random ASCII

  8. Pingback: Xperf Wait Analysis–Finding Idle Time | Random ASCII

  9. Pingback: Xperf and Visual Studio: The Case of the Breakpoint Hangs | Random ASCII

  10. Pingback: Visual C++ Debug Builds–”Fast Checks” Cause 5x Slowdowns | Random ASCII

  11. Pingback: Visual Studio Single Step Performance Fixes | Random ASCII

  12. Pingback: Make VC++ Compiles Fast Through Parallel Compilation | Random ASCII

  13. Pingback: You Got Your Web Browser in my Compiler! | Random ASCII

  14. Pingback: Self Inflicted Denial of Service in Visual Studio Search | Random ASCII

  15. Pingback: Xperf Symbol Loading Pitfalls | Random ASCII

  16. Pingback: Slow Symbol Loading in Microsoft’s Profiler, Take Two | Random ASCII

  17. Pingback: Windows Slowdown, Investigated and Identified | Random ASCII

  18. Pingback: Windows Slowdown, Investigated, Identified, and Now Fixed | Random ASCII

  19. Pingback: Making VirtualAlloc Arbitrarily Slower | Random ASCII

  20. Pingback: Hidden Costs of Memory Allocation | Random ASCII

  21. Pingback: Fixing another Photo Gallery performance bug | Random ASCII

  22. Pingback: Faster Fractals Through Better Scheduling | Random ASCII

  23. Pingback: PowerPoint Poor Performance Problem | Random ASCII

  24. Pingback: Defective Heat Sinks Causing Garbage Gaming | Random ASCII

  25. Pingback: Thread Naming in Windows: Time for Something Better | Random ASCII

    • brucedawson says:

      I don’t think logman is necessarily better or worse than xperf but I don’t think it can do the things that I do with xperf, so it is of little interest to me. Disclaimer: I’m not a logman expert, but I think this is true.

      TL;DR – UIforETW/xperf/WPA can work miracles and I explain how to do this in this blog. logman? Dunno.

      • Severin Pappadeux says:

        Not that it can do something different, but on my W10 installation it came with the system, C:\Windows\System32\logman.exe. Basically, if you install something on user system, looks like it is much better to run logman as an events watchman for your app

  26. Pingback: Power Wastage On An Idle Laptop | Random ASCII

  27. Hi Bruce, awesome work! Is there a place for RFEs? In particular, it would be great to be able to change the “trace to memory” window as well as specify the length of time before a trace is automatically saved to disk and/or stopped. Thanks!

    • brucedawson says:

      Feel free to create issue suggestions at

      Configuring the memory used and the auto-trace elapsed time has been suggested, but such changes must be made carefully to avoid giving users unnecessary foot-guns. “It just works” must continue to be as true as possible. That is, configuration is reasonable as long as it adds value without undue complexity or user risk.

      • Thanks. The complexity issue I understand but your point of view on risk seems overly cautious. As someone who has programmed in C/C++ for over 25 years, I have no lower extremities left to shoot! In my experience, a high amount of configurability is suitable for all but the most skittish, particularly when the *defaults* just work. In debugging performance and other issues, exploration is part of learning the ropes and I wouldn’t limit configurability unnecessarily in order to keep safe a small percentage of users that would try to do silly things on production systems. Yes I understand that having more configuration options multiplies the bug surface area and maintenance costs but I think that most users willing to experiment with advanced functionality would also be willing to help debug and improve those features, directly or indirectly. EOP (End of Pitch).

        • brucedawson says:

          I don’t disagree. Having it work out-of-the-box is most important. Having the configuration options as uncluttered as possible is also important, since every option that is added makes the remaining options harder to find. But I don’t think we’re really disagreeing in any meaningful way.

          > most users willing to experiment with advanced functionality would
          > also be willing to help debug and improve those features

          Well, the great thing about UIforETW being open source is that they can just grab a copy, change the constants, and party-on-Garth!

  28. Pingback: UIforETW is No Longer a CPU Hog | Random ASCII

  29. Pingback: ETW Flame Graphs Made Easy | Random ASCII

  30. Pingback: WPA Symbol Loading is Much Faster, but Broken for Chrome | Random ASCII

  31. Pingback: Thread Naming in Windows: Time for Something Better | Random ASCII

  32. I think another slowdown is on very large source files. If the function(s) being debugged can be migrated to smaller source files, its debugs faster. This was observed on a single source file that was 20K+ lines long.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s