Windows process-level performance diagnosis: Get-Process, Get-CimInstance, and handle counts

Goal

Narrow a host-wide CPU, memory or handle problem down to one Windows process from PowerShell, reaching for a Sysinternals tool only once a specific process is already the suspect.

Prerequisites

PowerShell on the target machine (local or via remoting); the WMI/CIM service running for Win32_PerfFormattedData_* classes (it does by default); administrative rights to inspect processes owned by other users.

Steps

1. Sort by working set: Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 10 Name, Id, WorkingSet64, CPU. Get-Process's documentation shows the working set and CPU as properties available directly on the returned objects; use WorkingSet64 (alias WS), since the older 32-bit WorkingSet property is wrong for processes above 2 GB.
2. Sort by CPU the same way: Get-Process | Sort-Object CPU -Descending | Select-Object -First 10; CPU here is cumulative processor time since the process started, not a percentage, so a long-running process can rank high while currently idle.
3. For a rate instead of a cumulative total, query the formatted performance data class: Get-CimInstance Win32_PerfFormattedData_PerfProc_Process | Where-Object Name -notin '_Total','Idle' | Sort-Object PercentProcessorTime -Descending | Select-Object -First 10 Name, IDProcess, PercentProcessorTime. The filter matters: the _Total and Idle instances would otherwise top the list. The value is relative to one logical processor, so a multi-threaded process can exceed 100. Get-CimInstance's documentation describes querying a class by -ClassName; the Win32_PerfFormattedData_PerfProc_Process class documentation lists PercentProcessorTime and IDProcess among its properties, already computed as a rate.
4. Check handles when a process is suspected of leaking them, a common cause of slow degradation rather than a sudden spike: Get-Process | Sort-Object Handles -Descending | Select-Object -First 10 Name, Id, Handles. The underlying Process.HandleCount property is documented as the number of operating-system handles the process has open; a count climbing steadily over hours without the workload changing is the signature of a leak.
5. Once a specific process is identified, move to a Sysinternals tool for detail PowerShell does not expose: Process Explorer, for inspecting exactly which handles and DLLs a process has open; or Process Monitor, for watching its file system, registry and process/thread activity in real time.
6. Process Monitor requires administrative rights (it loads a driver); Process Explorer runs without them but shows full detail for other users' processes only when elevated. Stop capturing in Process Monitor promptly, since its log grows quickly under default settings.

Expected result

A specific process ID with a measured rate (CPU percentage, working set, or handle count) that a script can act on, escalating to a GUI tool only when PowerShell's own properties are not enough.

Limits and test basis

Win32_PerfFormattedData_* classes are computed from two consecutive internal samples, so a single query can return an unreliable rate on the very first call; querying twice a few seconds apart is more reliable. A handle count alone does not say which resource type (file, registry key, event) is leaking; Process Explorer's per-handle view is needed for that detail.