Measure the agent before you blame—or exclude—it.
A screenshot of Task Manager is not a diagnosis. Use these 24 checks to separate a short scan or update spike from sustained CPU pressure, private-memory growth, dependency churn, a damaged update, security-control interaction, or a process that is not the approved agent at all.
1. Scope and contain
- Confirm the process belongs to the approved agent by checking path, publisher signature, version, service, parent process, and tenant assignment—not the filename alone.
- Record affected customer, site, device, workload, business impact, observation window, and whether the endpoint is production-critical before changing anything.
- Group affected devices by operating system, agent version, policy, scheduled job, patch window, network, security stack, and first-observed time to distinguish one device from a shared regression.
- Pause only the narrow approved workload when impact is material; do not disable monitoring, EDR, antivirus, or application control fleet-wide to make the symptom disappear.
2. Prove the baseline
- Capture at least two timestamped CPU samples over a defined interval; a rate counter needs separated samples and a short spike does not prove sustained overhead.
- Record process ID, start time, logical-processor count, total CPU, working set, private bytes, committed memory, handle count, thread count, and I/O rates.
- Use a stable process identity. On Windows 11, prefer the Process V2 counter set when duplicate executable names could cause counter-instance mix-ups.
- Compare the process with system-wide CPU, memory pressure, paging, disk latency, and free space so host saturation is not misattributed to one agent.
3. Correlate the workload
- Align the spike with patch scans, software inventory, script execution, remote sessions, antivirus scans, backup, agent update, startup, or policy refresh.
- Check whether the process is repeatedly retrying a failed network, proxy, DNS, certificate, authentication, or platform request.
- Review agent and operating-system logs for crash loops, update failures, database or cache churn, access denials, timeouts, and repeated queue processing.
- Confirm whether EDR, antivirus, content filtering, or application control is inspecting, blocking, quarantining, or repeatedly reopening agent files or connections.
4. Capture deep evidence
- Use Process Explorer or an equivalent approved tool to inspect the actual process tree, signer, loaded modules, handles, threads, and per-process history.
- For sustained CPU, capture a bounded Windows Performance Recorder trace using CPU Usage; add disk, file, registry, or network profiles only when the symptom justifies them.
- For growing memory, distinguish working set from private or committed memory and collect a time series; use heap, VirtualAlloc, resident-set, or handle profiles only with a defined question.
- Create a process dump only when authorized, necessary, and securely handled; dumps may contain credentials, customer data, secrets, or other sensitive memory.
5. Remediate safely
- Define the expected recovery interval, success metrics, stop condition, evidence to retain, rollback, owner, and escalation route before changing the endpoint.
- Correct the verified narrow cause—failed update, damaged cache, retrying dependency, conflicting policy, unsupported version, or blocked component—through the vendor-supported path.
- Test one authorized restart or repair on a representative endpoint and preserve before/after process identity, resource samples, logs, and functional results.
- Do not create permanent exclusions or fleet-wide throttles from a single sample; require scoped approval, an expiry, compensating controls, and a retest plan.
6. Validate and close
- Repeat the same CPU, memory, I/O, handle, thread, and system-pressure measurements across a comparable workload and observation window.
- Verify monitoring, inventory, alerting, a bounded script, patch scan, and remote support separately so lower resource use is not mistaken for a disabled agent.
- Reconcile the full cohort into recovered, unaffected, still impacted, retired, duplicate, wrong-version, unknown, or time-bounded-exception states.
- Record root cause, affected versions or policies, corrective and preventive action, residual risk, owner, review date, customer communication, and closure evidence.
When is the high-resource condition resolved?
Resolution requires comparable before-and-after measurements and functional proof. The agent must remain the approved signed process under the intended tenant, resource use must stay within the documented acceptance boundary during the same workload, monitoring and privileged functions must still work, and every exception or unresolved endpoint must have an owner, expiry, and escalation path.
Primary references and measurement limits
- Microsoft: About Performance Counters explains sampling, multi-instance process counters, Windows 11 Process V2, and why some rate values require two samples.
- Microsoft: Collecting Performance Data documents processor normalization and the way process-instance churn can distort samples.
- Microsoft: Recording for Resource-based Analysis documents WPR profiles for CPU, disk, file, registry, network, heap, pool, VirtualAlloc, handle, and resident-set analysis.
- Microsoft Sysinternals: Process Explorer documents process, handle, DLL, signature, and search inspection capabilities.
- Microsoft: User-mode Dump Files describes ProcDump's CPU-spike and process-dump use; dumps still require authorization and sensitive-data handling.