IMPORTANT ANNOUNCEMENT FOR OUR READERS!
AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!
We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!
Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.
If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.
NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!
As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!
One of the great things about the Windows Assessment and Deployment Kit is the Windows Performance Toolkit.
The toolkit, itself, has a subset of tools that produce in-depth performance profiles of Windows operating systems and applications.
If you are familiar with the older versions of the Windows Performance Toolkit obtained from the Windows 7 SDK, you know that obtaining traces with Xperf was, at times, very complex. Knowing which providers and stackwalking flags to enable was a struggle all together. There was no built-in UI and everything was done from a command prompt using xperf.exe or xbootmgr.exe. We wrote several posts on troubleshooting Windows performance issues using the Xperf utility as part of our Xperf Xpert series:
Windows Performance Toolkit V5.0 introduces WPR (Windows Performance Recorder) as well as WPA (Windows Performance Analyzer) to make our lives easier. Basically, the recorder gathers the trace and the analyzer opens the trace.
For today’s topics, we will focus on installing the Windows 8 ADK as well as using the WPR for common scenarios.
Installing the Windows Performance Toolkit V5.0
Installing the toolkit is pretty straightforward. First, download it from here. Don’t worry, you only have to do this on one machine which has internet connectivity as the install itself will copy down local copies of the Windows Performance Toolkit redistributables that can be used for installation to other machines.
So, let’s get started…. During the install, specify a location or a download path:
Select Yes to Join the CEIP:
Accept the license agreement:
Since, we are only installing just the Windows Performance Toolkit,
uncheck the other boxes and then click on Install:
Installation should only take a few minutes:
Now, you are done:
By default, the Windows Performance Toolkit installs to C:\Program Files (x86)\Windows Kits\8.0\Windows Performance Toolkit. If you wanted to install to an alternate machine, you can use the redistributables under C:\Program Files (x86)\Windows Kits\8.0\Windows Performance Toolkit\Redistributables. One cool thing to notice is the redistributable for ARM 🙂 which means you can install the toolkit on tablets\notebooks running Windows RT.
Using the Windows Performance Recorder
WPR comes in two flavors, a GUI form (wprui.exe) and a command line version (wpr.exe). Since I am a GUI junkie, I will be using wprui.exe.
To launch the Windows Performance Recorder, simply double click on the exe or if you are using Windows 8, click on the tile on the start screen (the one with the bar graphs!).
The tracing itself does require administrative privileges, so don’t be surprised if you see a UAC prompt:
Note: If you are running a 64 bit version of Windows 7 or Windows Server 2008 R2, you will need to disable the paging executive in order to successfully gather event stacks. To do this, go to a command prompt and run wpr.exe –disablepagingexecutive on. You can also do this manually by setting DisablePagingExecutive (dword) to a value of 1(hex) under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management. This does require a reboot.
Also, if you have 24 gigs or more of memory, it might be better to use the following general profile: C:\Program Files (x86)\Windows Kits\8.0\Windows Performance Toolkit\SampleGeneralProfileForLargeServers.wprp. Systems with large amounts of memory will consume larger amounts of nonpaged pool(buffer). This profile uses less memory then the default general profile.
At its simplest form, the GUI will appear like below:
Clicking on Start will launch the General Profile for the recording. In fact, by default the general profile is loaded for every recording. It is what its name implies……a general profile for recording basic
system issues and performance data. The general profile uses the NT Kernel Logger Collector as well as the WPR_initiated_WPR Event Collector. You can see this in action when a trace is running by going to Data Collector Sets\Event Trace Sessions. There you will see those two collectors running.
Now that the recording is started, the GUI will appear like below:
If you notice, we now show the number of events dropped. I can’t tell you how many times I’ve reviewed xperf data that had numerous events dropped which lead to an inconclusive analysis. If you see events
being dropped, you can just recapture a trace with WPR and save yourself headaches.
Clicking on Save will allow you to save the trace and cancel will stop the trace. Once saved, it restarts the tracing so that if you have another issue you could easily save it from the buffer.
We now save the traces under the user account conducting the recording under Documents\WPR Files.
This is primarily for security concerns as outlined by the yellow exclamation.
Furthermore, we can provide a detailed description of the problem, and the format is saved as machinename.date.time format.
Notice, there are also folders marked in same format with NGENPDB at the end. This folder will contain all the PDBs necessary to diagnose issues with the managed components.
Now, let’s move on to more advanced recording with WPR. Clicking on “More options” will bring up additional profiles used for recording. This is where you can get more granular on what you want to capture. There is an overhead associated with ETL tracing and the more checkboxes you check, the more overhead you will experience. Never, I repeat, never check every checkbox!!
The Performance scenario dropped down gives you the scenario you are trying to troubleshoot.
- General: Records general performance while the computer is running.
- On/Off – Boot: Records performance while the computer is booting.
- On/Off – Shutdown: Records performance while shutting the computer down.
- On/Off – RebootCycle: Records performance during the entire cycle while the computer is rebooting.
- On/Off – Standby/Resume: Records performance when the computer is placed on standby and then resumed.
- On/Off – Hibernate/Resume: Records performance when the computer is placed in hibernation and then resumed.
You might ask yourself …..what happened to xbootmgr.exe? I thought that did boot level traces? Guess what, WPR replaces xbootmgr and will be the preferred tool moving forward for any on/off scenarios.
The Detail level dropdown is where you specify whether the detail is light or verbose. Verbose is the default, but there might be times such as analyzing network I/O activity where you do not want to include
every send, receive, and acknowledgement in the trace. That is where light comes in handy. For the Logging mode, memory is the default for the General Performance scenario. I’d suggest for every LONG recording setting this to memory. Setting this logging mode to memory records logging data to circular buffers in memory. Furthermore, if you cannot anticipate when the issue will occur, use memory logging mode.
Logging to a file is generally used for very short recordings. Do not attempt to open a trace in WPA that is very large. If you are trying to analyze a trace in the several gigabytes, use memory logging mode.
Note: For any boot, fast startup, shutdown, rebootcycle, standby/resume, and hibernate/resume scenario, WPR will ALWAYS log to a file. You cannot change this in the GUI.
So, what if you wanted to create a custom profile if you already knew the provider you are trying to gather a trace for? MSDN has some good examples on creating custom profiles. Also, there is an example wprp file in the C:\Program Files (x86)\Windows Kits\8.0\Windows Performance Toolkit directory. To add it, click Add Profiles, then click on SampleWPRControlProfiles.wprp.
Notice, the profile was added under “Custom measurements.” All custom profiles will be added there.
Now that we have a recorded trace, what do we do with it? Well, that is where WPA comes into the picture. The Windows Performance Analyzer allows you to open the trace for analysis. You mean, it doesn’t
analyze it for me? Nope, not quite. I will save that thought for a later topic.
If you are interested in seeing some “live action” videos with WPA and WPR, I would suggest looking at the following Channel 9 videos by Michael Milirud:
As with anything, practice makes perfect! Install the toolkit and get used to it. Time is your friend.
James Klepikow Platforms PFE