Procedure

Diagnose a slow Windows computer

Diagnose a slow Windows computer without random cleanup by qualifying the symptom, measuring CPU, memory, disk and network usage, reviewing processes, free space and updates, and capturing PerfMon evidence when needed.

Objective

Identify the real bottleneck on a slow Windows computer by separating CPU, memory, storage, network, and application behavior, then apply one targeted and measurable correction instead of stacking unproven optimization changes.

Prerequisites

  • A precise description of the symptom and approximate occurrence time.
  • Administrative access, or at least the ability to use Task Manager and Resource Monitor.
  • Enough free space for a PerfMon log if a longer capture is required.
  • Knowledge of installed security software and critical business applications.
  • A healthy comparison workstation when the issue affects one hardware model or application.

Step-by-step procedure

1

Qualify the slowdown

Ask when the computer is slow: during boot, sign-in, application launch, browsing, file copies, or continuously. Record when the issue started, whether it is reproducible, and what changed recently. A permanent system-wide slowdown should not be investigated in the same way as a 30-second delay after sign-in.

Get-CimInstance Win32_OperatingSystem | Select Caption,Version,BuildNumber,LastBootUpTime
Get-CimInstance Win32_ComputerSystem | Select Manufacturer,Model,TotalPhysicalMemory
Expected result
  • The symptom has a reproducible window and clear hardware and OS context.
2

Check disk space and basic health

A nearly full system drive can affect Windows Update, paging, and applications. Check free space before advanced troubleshooting and review the health state Windows reports for the storage device. Treat a Healthy status as one signal, not as a complete hardware test.

Get-Volume | Select DriveLetter,FileSystemLabel,Size,SizeRemaining,HealthStatus
Get-PhysicalDisk -ErrorAction SilentlyContinue | Select FriendlyName,MediaType,HealthStatus,OperationalStatus
Expected result
  • The computer has enough free disk space for normal operation and further diagnostics.
3

Observe CPU, memory, and disk during the symptom

Open Task Manager or Resource Monitor while the slowdown is occurring and sort by CPU, memory, and disk. Look for a process that remains dominant throughout the symptom rather than a brief spike. For storage, distinguish throughput from latency; for memory, review available memory and paging.

resmon.exe
Get-Process | Sort CPU -Descending | Select -First 15 Name,Id,CPU,WorkingSet64
Expected result
  • One or more consumers correlate with the slowdown, or no obvious process is identified.
4

Check startup processes and recurring tasks

If the issue follows sign-in, inventory startup applications, services, and scheduled tasks that run at that time. OneDrive sync, updates, security scans, and business agents may all be legitimate but overlap. Disable only a noncritical component in a reversible test and measure the difference.

Get-CimInstance Win32_StartupCommand | Select Name,Command,Location,User
Get-ScheduledTask | Where-Object State -ne 'Disabled' | Select TaskPath,TaskName,State | Select -First 50
Expected result
  • Automatic workloads that coincide with the slowdown window are identified.
5

Check Windows Update and pending restart state

A computer completing updates, servicing components, or waiting for a restart can consume CPU and disk. Review update history and events before terminating TiWorker, TrustedInstaller, or maintenance processes. If a restart is justified, document the state first.

Get-Service wuauserv,bits | Select Name,Status,StartType
Get-HotFix | Sort InstalledOn -Descending | Select -First 10
Expected result
  • Windows servicing is either identified as a likely cause or ruled out.
6

Measure performance counters

When the cause is not obvious, use Performance Monitor. CPU, memory, and disk counters distinguish sustained saturation from a transient spike. Get-Counter is useful for a short sample; use a Data Collector Set or logman for intermittent incidents that require historical evidence.

Get-Counter 'Processor(_Total)% Processor Time','MemoryAvailable MBytes','PhysicalDisk(_Total)Avg. Disk sec/Transfer' -SampleInterval 2 -MaxSamples 15
Expected result
  • Resource usage is measured during the symptom rather than estimated.
7

Create a PerfMon capture for intermittent issues

Create a lightweight Data Collector Set for CPU, memory, disk, and process counters when the problem occurs infrequently. Choose an interval and maximum log size appropriate to the incident window, then stop the capture after reproducing the slowdown.

logman create counter BOAI_Perf -f bin -v mmddhhmm -max 1024 -c "Processor(*)*" "Memory*" "PhysicalDisk(*)*" "Process(*)*" -si 00:00:05
logman start BOAI_Perf
logman stop BOAI_Perf
Expected result
  • A BLG log covers the period in which the slowdown actually occurred.
8

Review event logs and reliability history

Check System and Application events around the exact incident time for disk, WHEA, driver, service, application, or timeout errors. Reliability Monitor can help correlate crashes and updates. Do not treat an unrelated warning as the cause solely because it exists.

perfmon /rel
Get-WinEvent -FilterHashtable @{LogName='System';StartTime=(Get-Date).AddHours(-2)} -ErrorAction SilentlyContinue | Where-Object LevelDisplayName -in 'Error','Critical' | Select -First 30 TimeCreated,Id,ProviderName,Message
Expected result
  • Relevant errors are correlated with the slowdown time window.
9

Correct one cause at a time and measure again

Apply the correction that matches the measured bottleneck: free or expand storage, update a problematic driver, repair an application, adjust a scheduled task, or upgrade RAM or storage when justified. Reproduce the same scenario and compare response time and counters.

Expected result
  • Response time and measured counters improve after the targeted correction.

Validation

The procedure is validated when:

  • The slowdown is reproducible or a performance capture covers the incident window.
  • The CPU, memory, storage, network, or application bottleneck is identified.
  • The correction improves a measured indicator rather than only a subjective impression.
  • No critical security service remains disabled.

Rollback

  • Re-enable any service or startup item disabled for testing when no improvement was measured.
  • Restore the previous driver or application version if an update makes performance worse.
  • Remove the Data Collector Set after collection when it is no longer required.
  • Preserve logs before rebooting if the problem returns intermittently.

Troubleshooting / common errors

  • If no single process is responsible, compare PerfMon counters with a healthy workstation using the same workload.
  • If disk active time is high with low throughput, investigate storage latency, queueing, and hardware health.
  • If the issue appears only after sign-in, focus on startup applications, scheduled tasks, profile loading, and synchronization.
♡ 0