Is your PC running slow? Learn how to identify the problem with Perfmon in Windows.

PerfMon (Performance Monitor) is The ultimate tool for monitoring in WindowsPerfMon: Allows you to view real-time, long-term, and analyze performance metrics for CPU, memory, disk, network, and specific processes. Unlike Task Manager, PerfMon takes samples at regular intervals and logs to disk, making it ideal for hunting down problems that only surface after hours of running, such as memory overflows or resource leaks in services and applications.

In this article we show you how to use PerfMon. From choosing and understanding the right counters and adjusting chart sampling and scaling, to creating Data Collector Sets to log metrics to file (BLG/CSV.

What is PerfMon and when to use it?

 

Performance Monitor (PerfMon) is the native Windows counter viewer and recorder.. Presents metrics in the form of graphs and raw data obtained from system and application counters (e.g., from the .NET CLR or a specific process). Its biggest advantage over “fast” utilities such as Task Manager is that you can leave it running for hours or days, with periodic samples, to detect real trends (peaks, baselines, sustained growth).

PerfMon is crucial for diagnose memory growth, handle or thread leaks, and isolate problematic components by running specific tests. For example, if you suspect a memory leak, you'll enable counters like Private Bytes, Handle Count, and Thread Count for the affected process, along with .NET CLR Memory counters like # Bytes in all Heaps and Gen 2 heap size for .NET applications, to see if the growth is occurring during or outside of the GC.

Ways to open PerfMon and specialized modes

 

You can open PerfMon from the Start menu, search for “performance” or “perfmon” and run as administrator when you go to create logs or query remote computers.

If you prefer the Command line (Win+R or CMD), you have very useful direct modes with the following syntax:

perfmon </res|report|rel|sys>

What does each option do?

• /res to open the resource view
• /report to launch the system diagnostic collector suite and view a report.
• /rel to open Reliability Monitor.
• / sys to go directly to the classic performance monitor.

Council: if you want to check the reliability of the equipment, perfmon / rel It is a direct shortcut to stability and bug history.

Reliability Monitor It's also located in Control Panel > System and Security > Security and Maintenance. Another shortcut: type "reliab" into the Start menu search and select "View reliability history." You'll see critical events, warnings, and information by day or week, with access to technical details of application and driver failures.

Real-time visualization: adding and understanding counters

 

To see a live chart, open “Performance Monitor” in the tree on the left. If there are preloaded counters and you want to start clean, select them in the table below and press del Then, in the chart area, right-click > Add Counters… to open the dialog with all available categories.

Choose the category of interest, the counter, and the object instance (e.g., your process). To diagnose memory and resources in a specific app, add these key counters from the group y .NET CLR Memory where appropriate:

• Process \ Private Bytes: Private memory allocated by the process (not shared with others). Sustained growth indicates actual consumption of its own virtual memory.
• Process \ Handle Count: number of open handles. Constant increases often indicate resource leaks (sessions, system objects).
• Process \ Thread Count: Number of active threads in the process. Unexpected spikes may indicate concurrency issues or unfinished threads.
• .NET CLR Memory \ # Bytes in all Heaps: Total memory for .NET objects. If it grows without stabilizing, check for GC pressure and unreleased references.
• .NET CLR Memory \ Gen 2 heap size: Gen 2 heap size (long-lived items). Continued growth suggests uncollected long-lived items.

Interpret the graph with a critical eyeIf you notice that Private Bytes is steadily increasing while # Bytes in all Heaps and Gen 2 heap size remain stable, the growth isn't in the .NET heap but in the process's native memory/reserves. This pattern usually indicates a leak outside of the GC (e.g., unfreezed buffers or handles).

Adjust the graph: scale, interval and duration

PerfMon allows adjust the visibility of each counter and the history period you see. Press Ctrl + Shift + A To select all the counters in the list below, right-click and choose Scale selected counters, so they will all be visible without one “flattening” the rest.

Opens Chart Properties Right-click > Properties… and set the sampling rate on the General tab. For example, sample every 10 seconds and set Duration to 10000 to cover approximately 2,5 hours in the view. The longer the phenomenon, the more spaced out the sampling rate should be to avoid huge files and overloading your computer.

Extra tip: PerfMon exposes ActiveX properties and methods, allowing you to integrate or control it from other development tools and even embed it as a control in your own application if needed.

Automate with Logman: Create, Start, and Stop

 

Logman.exe is the command-line utility for creating and managing counter sets.. Open a command prompt with administrator privileges and run a command similar to the following to create a large continuous monitoring suite with a circular file:

Logman.exe create counter Avamar -o "c:\\perflogs\\Emc-avamar.blg" -f bincirc -v mmddhhmm -max 250 -c "\\LogicalDisk(*)\\*" "\\Memory\\*" "\\Network Interface(*)\\*" "\\Paging File(*)\\*" "\\PhysicalDisk(*)\\*" "\\Processor(*)\\*" "\\Process(*)\\*" "\\Redirector\\*" "\\Server\\*" "\\System\\*" -si 00:00:05

To start and stop capture, uses:

Logman.exe start Avamar
Logman.exe stop Avamar

Command tips: -f bincirc creates a circular binary log (-max limits the size in MB), -si defines the sampling interval, and -c adds counters in bulk for objects and their instances. Use quoted paths and escape backslashes when scripting or exporting configuration.

When to use Logman? It is ideal for collect long-distance data On servers, automate diagnostics, or standardize captures across multiple machines. You can schedule it with Task Scheduler and rotate files without intervention.

Useful counters and thresholds per subsystem

Conference proceedings: Monitors actual capacity, paging pressure, and system pool depletion. These counters and guidelines help separate symptoms from causes:

• Memory \ % Committed Bytes In Use: Percentage of committed memory over the commitment limit. If it consistently exceeds 80%, review the paging file size and actual usage.
• Memory \ Available MBytes: Free physical memory. Investigate if < 5% of RAM drops repeatedly (and < 1% is critical).
• Memory \ Committed Bytes: Total committed bytes. Should not vary sharply; frequent changes can result in pagefile expansions.
• Memory \ Pool Nonpaged Bytes: non-paged pool (objects that cannot be flushed to disk). Persistent saturations (> 80%) They are associated with events such as 2019 (nonpaged pool exhaustion).
• Memory \ Pool Paged Bytes: : paged pool. Sustained values > 70% of the maximum indicate a risk of a 2020 event (paged pool exhaustion).

Processor: Look for sustained loads and heavy I/O signals or noisy drivers.

• Processor Information \ % Processor Time (all instances): >90% sustained on 1 CPU or >80% on multiprocessor suggests CPU overload.
• Processor \ % Privileged Time: Kernel mode time. Continuously exceeding 30% on app/web servers may indicate excessive driver or system workload.
• Processor \ % Interrupt Time y % DPC Time: > 25% point to intense device activity (NIC, disk, etc.).
• System \ Context Switches/sec y Processor \ Interrupts/sec: useful for viewing context switching pressure and interrupt activity.

Red: points to NIC health and communication quality.

• Network Interface\Packets Received Discarded: should remain close to zero; rising values usually indicate insufficient buffers/hardware.
• Network Interface\Packets Received Errors: : errors > 2 sustained require review of links/cables/drivers.

Disc: measures saturation, latency and capacity.

• PhysicalDisk \ % Idle Time: percentage of idle time. Sustained low indicates a busy disk; it reflects the remaining capacity well.
• PhysicalDisk \ Avg. Disk sec/Read y Avg. Disk sec/Write: Average latency. Typical references (guidelines): Excellent reads < 8 ms, acceptable < 12 ms, fair < 20 ms, poor > 20 ms; Excellent writes < 1 ms, good < 2 ms, fair < 4 ms, poor > 4 ms.
• PhysicalDisk \ Avg. Disk Queue Length: average tails. Values below 2× are usually reasonable.
• PhysicalDisk \ Split IO/Sec: I/Os split due to fragmentation or inadequate block sizes. The lower the better.
• LogicalDisk \ % Free Space: Always leave > 15% free (recommended ≥ 25%) on the system's logical volumes.

Disk objects: physical vs. logical.

• PhysicalDisk adds access to all partitions of a physical device (identifies the hardware).
• LogicalDisk Measures a specific partition or mount point. With dynamic disks, a logical volume can span multiple physical disks, and its counters will reflect the total.

Process: to correlate resources with the behavior of a specific app, monitor Process \ % Processor Time, Private Bytes, Virtual Bytes y working set. Handle Count It is key if you suspect pool leaks; growth of handles often marry with abnormal increases in Pool Nonpaged/Paged.

Reliability Monitor: Investigate failures and compatibility

Windows Reliability Monitor summarizes stability and events by day or week, classifying critical, warning and informationFrom each column, you can open “View Technical Details” to inspect modules, code, and digital signatures of the binaries involved.

• object lessonYou'll find entries like svchost.exe_MapsBroker or other crashing applications. Sometimes the reported module (e.g., Kernelbase.dll) belongs to the Windows kernel and is signed by Microsoft, suggesting that the root cause isn't the kernel, but rather the application or a plugin running in your user space.
• What to do when an old app is failingRun the compatibility troubleshooter and try forcing compatibility mode (e.g., Windows 7) and disabling high DPI scaling if you encounter interface or performance issues. This setting has been shown to resolve crashes in legacy software.
• Links stability findings with PerfMonCombines crash history with counter logs to see if Private Bytes, Handle Count, or disk latency were high before the crash. This correlation gives you a thread to pull.
• Practical closure: With PerfMon and Reliability Monitor you can diagnose from the symptoms (crash, slowness) to the cause (memory leak, disk bottleneck, 100% CPU, network errors), supported by counters and thresholds that clearly guide you.

If you need a quick guide to getting started: Open PerfMon, add counters for the target process (Private Bytes, % Processor Time, etc.), adjust sampling and duration to cover the window in which the problem occurs, log to file with a Collector Set, and if applicable, automate with Logman on servers or test environments that need to run for hours.