How to collect a boot trace on Windows 10 with Windows Performance Recorder from the Microsoft ADK

The Dude
  • For: Windows 10 (any x64 build)
  • Requirements: Windows Performance Toolkit from the Microsoft ADK


  1. Launch WPRUI as administrator (aka Windows Performance Recorder) by clicking Start and searching for WPRUI. Right-click/click run as administrator
  2. Check boxes that are important in your scenario. My recommendation is
    1. check First Level Triage
    2. Expand Resource Analysis
    3. check CPU
    4. check Disk IO
    5. Expand Scenario Analysis
    6. check Minifilter IO
    7. Change “Performance scenario” from ‘general’ to ‘boot’
    8. Change “Number of iterations” from ‘3’ to ‘1’
    9. Click Start (This will reboot the machine)
  3. Logon when the machine is rebooted.
      1. If you are not running as an administrator, launch Windows Performance Recorder again as administrator.
      2. You should be prompted for a timer for 120 seconds, wait it out.
  4. That’s it, trace should finish, and a window appear telling you the file location and offering to open it in Windows Performance Analyzer.





  1. What is the data you get out of MiniFilter? In Trace-Processing Library I get only an additional DiskIO time and if the time is reliable. That sounds not terribly useful, at least when one use WPA.

    • There is a graph “Mini-filter delays” that shows the time added to the process by each mini-filter driver.

      When I deal with our product and mis-configured third-party AV solutions, I can see significant IO delays on occasion on our process IO. This makes us look artificially slower than we are, or should be. So we use it for a bellwether test of “Are A/V exclusions set properly”.

      In the case with multiple security products, you can sadly find many times they are scanning each other in addition to their normal work, which causes the system to slow to a crawl as you might imagine. I’ve seen IRP delays as high as 10 seconds in this graph, as an example of utility.

  2. Ahh Cool. I did not know about that one. The usual approach I have taken is to stacktag the AV solutions which often tell me where CPU time is spent in the kernel or user mode drivers which often have broken stacks anyway due to no-FPO optimization. Just a few days ago I did finish my FileIO ETW extraction tool where I have hoped to see the impact of AV solutions. Unfortunately the File I/O events do not include in their IO Time the impact of AV Minifilters. That is a pity because that makes the large File IO event data much less useful.

    • What I’ve noticed is SYSTEM does a lot of the diskIO for processes as well. For example tracing Tanium, we can see sometimes SYSTEM is recorded in ETW doing the disk write event to SQL. I’m assuming the Windows file cache manager muddies things and that’s what ETW is reporting on.

Leave a Reply