This chapter covers Windows Performance Monitor, a critical tool for identifying system bottlenecks in Windows operating systems. For the CompTIA A+ 220-1102 exam, Performance Monitor falls under Domain 1.0 (Operating Systems), specifically Objective 1.2: Given a scenario, use Windows appropriate Microsoft command-line tools. While not a command-line tool itself, Performance Monitor is often accessed via `perfmon` from the command line, and understanding its functionality is essential for troubleshooting performance issues. Expect 2-4 exam questions that test your ability to interpret performance counters, configure Data Collector Sets, and identify which counter to use for a given symptom. Mastery of this tool separates a technician who guesses at problems from one who diagnoses with data.
Jump to a section
Think of Windows Performance Monitor as the black box flight recorder in an aircraft. Just as a flight recorder continuously samples dozens of parameters—altitude, airspeed, engine RPM, fuel flow—every second and stores them for later analysis, Performance Monitor samples hundreds of Windows performance counters (like CPU usage, disk queue length, memory pages/sec) at a configurable interval (default 1 second). When a pilot encounters a problem, they download the flight data and look for the exact moment a parameter exceeded a threshold (e.g., engine temp spiked). Similarly, when a Windows system slows down, you use Performance Monitor to capture data logs, then examine the graph or report to find when % Processor Time hit 100% or Available MBytes dropped to near zero. The key mechanistic parallel: both systems sample at regular intervals, store timestamped data, and allow post-event analysis to pinpoint the root cause. You wouldn't try to diagnose a plane crash by watching the altimeter in real time—you'd review the recorded data. Same with Windows: you create a Data Collector Set (like programming the flight recorder), let it run during the problem period, then analyze the saved log. The analogy holds because both systems are designed for forensic analysis after the fact, not real-time troubleshooting, although Performance Monitor can also show live data (like a cockpit instrument panel). The exam tests your ability to configure the 'recorder' and interpret the 'flight data' to identify resource bottlenecks.
What is Windows Performance Monitor and Why It Exists
Windows Performance Monitor (perfmon) is a Microsoft Management Console (MMC) snap-in that provides real-time and historical performance data for Windows systems. It exists because administrators and support technicians need a way to quantify system performance—not just feel it. Without perfmon, you'd rely on subjective observations like 'the computer feels slow.' Performance Monitor replaces guesswork with objective metrics called performance counters. Each counter measures a specific aspect of system activity: processor utilization, memory usage, disk I/O, network throughput, and more. The tool is built into all modern Windows editions (Windows 10, 11, Server 2016/2019/2022) and is accessible from the Administrative Tools folder or by running perfmon from the command line.
How Performance Monitor Works Internally
Performance Monitor doesn't 'watch' the system in real time by intercepting every operation. Instead, it relies on the Windows Performance Counter infrastructure. Performance counters are provided by system components (kernel, drivers, services) that expose data through a standardized API. When you add a counter in Performance Monitor, the tool queries that API at a specified interval (default 1 second for live view, configurable for logging). The query returns a numeric value—for example, \Processor(_Total)\% Processor Time returns the percentage of time the processor was busy executing non-idle threads during the sample interval.
Here's the key mechanism: counters are either instantaneous (snapshot at the moment of query) or averaged over the sample interval. For instance, \Memory\Available MBytes is instantaneous—it reports how many megabytes of RAM are immediately available at that second. In contrast, \Processor(_Total)\% Processor Time is an average over the last sample interval. The system calculates it by measuring how much of the interval was spent in the idle thread versus active threads.
Performance Monitor can operate in three modes:
- Real-time monitoring: Displays counters as line graphs, histograms, or numeric reports. Data is sampled every second by default, but you can change the sample interval in the properties.
- Data Collector Sets (DCS): A collection of counters, sampling intervals, and file locations for logging. You can create a DCS to log performance data to a file (.blg binary log or .csv text). This is essential for historical analysis.
- Reports: After a DCS runs, you can view the logged data as a report. Performance Monitor also includes pre-built System Diagnostics and System Performance reports that collect data for a specified duration (default 60 seconds) and generate an HTML report with analysis.
Key Components, Values, Defaults, and Timers
#### Performance Counters
There are thousands of counters, but the 220-1102 exam focuses on a handful. Memorize these:
- Processor:
- \Processor(_Total)\% Processor Time: Total CPU utilization across all cores. Sustained >85% indicates a CPU bottleneck.
- \Processor(_Total)\% Interrupt Time: Time spent handling hardware interrupts. High values (>15%) suggest a failing hardware device or driver.
- Memory:
- \Memory\Available MBytes: Amount of physical RAM available for allocation. Below 10% of total RAM indicates memory pressure.
- \Memory\Pages/sec: Rate at which pages are read from or written to disk to resolve hard page faults. High values (>1000) indicate excessive paging (memory bottleneck).
- Disk:
- \PhysicalDisk(_Total)\% Disk Time: Percentage of time the disk was busy servicing read/write requests. Sustained >90% indicates a disk bottleneck.
- \PhysicalDisk(_Total)\Avg. Disk Queue Length: Number of I/O requests waiting for the disk. Should be <2 per spindle (for HDDs); for SSDs, queue length can be higher but still indicates congestion if >2 per physical disk.
- Network:
- \Network Interface(*)\Bytes Total/sec: Total bytes sent and received per second. Compare to the interface bandwidth (e.g., 1 Gbps = 125 MB/s). Sustained >80% suggests a network bottleneck.
#### Data Collector Sets
A Data Collector Set bundles performance counters, sampling intervals, and schedule into a reusable package. Key defaults:
Sample interval: Default is 15 seconds for DCS (versus 1 second for live view). You can set it as low as 1 second or as high as days.
Log format: Binary (.blg) by default; can be changed to comma-separated (.csv) or tab-separated (.tsv). Binary is smaller and faster.
Maximum size: Default is 1 GB per log file. When reached, the DCS can stop, overwrite, or create a new file.
Schedule: You can set a start time (absolute or relative) and stop condition (duration, manual, or at a specific time).
#### Built-in Reports
System Diagnostics: Runs for 60 seconds, collects a defined set of counters, and generates an HTML report with a traffic-light rating (green/yellow/red) for each resource. Red indicates a problem.
System Performance: Similar but focuses on performance counters for a longer duration (default 60 seconds).
Configuration and Verification Commands
To open Performance Monitor:
- GUI: Start > Administrative Tools > Performance Monitor, or type perfmon in Run.
- Command line: perfmon /res opens Resource Monitor (a subset of performance data). perfmon /rel opens Reliability Monitor (shows system stability over time).
- MMC: perfmon /sys opens the Performance Monitor snap-in in a new MMC console.
To create a Data Collector Set from the command line, use logman:
logman create counter MyPerfLog -c "\Processor(_Total)\% Processor Time" "\Memory\Available MBytes" -o "C:\PerfLogs\MyLog.blg" -f bincirc -si 15 -v mmddhhmmThis creates a circular binary log that collects those two counters every 15 seconds, with automatic file naming based on month/day/hour/minute.
To start and stop a DCS:
logman start MyPerfLog
logman stop MyPerfLogTo view the log as a report:
Open Performance Monitor, click Reports, navigate to User Defined, and select your log.
Or use relog to convert the binary log to CSV: relog MyLog.blg -f csv -o MyLog.csv
How Performance Monitor Interacts with Related Technologies
Performance Monitor is closely related to:
- Task Manager: Provides a quick snapshot of current CPU, memory, disk, and network usage. Performance Monitor offers deeper historical analysis.
- Resource Monitor (resmon): Shows real-time data with per-process breakdowns for CPU, memory, disk, and network. Accessible from Performance Monitor's toolbar or by running resmon.
- Reliability Monitor (perfmon /rel): Tracks system stability over time, marking critical events (crashes, hangs) and application failures. Useful for correlating performance degradation with system changes.
- Event Viewer: Performance Monitor can trigger Data Collector Sets based on events. For example, you can configure a DCS to start when a specific event ID is logged.
- Windows Performance Toolkit (WPT): Part of the Windows Assessment and Deployment Kit (ADK), used for advanced performance analysis (e.g., boot performance, application launch). Not on the 220-1102 exam but good to know.
Common Exam Scenarios
The 220-1102 exam will present a symptom (e.g., 'System is slow when opening applications') and ask which counter to check. The correct answer is typically \Memory\Pages/sec for memory pressure, \PhysicalDisk\Avg. Disk Queue Length for disk bottleneck, or \Processor\% Processor Time for CPU. Another common question: 'Which tool allows you to log performance data over time?' Answer: Data Collector Set. 'Which command opens Performance Monitor?' Answer: perfmon. 'Which counter indicates memory pressure?' Answer: \Memory\Available MBytes (when low) or \Memory\Pages/sec (when high).
Identify the Symptom
Before opening Performance Monitor, clearly define the problem: is the system slow during boot, when launching applications, during file transfers, or when running a specific program? The symptom guides which counters to monitor. For example, slow application launches often point to disk I/O (high Avg. Disk Queue Length) or memory (high Pages/sec). Slow file transfers suggest network or disk bottlenecks. General sluggishness may be CPU or memory. Write down the symptom and the time it occurs. This step is critical because Performance Monitor can collect thousands of counters, but you only need a few. On the exam, you'll be given a symptom and asked which counter to check first.
Open Performance Monitor
Press Windows+R, type `perfmon`, and press Enter. The Performance Monitor MMC snap-in opens. Alternatively, you can open it from Administrative Tools. The default view shows a real-time graph with no counters selected. You'll see three sections in the left pane: Performance Monitor (the live graph), Data Collector Sets, and Reports. For real-time troubleshooting, click on 'Performance Monitor' under 'Monitoring Tools'. For logging, you'll work with Data Collector Sets. The exam expects you to know that `perfmon` is the command to open this tool, not `resmon` (Resource Monitor) or `taskmgr` (Task Manager).
Add Relevant Counters
Click the green plus (+) icon on the toolbar to open the Add Counters dialog. Select the computer (local or remote) and browse the counter categories (Processor, Memory, PhysicalDisk, Network Interface, etc.). Expand the category and select the specific counter(s). For example, to check CPU usage, select `Processor` > `% Processor Time` and then select `_Total` instance (all cores combined). Click Add, then OK. The graph now displays the counter in real-time. For memory, add `Memory` > `Available MBytes`. For disk, add `PhysicalDisk` > `% Disk Time` and `Avg. Disk Queue Length`. The exam tests your ability to choose the correct counter for a given symptom. A common trap: selecting `% Disk Time` for a disk bottleneck when `Avg. Disk Queue Length` is more accurate (especially on SSDs where % Disk Time can be misleading).
Observe Real-Time Data
Watch the graph for a few minutes while reproducing the problem. The graph updates every second by default. Look for sustained high values: CPU >85%, Available MBytes <10% of total RAM, Avg. Disk Queue Length >2 per physical disk, Network Interface % Utilization >80%. The graph's scale adjusts automatically; you can change the vertical scale by right-clicking the graph and selecting Properties. Pay attention to the time axis—if the problem lasts only a few seconds, the real-time graph may not capture it at the default 1-second interval. For intermittent issues, you need to log data. The exam may ask: 'Which counter shows a value above 90% indicating a bottleneck?' Answer: `% Processor Time` or `% Disk Time`.
Create a Data Collector Set for Logging
For intermittent or historical analysis, create a Data Collector Set. In the left pane, expand 'Data Collector Sets', right-click 'User Defined', select New > Data Collector Set. Name it (e.g., 'Performance Log'). Choose 'Create manually (Advanced)'. Select 'Performance Counter' as the type. Add the same counters as before. Set the sample interval to 15 seconds (default) or lower (e.g., 5 seconds) for short problems. Choose a location to save the log (default is `%SystemDrive%\PerfLogs\Admin\`). Finish the wizard. Then right-click the new DCS and select Start. Reproduce the problem while the DCS is running. After the problem occurs, right-click and Stop. The exam tests your ability to create a DCS for logging and understanding that the default sample interval is 15 seconds, not 1 second (which is for live view).
Analyze the Logged Data
After stopping the DCS, navigate to Reports > User Defined > your DCS name. The report shows the same counters as a graph, but you can zoom into the time period of interest. Click and drag on the graph to zoom. Look for spikes or sustained high values. You can also export the data to CSV for analysis in Excel. Right-click the report and select Save As to export. The exam may ask: 'Where do you view logged performance data?' Answer: Reports. 'What is the default log format?' Answer: Binary (.blg). 'What tool converts .blg to CSV?' Answer: `relog`. Knowing these details helps you eliminate wrong answers.
Enterprise Scenario 1: Virtual Desktop Infrastructure (VDI) Performance Degradation
A company runs 500 virtual desktops on a VMware vSphere cluster with Windows 10 VMs. Users complain of slow logins and application launches between 8:00 AM and 9:00 AM. The IT team suspects a storage bottleneck. They deploy a Data Collector Set on a representative VDI host logging the following counters every 10 seconds: \PhysicalDisk(_Total)\% Disk Time, \PhysicalDisk(_Total)\Avg. Disk Queue Length, \Memory\Pages/sec, and \Network Interface(*)\Bytes Total/sec. After a week of logging, they analyze the reports and discover that Avg. Disk Queue Length exceeds 10 per physical disk during the login storm, while % Disk Time is 100% but the disks are SSDs (so % Disk Time is not a reliable indicator). The team identifies that the storage array's 10 Gbps links are saturated, causing queuing. They upgrade the links to 25 Gbps and add more SSDs. Performance Monitor provided the evidence needed to justify the hardware investment. Misconfiguration pitfall: Setting the sample interval too high (e.g., 1 hour) would miss the 30-minute login spike entirely. Setting it too low (e.g., 1 second) would generate gigabytes of data per day, overwhelming the log file size limit.
Enterprise Scenario 2: Memory Leak in a Line-of-Business Application
A financial firm has a Windows Server 2019 running a proprietary trading application. Over time, the server's memory usage grows until the system becomes unresponsive, requiring a reboot every two weeks. The support team uses Performance Monitor to create a Data Collector Set that logs \Process(MyApp)\Working Set, \Memory\Available MBytes, and \Memory\Pages/sec every 5 minutes for 24/7 logging. After a few days, the report shows that the application's Working Set increases steadily while Available MBytes drops from 8 GB to 512 MB over 10 days. Pages/sec spikes when Available MBytes falls below 1 GB. The team identifies a memory leak in the application and contacts the vendor for a patch. In the meantime, they configure a scheduled task to restart the application service daily. Performance Monitor's logging capability was essential for proving the leak over time. Common mistake: Using real-time monitoring instead of logging would require someone to watch the screen for days, which is impractical. The exam expects you to know that Data Collector Sets are for long-term data collection.
Scenario 3: Network Bandwidth Saturation
A school district's network becomes slow every afternoon when students access streaming video. The network administrator runs Performance Monitor on a domain controller and a file server, logging \Network Interface(*)\Bytes Total/sec and \Network Interface(*)\Packets/sec every 15 seconds. The report shows that the network interface on the file server is saturated (Bytes Total/sec consistently at 125 MB/s for a 1 Gbps link) between 1:00 PM and 3:00 PM. The admin uses this data to implement Quality of Service (QoS) policies to limit streaming traffic and upgrade the link to 10 Gbps. Performance Monitor provided the historical data needed to justify the upgrade. A common pitfall: Forgetting to log the correct network interface—on servers with multiple NICs, the counter must be selected per interface, not the _Total instance (which may sum all interfaces and overestimate utilization).
Exam Objectives and Alignment
This topic aligns with CompTIA A+ 220-1102 Objective 1.2: 'Given a scenario, use Windows appropriate Microsoft command-line tools.' While Performance Monitor is a GUI tool, it is invoked from the command line via perfmon. The exam expects you to know:
The command to open Performance Monitor: perfmon.
The command to open Resource Monitor: resmon.
That perfmon /rel opens Reliability Monitor.
That perfmon /sys opens the Performance Monitor snap-in.
The logman command for creating and managing Data Collector Sets from the command line.
The relog command to convert binary logs to CSV.
Common Wrong Answers and Traps
Trap 1: Confusing Performance Monitor with Resource Monitor. A question may ask: 'Which tool shows real-time per-process CPU, memory, disk, and network usage?' The correct answer is Resource Monitor (resmon), not Performance Monitor. Performance Monitor shows counters but not per-process breakdowns by default. Candidates often choose Performance Monitor because it's more familiar.
Trap 2: Assuming % Disk Time is always the best disk bottleneck indicator. On SSDs, % Disk Time can be 100% even with low queue depth because SSDs are fast and can service one request at a time. The better counter is Avg. Disk Queue Length. The exam might present a scenario with an SSD and ask which counter to use—the answer is Avg. Disk Queue Length, not % Disk Time.
Trap 3: Forgetting that the default sample interval for Data Collector Sets is 15 seconds, not 1 second. A question might ask: 'How often does a Data Collector Set sample by default?' The answer is 15 seconds. Many candidates think it's 1 second because that's the live view default.
Trap 4: Choosing Memory\Available MBytes when the symptom is excessive paging. While low Available MBytes indicates memory pressure, the direct indicator of paging is Memory\Pages/sec. A question might ask: 'Which counter shows the rate of hard page faults?' Answer: Pages/sec.
Specific Numbers and Terms to Memorize
CPU bottleneck: % Processor Time > 85% sustained.
Memory pressure: Available MBytes < 10% of total RAM, or Pages/sec > 1000.
Disk bottleneck: Avg. Disk Queue Length > 2 per physical disk (HDD). For SSDs, queue length > 2 per disk is still concerning.
Network bottleneck: Bytes Total/sec > 80% of interface bandwidth.
Default DCS sample interval: 15 seconds.
Default log format: Binary (.blg).
Maximum log file size default: 1 GB.
Built-in reports: System Diagnostics (60 seconds), System Performance (60 seconds).
Edge Cases and Exceptions
Virtual machines: Inside a VM, performance counters may not reflect physical hardware accurately. For example, % Processor Time in a VM may show high usage even if the host CPU is idle, due to hypervisor scheduling. The exam does not focus on VM nuances, but be aware.
32-bit vs 64-bit counters: On 64-bit Windows, some counters may be limited to 32-bit values (e.g., Memory\Available MBytes maxes at 4 GB if using the 32-bit counter). Always use the 64-bit version on 64-bit systems.
Remote monitoring: Performance Monitor can connect to remote computers if the remote registry service is running and firewall rules allow. The exam may test that you need appropriate permissions.
Elimination Strategy
On exam questions, if you're unsure, eliminate options that are not performance counters (e.g., Event Viewer, Task Manager) or that don't match the symptom. For a disk bottleneck, eliminate CPU and memory counters. For a network issue, eliminate disk counters. If the question mentions 'log data over time,' the answer is Data Collector Set. If it says 'real-time per-process data,' the answer is Resource Monitor.
Performance Monitor is opened with the `perfmon` command; Resource Monitor with `resmon`.
Data Collector Sets log performance counters to a .blg file with a default sample interval of 15 seconds.
Key counters: \Processor(_Total)\% Processor Time (CPU), \Memory\Available MBytes (RAM), \PhysicalDisk(_Total)\Avg. Disk Queue Length (disk), \Network Interface(*)\Bytes Total/sec (network).
CPU bottleneck: % Processor Time >85% sustained.
Memory pressure: Available MBytes <10% of total RAM or Pages/sec >1000.
Disk bottleneck: Avg. Disk Queue Length >2 per physical disk (HDD).
Network bottleneck: Bytes Total/sec >80% of interface bandwidth.
Built-in reports (System Diagnostics, System Performance) run for 60 seconds by default.
Use `logman` to create and manage Data Collector Sets from the command line.
Use `relog` to convert .blg log files to .csv format.
These come up on the exam all the time. Here's how to tell them apart.
Performance Monitor
Provides real-time and logged performance data via counters.
Can log data for hours, days, or weeks using Data Collector Sets.
Focuses on system-wide resource counters (CPU, memory, disk, network).
Accessed via `perfmon` command.
Ideal for long-term trend analysis and historical comparisons.
Resource Monitor
Shows real-time per-process CPU, memory, disk, and network usage.
Cannot log data; only shows live snapshot.
Provides detailed per-process information (which process is using the disk, network endpoints).
Accessed via `resmon` command or from Performance Monitor toolbar.
Ideal for immediate troubleshooting of which process is consuming resources.
Mistake
Performance Monitor shows the same data as Task Manager.
Correct
Task Manager provides a real-time snapshot of current resource usage, but Performance Monitor can log data over time for historical analysis and includes hundreds of counters not available in Task Manager, such as `Memory\Pages/sec` and `PhysicalDisk\Avg. Disk Queue Length`. Task Manager shows CPU usage per process, but not interrupt times or system calls per second.
Mistake
Data Collector Sets log data every second by default.
Correct
The default sample interval for a Data Collector Set is 15 seconds, not 1 second. The 1-second interval is only for the real-time graph in Performance Monitor. Changing the DCS interval to 1 second can generate huge log files quickly and is not recommended for long-term logging.
Mistake
% Disk Time over 90% always indicates a disk bottleneck.
Correct
On SSDs, % Disk Time can be 100% even under light load because SSDs process I/O very quickly and the counter measures the percentage of time the disk was busy, not the queue depth. A better indicator for SSDs is `Avg. Disk Queue Length`. For HDDs, % Disk Time > 90% is a valid bottleneck indicator, but queue length is still more reliable.
Mistake
Performance Monitor can only monitor the local computer.
Correct
Performance Monitor can connect to remote computers as long as the Remote Registry service is running on the target and the necessary firewall rules (typically RPC) are configured. You can add counters from a remote computer by selecting 'Select counters from computer' and entering the computer name.
Mistake
The only way to log performance data is through Performance Monitor GUI.
Correct
You can create and manage Data Collector Sets from the command line using `logman`. For example, `logman create counter MyLog -c "\Processor(_Total)\% Processor Time" -o C:\PerfLogs\MyLog.blg -si 15` creates a log. You can also start/stop logs with `logman start` and `logman stop`. This is essential for scripting and automation.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Press Windows+R, type `perfmon`, and press Enter. Alternatively, you can open it from Administrative Tools in the Control Panel. The command `perfmon` works in all modern Windows versions. For Resource Monitor, use `resmon`. For Reliability Monitor, use `perfmon /rel`. The exam expects you to know these command differences.
Performance Monitor is for system-wide counter monitoring and logging over time. Resource Monitor is for real-time per-process resource usage (CPU, memory, disk, network). Performance Monitor uses counters like `% Processor Time`; Resource Monitor shows which specific process is using the CPU. Both are accessed from the command line: `perfmon` and `resmon`. For exam questions, if the scenario requires identifying which process is hogging resources, the answer is Resource Monitor.
Two key counters: `\Memory\Available MBytes` (low value indicates memory pressure) and `\Memory\Pages/sec` (high value indicates excessive paging). A general rule: if Available MBytes is less than 10% of total physical RAM, or if Pages/sec exceeds 1000, there is a memory bottleneck. The exam may ask specifically for 'pages per second' as the indicator of hard page faults.
Create a Data Collector Set in Performance Monitor. Right-click 'User Defined' under Data Collector Sets, select New > Data Collector Set, choose 'Create manually (Advanced)', select 'Performance Counter', add the desired counters, set the sample interval (default 15 seconds), choose a save location (default `%SystemDrive%\PerfLogs\Admin\`), and finish. Then right-click the DCS and click Start. To stop, right-click and click Stop. View the log under Reports.
The default sample interval is 15 seconds. This is different from the real-time graph in Performance Monitor, which defaults to 1 second. The exam may test this distinction. If you need more granular data, you can lower the interval to 1 second, but be aware that log files will grow much larger.
Use the `relog` command-line tool. For example: `relog C:\PerfLogs\Admin\MyLog.blg -f csv -o C:\PerfLogs\MyLog.csv`. This converts the binary log to a comma-separated values file that can be opened in Excel. The `-f` parameter specifies the output format (csv, tsv, bin). The exam may ask which tool converts .blg to CSV.
Yes, Performance Monitor can connect to remote computers. When adding counters, select 'Select counters from computer' and enter the computer name. The remote computer must have the Remote Registry service running and appropriate firewall rules (RPC) configured. You also need administrative privileges on the remote machine. The exam may test this capability.
You've just covered Windows Performance Monitor — now see how well it sticks with free 220-1102 practice questions. Full explanations included, no account needed.
Done with this chapter?