Windows performance toolkit windows server 2012

What is the Windows Performance Toolkit?

Windows Performance Tools are designed for analysis of a wide range of performance problems including application start times, boot issues, deferred procedure calls and interrupt activity (DPCs and ISRs), system responsiveness
issues, application resource usage, and interrupt storms.

Installation of the Windows Performance Tools

The Windows Performance Tools (WPT) is part of the Windows 8.1 SDK and the Windows Assessment and Deployment Kit. In this guide I’ll use the Windows 8.1 SDK Installer to install
the WPT.

Go to the download site of the SDK:

http://msdn.microsoft.com/en-US/windows/desktop/bg162891

and click on the button download to download the Webinstaller:

and store the installer on your HDD. Now run the setup and this screen shows up:

Click next and select the WPT from the list:

Click «Install» and the Setup downloads the required files.

and installs the WPT

After a reboot (required to add the WPT folder to the PATH variable to run the tools from every place) you are ready to use xperf.

I have a nice tip for you: The setup stores the MSI files in the folder
C:Program Files (x86)Windows Kits8.1Windows Performance ToolkitRedistributables The 32Bit version is named
WPTx86-x86_en-us.msi, the 64Bit version is named WPTx64-x86_en-us.msi. The 3rd file (WPTarm-arm_en-us.msi) is needed for ARM based tablets/notebooks which run Windows RT. You can store them and use them on a different PC. This avoids
to download the files over and over again.

 To learn more about the Windows Performance Tools go to the Windows Performance Analysis Developer Center
.
 See also: Windows Performance Toolkit

This post is part 2 of a 3-part series on monitoring the health and performance of the Windows operating system. Part 1 details key Windows performance counters, events, and services to monitor; this post covers data collection with native tools; and Part 3 explains how to monitor Windows with Datadog. For an in-depth webinar and Q&A session based on this series, check out this slide deck and video.

Windows offers a number of native tools to collect all of the metrics and events mentioned in part 1 of this series. In many cases, Windows offers more than one tool for the task. In this post, we will cover a few ways to access Windows metrics and performance data, using the tools that come bundled with Windows Server 2012.

Though there are many tools built into Windows Server 2012 for monitoring system health and performance, we will focus on a limited subset in this article.

Non-GUI tools:

• Powershell
• WMI and Powershell

GUI tools:

• Performance Monitor (Metrics)
• Reliability Monitor (Events)
• Resource Monitor (Metrics)
• Service snap-in (Services)
• Server Manager (Metrics, events, services)
• Task Manager (Metrics)

Powershell

Powershell is one of the most dynamic and powerful ways to get information about a Windows system (and, with Powershell available on other platforms, other systems as well).

Powershell commands are referred to as cmdlets, and follow a strict Verb-Noun naming convention. For example, Remove-Item is functionally similar to rm on Unix-like systems. A Powershell tutorial is beyond the scope of this article, but Microsoft has tutorials for the uninitiated.

All of the metrics and events listed in part one of this series can be collected with Powershell:

• CPU
• Memory
• Disk
• Network
• Events

Part of the, er, power of collecting metrics with Powershell is that you can choose between real-time performance data for spot-checking, or sampling metric values over time for historical trending (by using the -MaxSamples and -SampleInterval command line arguments).

Collecting performance metrics with Powershell using the Get-Counter cmdlet follows a straightforward syntax:

Get-Counter -Counter <Counter Class><Property Name>

If you’re unsure of a property name, you can retrieve a list of all properties by class with the following:

(Get-Counter -ListSet <Counter Class> ).Paths

For example, this command will display all of the properties of the Memory class:

(Get-Counter -ListSet Memory).Paths

CPU metrics

Memory metrics

Disk metrics

Network metrics

Events

You can also query the event log with Powershell. The query follows this format:

Get-EventLog -LogName <Name of log> `
-EntryType <Information|Warning|Error|SuccessAudit|FailureAudit> `
-After <MM/DD/YYYY> | Where-Object {$_.EventID -eq <EventID>} `
| Format-List

This query invokes the Get-EventLog cmdlet, with the log name, entry type, and start date as parameters. The output of that cmdlet is piped to Where-Object, a cmdlet that filters the piped value ($_) for objects whose EventIDs (.EventID) are equal to (-eq) the EventID we are searching for. The output is finally piped to Format-List which prints the output in a human-readable format.

For example, this query will show all security audit failure events with EventID 4625 (failed logon) from the Security log which occurred after 10/18/2016:

Get-EventLog -LogName Security -EntryType FailureAudit -After 10/18/2016 | Where-Object {$_.EventID -eq 4625} | Format-List

Category           : (12544)
CategoryNumber     : 12544
ReplacementStrings : {S-1-0-0, -, -, 0x0...}
Source             : Microsoft-Windows-Security-Auditing
TimeGenerated      : 10/19/2016 3:21:32 PM
TimeWritten        : 10/19/2016 3:21:32 PM
UserName           :

Index              : 1305543
EntryType          : FailureAudit
InstanceId         : 4625
Message            : An account failed to log on.

                     Subject:
                         Security ID:        S-1-0-0
                         Account Name:        -
                         Account Domain:        -
                         Logon ID:        0x0

                     Logon Type:            3

                     Account For Which Logon Failed:
                         Security ID:        S-1-0-0
                         Account Name:        MATT
                         Account Domain:

                     Failure Information:
                         Failure Reason:        %%2313
                         Status:            0xc000006d
                         Sub Status:        0xc0000064

Services

All of the services listed in part one of this series can be collected via Powershell. The query follows this format:

Get-Service | where {$_.DisplayName -eq "Windows Update"}

The above command displays the status of the Windows Update service:

Status   Name               DisplayName
------   ----               -----------
Stopped  wuauserv           Windows Update

WMI + Powershell

Windows Management Instrumentation (WMI) is a set of extensions that provide a standardized interface through which instrumented components can be queried for information. WMI was introduced to make management of Windows computers easier, by providing a consistent interface across OS versions, while working alongside other popular management interfaces like SNMP or Desktop Management Interface (DMI).

The introduction of Powershell (and the Get-WmiObject cmdlet specifically) has made WMI much easier to use. Before, accessing system information via WMI required some boilerplate in VBScript or another scripting language. But with Powershell, WMI can be queried in one line.

If you’re just getting started with Windows monitoring, Powershell is generally a simpler way to access performance metrics. But since WMI is still in widespread use, we’ve included the equivalent WMI commands here for completeness. You can get started with iterating through all of the available WMI Classes by opening up a Powershell window and running the following:

$name = "Win32_perfformatteddata" 
$WMIClasses = Get-WmiObject -List | Where-Object {$_.name -Match $name}

foreach($class in $WMIClasses)
{
$class.Name
}

Executing the above commands will result in substantial output, truncated and reproduced below:

[...]
Win32_PerfFormattedData_PerfDisk_LogicalDisk
Win32_PerfFormattedData_PerfDisk_PhysicalDisk
Win32_PerfFormattedData_PerfNet_ServerWorkQueues
Win32_PerfFormattedData_PerfOS_Cache
Win32_PerfFormattedData_PerfOS_Memory
Win32_PerfFormattedData_PerfOS_Objects
Win32_PerfFormattedData_PerfOS_PagingFile
Win32_PerfFormattedData_PerfOS_Processor
Win32_PerfFormattedData_PerfOS_System

You may recognize some of the names from Powershell commands, like Win32_PerfFormattedData_PerfDisk_LogicalDisk. To list performance counters for the entire LogicalDisk class, you can run a command like:

Get-WmiObject -Query "Select * from Win32_perfformatteddata_perfdisk_LogicalDisk"

which will output counters for all logical disks on the server:

[...]
AvgDiskBytesPerRead     : 0
AvgDiskBytesPerTransfer : 0
AvgDiskBytesPerWrite    : 0
AvgDiskQueueLength      : 0
AvgDiskReadQueueLength  : 0
AvgDisksecPerRead       : 0
AvgDisksecPerTransfer   : 0
AvgDisksecPerWrite      : 0
AvgDiskWriteQueueLength : 0
CurrentDiskQueueLength  : 0
DiskBytesPersec         : 0
DiskReadBytesPersec     : 0
DiskReadsPersec         : 0
DiskTransfersPersec     : 0
DiskWriteBytesPersec    : 0
DiskWritesPersec        : 0
FreeMegabytes           : 100400
Name                    : C:
PercentDiskReadTime     : 0
PercentDiskTime         : 0
PercentDiskWriteTime    : 0
PercentFreeSpace        : 77
PercentIdleTime         : 96

The table below lists the WMI queries to collect all of the metrics from part one of this series.

Performance Monitor (tracks counters)

Polling for performance data with WMI or Powershell is good for collecting data with scripts or other automated means. But without some means of visualizing that data, it can be hard to spot trends and issues from a sea of numbers.

Windows Performance Monitor provides a built-in interface for graphing performance counters, either in real-time or from logs of historical data. You can graph data from both local and remote hosts, as well. Performance counters are organized by class and have human-readable names as well as detailed metric descriptions.

Resource Monitor

Windows Resource Monitor is very similar to the well-known task manager, but differs in the amount of information it makes available. The resource monitor is a very good starting point for investigation; it can surface nearly all of the metrics listed in part one of this series. Its main strength is that it provides a real-time graphical interface to access CPU, memory, disk, and network metrics, allowing you to see at a glance which particular process is hogging the disk, for example.

Reliability Monitor

Windows Reliability Monitor is a graphical interface that surfaces system events and organizes them chronologically and by severity.

From this list view, you can right-click a specific event and check for a solution to the issue, view a solution to the issue, or view technical details for more information on the state of the system at the time of the event. Selecting “View technical details” will display more detailed information on the issue, like problem event name, where the error occurred, and more.

Selecting “Check for a solution” will prompt you to send details of the event to Microsoft for analysis. If you’re lucky, your problem may have a known solution and “View solution” will no longer be grayed out; clicking it will open the solution (on Microsoft’s website) in your browser.

Service snap-in

The Services management snap-in (services.msc) is an indispensable tool that provides administrators with a graphical interface to monitor and manage services on Windows machines.

With sortable rows, you can see at a glance the state, startup type, and execution privileges of all services on your system.

Right-clicking on any service and selecting Properties will give you more detail on the selected service, including a list of its dependencies and the services that depend on it.

Last but not least, you can also set alerts on service failure by selecting the Recovery tab and changing First, Second, or Subsequent failure actions to “Run a Program” and setting the program to an email script or other response.

Windows Server Manager

Like the reliability monitor, Server Manager surfaces information from disparate sources, all in a single pane.

With Server Manager, you can access a high-level overview of resource consumption, service status, and events, aggregating information from both local and remote hosts.

Also included in Server Manager is the Windows Server Best Practices Analyzer. Windows Server Best Practices Analyzer (BPA) is a tool unique to Windows Server 2008 R2 and Windows Server 2012 R2. BPA analyzes the roles enabled on your host, and provides recommendations based on Windows server management best practices. It can identify issues with configuration, security, performance, policies, and more.

Task manager

On a local machine, the venerable task manager provides immediate access to a view of what’s going on under the hood. In addition to a list of running processes, the task manager also includes tabs with more information on hardware performance and running services.

Honorable mention: Process Explorer

In the same vein as the Task Manager is Process Explorer, a third-party tool in the versatile Sysinternals Suite. Since it is not included in Windows Server 2012, we won’t go into too much detail here. However, it is worth mentioning as a more full-featured alternative to the built-in Task Manager.

Some of its noteworthy features include:

• view DLLs and handles loaded/opened by process
• dynamically modify process priority
• submit hash of process executable to VirusTotal.com for analysis
• interactive dependency visualizer (see below)

From collection to action

In this post we’ve covered several ways of surfacing Windows Server 2012 R2 metrics, events, and service information using simple, lightweight tools already available on your system.

For monitoring production systems, you will likely want a dynamic solution that not only ingests Windows Server performance metrics, but metrics from every technology in your stack.

At Datadog, we’ve developed integrations with more than
600 technologies, including Windows, so that you can make your infrastructure and applications as observable as possible.

For more details, check out our guide to monitoring Windows Server 2012 R2 performance metrics with Datadog, or get started right away with a free trial.

The Windows Performance Toolkit allows Administrators a keen insight into the startup and login process. In this four part series, we will dive into these tools and fix common performance issues. Part 1 covers downloading and installing the Windows Performance Toolkit.

Ever heard this one, “My computer is slow.” Or how about, “It is taking forever to login.” If you answered no to either of those comments, I envy you! These issues are incredibly frustrating to fix because of the lack of data. Most of the time, you are lucky to get an error code or a log. Instead of brushing these complaints off as user perception or older hardware, let’s dig into some troubleshooting and use the Windows Performance Toolkit!

Download

In the days of old, every single troubleshooting tool (almost) always had its own download and separate installation. Thankfully, Microsoft has combined (almost) all of the tools needed for client Assessment and desktop Deployment into a single Kit named Windows ADK. You can download the Windows ADK here.

Installation

After launching the ADK setup, proceed to the feature selection screen. If you are only using the Performance toolkit, just select the Windows Performance Toolkit option. In my environment, I find that I use the Windows Assessment Toolkit quite a bit as well so I also install it as a default option.

Installing the Windows Performance Toolkit

As a note, if you followed our Deploying Windows 8 Series – you might already have ADK installed. It is perfectly fine to run the Deployment Tools, ACT, or any of the other ADK features with the Performance toolkit.

Now that you have the Windows Performance Toolkit installed on your management machine, you will also want to install it on a test client that exactly mimics your organization. This test client, preferably a virtual machine, is about to undergo a lot of changes!

WPR, WPA, WHY so many acronyms?

After installation, you will now have a few new tools at your disposal. The first tool is the Windows Performance Recorder (WPR).

The Windows Performance Recorder tool

This tool has been streamlined and replaces the functionality of two past tools: Xpref and Xbootmgr. Because a lot of existing performance documentation still reference these two obsolete tools, it is important to substitute WPR in their place.

You will use WPR to capture performance related issues on client machines. Most of the time, we will use the Reboot Cycle performance scenario to test clients. After our information has been captured, WPR will save and compress that information into a single trace file. This file is normally has an .ETL extension.

Your second main tool is the Windows Performance Analyzer (WPA). This tool will be ran on your management machines. Although you can run it on a client, you’ll likely get improved performance on administrative machines (and will find the graphs easier to read).

Let’s launch WPA and see what we get:

Windows Performance Analyzer after first launch

Not much to see here! That’s is because we have to open a trace first. After opening a trace file, we get:

The Windows Performance Analyzer with a Trace Opened

Much more informative! On the left, we have our graph explorer. This areas are broken up into four categories. The first category, System Activity, includes graphs for Services, Processes, phases, etc. It is our high level center where your initial troubleshooting will take place. The next four categories, Computation, Storage, and Memory, address potential resource bottlenecks. The Computation center shows graphs related to CPU usage, Storage shows hard drive/write usage, and memory – well, show memory usage. Later, we are going to look at specific graphs in a lot more detail.

In Part 2, we are going to create a baseline trace and start troubleshooting a slow startup! If you have any questions at all, just leave us a comment.

Slow pages lose users: research from Bing and Google indicates that delays as small as half a second can impact business metrics. To build fast sites, developers need powerful tools to analyze the performance of their sites and debug issues. In-browser tools like the F12 Developer Tools are a great start and the primary tools for analyzing what’s happening behind the scenes when a page slows down. However, some scenarios require measuring performance characteristics in the context of other applications and the operating system itself. For these scenarios, we use the Windows Performance Toolkit.

https://channel9.msdn.com/Events/WebPlatformSummit/edgesummit2016/ES1606/

The Windows Performance Toolkit (WPT) is a powerful tool to analyze both app and operating system performance, and is used extensively by the Microsoft Edge performance team for in-depth analysis. The toolkit includes the Windows Performance Recorder, a tool for recording traces, and the Windows Performance Analyzer, a tool for analyzing traces. It uses a fast, non-impactful trace logging system called Event Logging for Windows (ETW) to sample stacks and collect app or OS-specific events.

Since WPT can record and analyze CPU and memory usage for all Windows applications, WPT can be used for tasks that in-browser developer tools can’t, like analyzing GPU usage, disk usage, and system wide memory usage. In addition, WPT can be used to analyze performance in context of the system – for example, identifying the impact of virus scanners or performing cross-window analysis or measuring across multiple tabs in multiple processes.

In this post, we’ll introduce you to WPT with a very basic step-by-step example, in which we’ll use WPT to debug a simple performance issue. This example and analysis technique can be used with the in-browser F12 Developer Tools as well, but serve as a simple introduction to WPA. In later posts, we plan to explore more sophisticated analysis techniques using the capabilities described above.

Installing the Windows Performance Toolkit

The WPT is available as a component of the Windows Assessment and Deployment Kit, available for free from the Microsoft Dev Center. This kit includes a number of additional tools, however we’ll be focusing on just the Windows Performance Toolkit for the purposes of this post.

Gathering a performance trace

The first step to analysis using WPT is gathering a performance trace. In this step, we’re recording the performance characteristics of activity across the system to identify potential culprits inside and outside of the browser. For the purposes of this tutorial, we built a simple demo page with some artificial performance problems. We’ll use this page for the trace and analysis below.

Prepare Windows Performance Recorder

To minimize noise in the recording, you should close all applications besides the browser tabs you intend to analyze for this step. Launch the Windows Performance Recorder application (installed with the Windows Performance Toolkit”) and select the “Edge Browser” and “HTML Responsiveness analysis” profiles under “More options” (as seen in the screenshot below). These settings will configure Windows Performance Recorder to gather the metrics most useful for Edge performance analysis, including subsystem stack attribution, JavaScript symbols and networking, and frame-by-frame information.

Identify scenarios

Before starting the trace, it’s best to identify the scenarios you’re analyzing and try to keep them as atomic as possible. Imagine a site with performance problems when loading the page (from start of navigation to page load complete), scrolling, and selecting something in a table. In this case it’s best to record traces for each of the three scenarios separately to keep the analysis focused for each issue.

If a scenario involves navigating to a site, consider beginning the scenario at about:blank. Starting at about:blank will avoid the overhead of the previous page. If it involves navigating away from a site, navigate to about:blank to complete the scenario. This will keep the noise of other sites out of the trace unless the specific interaction between sites is the issue under investigation.

In our example, the scenario is a simple page load. We’ll navigate the browser to about:blank, and then navigate to the example page (you can download the sample on the Performance Analysis Test Drive here).

Record and execute scenarios

Once you’re ready to gather a trace for a given scenario, click “Start” to begin recording and execute the scenario you intend to measure. In our example, we’ll simply perform the navigation to our sample page.

As the browser navigates to and loads the demo page, Windows Performance Recorder will collect information about all programs running on the computer while the trace is recording, with minimal impact on active processes. As soon as you’ve finished executing the scenario (page load is complete), click “Stop” immediately and save the trace. This helps minimize the noise in your analysis as well as keep the trace file to a manageable size, as ETL files can get quite large.

Analyzing a performance trace

To analyze the trace, open Windows Performance Analyzer and open the ETL file generated in the previous step. You may need to load symbols for the trace, which can involve a large download. We recommend restricting the symbols loaded to Microsoft Edge and web apps, unless you have a specific additional need. You can do this by selecting “Trace/Configure Symbol Paths” from the WPA menu. Here you can use the Load Settings menu to restrict symbols to MicrosoftEdgeCP.exe and WWAHost.exe (as seen in the screenshot below).

The symbols will be cached to disk and future traces will load symbols much more quickly. After symbols begin loading, apply the HTML Analysis Profile by selecting “Profiles/Apply” from the menu then clicking “Browse Catalog.” Choose HtmlResponsivenessAnalysis.wpaProfile. For nearly all web site investigations, we recommend starting with this profile since it includes the key graphs and tables necessary for analyzing the performance of a website. This profile will configure four tabs (Big Picture, Frame Analysis, Thread Delay Analysis, and Trace Markets) loaded with data and graphs useful for analysis (as seen in the screenshot below).

For more on configuring these views and the functions of each tab, see our “Analyzing a trace” walkthrough on Microsoft Edge Dev. For the purposes of this post, we’ll assume you have the views configured to your liking and walk through a single performance analysis technique – top-down analysis.

Top-down Performance Analysis

Once you have recorded and loaded a trace for analysis, there are a number of techniques to investigate performance. For this post, we’ll walk through a technique called top-down performance analysis, which is focused on finding the most obvious and impactful performance problems on a page – literally investigating operations from the top down by impact in milliseconds. This general technique can be used in many tools, including the JavaScript view in the F12 Developer Tools, as well as in WPA.

To perform this analysis, begin with in Windows Performance Analyzer’s “Frame Analysis” tab. Under CPU Usage, sort the collapsed nodes by decreasing total CPU time (weight in milliseconds). From here, review each node and look up the corresponding source code to evaluate the potential reduction in call counts until CPU time breaks into smaller pieces. Note that this step is easiest with unminified code.

On a complex page, you should apply this technique to each major component independently. Many site have several separate components competing for CPU and network time, which the top-down analysis technique will help to highlight.

Sample analysis

Using the top-down analysis technique, let’s walk through the analysis of the demo page which we recorded above. For the purposes of this example, we’ll use a performance issue that is relatively simple and contrived.

Follow the instructions above to open the recording and then open the trace of our sample page in Windows Performance Analyzer. After doing so, go to the Frame Analysis tab and scroll down to the CPU Usage (Attribute) graph. Highlight the portion of time that has a visible graph and right click to Zoom in. This will filter the information in the CPU Usage (Sampled) table down to only that section of time. Next, remove the Thread ID and Activity to get a bit more space to view the Stack.

We’ll begin our Top-down Analysis here by clicking in the UI Thread root in CPU Usage (Sampled) seen in the screenshot below. Expand the tree and review what is occurring until you find the first bit of JavaScript—this should be topdown.js!Global code-1:1 (line 1, column 1). This appears to call down into runOnParse-164:18 (line 164, column 18) which then calls into initalizeHashtags-96:26 (line 96, column 26).

If we look into the code referenced here, we can observe that Global declares a few consts, creates a number of functions and calls runOnParse. So far so good! Continuing down the stack, we’ll next look into runOnParse. This appears well structured:

Next, we’ll look into intializeHashtags. Reviewing the code, we observe a loop that creates the hashtags. We also can observe a line at the end of the loop with a comment (lines 111-112) that it should run after the loop where all hashtags are created.

This is our problem code! Moving setWidthOfCells outside of the loop will run it after all hash tags are created, running only once instead of once for every tag, resulting in a dramatic performance improvement.

This is a relatively simple and contrived example, but illustrates the principle well. Top-down performance analysis is just one technique—while it’s a good start to debugging many simply performance problems, WPT enables more sophisticated approaches as well. Some other techniques include Bottom-up DOM API Analysis, which groups all of the API calls and then looks at the callers to find important optimizations, as well as Synchronous Layout Reduction. We plan to explore some of these techniques in more detail in future posts and demos.

Try out the Windows Performance Toolkit for yourself!

The best way to get acquainted with WPT is to try it out for yourself! We’ve published the slow web page used in the above example to our demo site and GitHub so you can follow along to identify the performance problem – see my video from Edge Web Summit to follow this debugging in real time.

WPT is powerful but it can be a steep learning curve – if you have any questions, don’t hesitate to reach out! You can get in touch via the comments below or @MSEdgeDev on Twitter with any questions or comments.

– Todd Reifsteck, Senior Program Manager, Microsoft Edge