ETW is the best way to analyze performance on Windows, and Windows Performance Analyzer (WPA) has been the preferred tool for analyzing ETW traces for ten years now, generally obtained either by running UIforETW or by getting it from the Windows 10 SDK. However the SDK version was not updated for a long time.
Starting in 2018 WPA has been available from the Microsoft store and the hope was that this version would be updated more frequently, however this version was also not updated for a long time.
Earlier this year, however, a new preview version of WPA (cleverly called Windows Performance Analyzer (Preview)) became available from the Microsoft store, with its debut version being 10.6.20.1. For a few months this was the most recent version available.
Update: As of late November the preview version of WPA is once again ahead of the non-preview version. The preview version is currently sitting at 188.8.131.52, has a refreshed UI and Dark Mode, and supports v1.0 Release Candidate of the Performance SDK for building processing plugins.
Benefits of 10.6.20.1
The 10.6.20.1 version of WPA has a new Other section in Graph Explorer which contains a CPU Frequency graph which I’m hoping will be useful. The new WPA also removes some limits that made some large traces impossible to load in old versions of WPA – previously WPA would crash when loading these traces.
However the biggest advantage of the new version is that transcoding of large symbol files is much faster. Chrome has large PDBs and they were taking more than twenty minutes to process with the previous version of WPA. Given that we ship daily builds of Chrome Canary, and given that I sometimes profile local Chrome builds, I was having to wait the more than twenty minutes quite frequently. I haven’t measured the performance of the new version’s symbol transcoding but it’s fast enough that I don’t much notice the delay – five minutes perhaps? Maybe less? It’s a big improvement.
Which to get?
With three different options for getting WPA it’s hard to know what to do. The simplest answer is to grab the latest release of UIforETW (1.5.6) and run it. This will automatically install 10.6.20.1, and you’re done. You can then postpone worrying about the store version until (and if) it moves ahead of the SDK/UIforETW version.
That said, the store versions have the possibility of being newer than the SDK version (the store preview version was the newest version for several months) so it’s worth knowing how to get them.
For many users you just need to open the Microsoft store and search for Windows Performance Analyzer or Windows Performance Analyzer (Preview). Sometimes the former search will find both, but sometimes it won’t. The Microsoft store is inscrutable and unpredictable, especially on Windows 10. Among other issues the Windows 10 store won’t let me rate or review the preview version because I don’t “own” it, despite having it downloaded. Very strange.
It is quite safe to install both versions, which is what I have done on my machines.
If you are working at a large company then access to the Microsoft Store may be blocked, but do not despair. It is still possible to install apps from the store, it’s just a bit more work. These commands will do the trick for the regular version:
> git clone https://github.com/MattiasC85/Scripts.git
> powershell Scripts\OSD\Download-AppxFromStore.ps1 https://www.microsoft.com/en-us/p/windows-performance-analyzer/9n0w1b2bxgnz
These commands will do the trick for the preview version (you can skip the git clone step if you’ve done it already):
> git clone https://github.com/MattiasC85/Scripts.git
> powershell Scripts\OSD\Download-AppxFromStore.ps1 https://www.microsoft.com/en-us/p/windows-performance-analyzer-preview/9n58qrw40dfw
In both cases the powershell script downloads the AppX file which you then run to install WPA. The installed versions will be kept up-to-date just as if they had been installed from the store.
I’ve found that powershell script handy multiple times, for getting Windbg (Preview), SizeBench, and this. The store URL which is passed to the powershell script can be found with a web search for “<appname> Microsoft Store”. Recommended.
If the store isn’t blocked on your machine and you want the simplest possible way to install both versions then this pair of commands will do the trick:
winget install 9N0W1B2BXGNZ
winget install 9N58QRW40DFW
Running the right version
If you run WPA from the command prompt or from UIforETW then whichever version is first in the path will be invoked. If you want one of the store versions to run then you need to edit your path environment variables so that this store entry:
comes earlier than this SDK entry:
C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\
This is made complicated by the existence of user and system path variables that are merged with the system path variables coming first. I think that your best option is to move the SDK entry to the user path for easier sorting.
But wait, we’re not done yet! If you have installed both store versions of WPA then you need to control which of those will run. Both versions publish execution aliases which are zero-length files in the WindowsApps directory that then launch the real executable. Since both versions publish the same execution aliases (wpa.exe, wpaexporter.exe, and xperf.exe) there needs to be a mechanism to select the appropriate version.
You can do this by running the App execution aliases settings widget. Just search for app execution alias in the start menu and you’ll end up here:
Just select the version that you want for each executable. If you turn off both execution aliases then the SDK version will be run.
But wait, there’s still more! By default the WindowsApps directory contains execution aliases for python. These may now be closer to the front of your path, and if you haven’t installed the store Python then running one of these will try to install Python, which works badly when run from a build script. If you don’t plan to use these aliases then you need to disable them, like this:
UIforETW 1.55 is the first version that knows how to launch WPA from the store, by searching the store the first instance of wpa.exe. Be sure that you are running that version or higher.
I recommend getting the new WPA through one of these channels, or better yet, through all three.
I use the WPA 10.6.20.1 which comes with the Windows 11 SDK. This comes now with two MSIs.
The core MSI contains wpr and wprui to record things. The other bigger contains WPA and the rest to view ETW Traces. The separation is not clean because WPRUI of the core (WPTx64 (OnecoreUAP)-x86_en-us.msi 2.5 MB ) installer misses some dlls which come with the full WPA (WPTx64 (DesktopEditions)-x86_en-us.msi 78 MB) installer. But is is sufficient to record data with latest and greatest WPR.exe of Win11 with only 2,5 MB. The full WPA (78 MB) installer comes with .NET 3.1 as self contained package. If you just install the DesktopEditions msi then WPA will not work which can confuse users who expect a working WPA after the installer has run.
The Redistributables directory for WPT comes with nine (!!!) MSIs which was rather confusing at first. I initially was going to just distribute WPTx64 (DesktopEditions)-x86_en-us.msi in its 78 MB glory, but that failed on some machines, and I was then told that I also needed to distribute WPTx64 (OnecoreUAP)-x86_en-us.msi. So, UIforETW distributes and installs both of these.
It’s good to know that the OnecoreUAP MSI can be use when just recording traces – that’s handy if installing it on a server or some-such. I don’t think I’ll make use of that very often though – it’s simplest to just install the entire thing.
You might be interested in https://github.com/Siemens-Healthineers/ETWAnalyzer which did go open source today. I think it is the biggest tool out there to query ETW data with the TraceProcessing Library.
Do you know through your networks if there is any possibility of the WPA being open sourced or ported to Linux? It seems like you can already use it to analyze traces from Linux, but you still need to jump onto windows to do it, which is super lame. I’d be tempted do do the porting myself if it was open source so I could get it on Linux, but alas, I need the code for that.
I haven’t heard rumors of either thing.