Service desk

Slow computer troubleshooting: find the real cause before you reimage

"It's running slow" is the most common complaint in IT and the least specific. The machine might be starved of memory, halfway through an antivirus scan, throttling in the afternoon sun, or perfectly healthy and waiting on a struggling server. Slow computer troubleshooting is really a sorting problem: there is a short list of genuine causes, each leaves a distinct signature, and each has a different fix. This guide walks through those signatures in order, whether you support paying clients or the colleague two desks away.

The reason this matters is that the default response, reimage the machine or just buy a new one, treats every cause identically. Sometimes that works by accident. Often it wastes half a day and the slowness comes straight back, because the cause was never on the machine in the first place. Ten minutes of diagnosis beats four hours of rebuilding almost every time.

Start with the symptom, not the machine

Before you touch Task Manager, ask four questions. The answers cut the list of possible causes roughly in half each time:

• Slow at what? "Everything" points at disk, memory or thermals. "Just Outlook" or "just the finance system" points at one application or the service behind it.
• Slow always, or slow sometimes? Constant slowness is hardware or configuration. Slowness that comes in bursts is a background job. Slowness at 9am on Mondays is everyone logging in at once.
• Since when? "Since yesterday" usually means something changed: an update, a new agent, a new browser extension. "For months, gradually" points at ageing hardware or accumulating startup load.
• Just this person? If three people report it the same week, stop diagnosing the endpoint. The cause is shared: the network, a server, or a change you rolled out.

Write the answers into the ticket. Half the value of a service desk is that the next person does not start from zero, and "user says slow" is starting from zero.

Slow to start: disk and startup load

If the complaint is about boot time and the first ten minutes of the day, look at the disk first. The single biggest performance divide in any fleet is still spinning hard drive versus SSD, and machines with HDDs are still out there in the long tail of every estate. Check what you are dealing with before anything else:

Get-PhysicalDisk | Select-Object FriendlyName, MediaType, HealthStatus

If MediaType says HDD on a general-purpose laptop or desktop, you have found your cause and no amount of software tuning will fix it. An SSD swap or a replacement machine is the answer, and everything else in this article is secondary.

On SSD machines that are still slow to start, open Task Manager's Startup tab and look at what launches at logon. Estates accumulate startup programs the way lofts accumulate boxes: three chat clients, two cloud sync tools, a printer utility from a printer that left the building in 2023. Each one is small; twenty of them at logon is not. Disable everything that does not need to start automatically, and fix it fleet-wide in policy rather than machine by machine.

The other classic signature here is disk sitting at 100% in Task Manager for minutes after logon while the machine catches up on indexing, sync and updates. On an HDD that is crippling; on an SSD it should clear quickly. If it does not, note which process owns the disk column, because that is your next section.

Slow all day: memory pressure

If the machine is sluggish constantly, in every app, with fans quiet and disk idle, suspect memory. The signature is easy to read in Task Manager's Performance tab: memory sitting above roughly 85% committed, and the disk ticking over constantly as Windows pages memory out to disk to cope. Paging is the killer. The moment the working set no longer fits in RAM, every application pays a disk-speed penalty for a memory-speed operation.

Two things cause it. Either the machine has too little RAM for the year it is living in, 8GB being the current floor for a business Windows machine running a browser, Teams and an office suite together, or one process is eating far more than its share. Sort the Processes tab by memory and look at the top entry. A browser with 60 tabs is the usual suspect; a leaking application that climbs all week and resets on restart is the more interesting one, and worth reporting to whoever owns that app.

The fix follows the cause: more RAM if the workload is legitimate, and a conversation or an app fix if it is not. Adding RAM to a machine whose real problem is a memory leak just buys the leak more room.

Slow in bursts: background jobs fighting the user

Slowness that arrives in waves, twenty bad minutes and then fine again, is almost never the user's workload. It is something scheduled: an antivirus full scan, a backup job, search indexing, a sync client reconciling thousands of files, or Windows Update downloading and installing in the background. The diagnostic move is correlation. Note the times the user reports, then look at what ran at those times: scan schedules, update history, backup logs.

Every one of those jobs is necessary. The failure is scheduling them inside working hours, or letting them all land at once. Move full scans and heavy maintenance to lunchtime or evenings, stagger them across the fleet rather than triggering every machine at 9am, and let updates install at a time you chose rather than whenever the machine feels like it. If updates themselves are the recurring disruption, that is usually a sign they are failing and retrying, which is its own diagnosis: we wrote up how to find the real cause of failing Windows updates separately.

One more burst-shaped cause deserves a mention: malware. Cryptominers and other unwanted processes show up exactly like a rogue background job, high CPU from a process nobody recognises, often when the machine is idle. If the process owning the CPU column is not something you installed, treat it as a security question, not a performance one.

Slow when hot or unplugged: power and thermals

Some machines are only slow in specific physical conditions, and users rarely volunteer the pattern because they have not spotted it. A laptop that crawls on battery but flies on mains is running a power plan that caps the CPU when unplugged, or is being charged through an underpowered USB-C charger that cannot sustain full performance. A machine that starts the day fine and degrades by afternoon, fans roaring, is thermal throttling: the CPU is deliberately slowing itself to stay within temperature limits.

The tell is in Task Manager's CPU graph: a clock speed pinned well below the chip's base frequency while utilisation is high. The causes are unglamorous. Vents blocked by a desk dock or a sofa, fans furred with dust, thermal paste that dried out years ago, or a "quiet" fan profile set in firmware. Compressed air and a sensible power plan fix a surprising share of "this laptop needs replacing" tickets, at a cost of roughly nothing.

Slow, but it is not the computer

A large fraction of slow computer tickets, plausibly the largest, are not about the computer at all. The endpoint is idle: low CPU, plenty of free memory, disk quiet. It is waiting on something at the other end of a wire. The candidates:

• The VPN. If all traffic is backhauled through a VPN before reaching the internet, every cloud app is as slow as that tunnel. The tell: everything is faster off VPN.
• Wi-Fi. A weak signal or congested access point makes a fast laptop feel broken. The tell: it is fine on a cable, or fine in a different room.
• A server or SaaS app. If the slowness lives in one application for multiple people, diagnose the service, not the laptops of everyone who uses it.
• Legacy logon plumbing. Roaming profiles, logon scripts and mapped drives to a wheezing file server produce "slow computer" complaints that are really "slow server" complaints.

The general test is isolation: same task, same account, different machine or different network. If the symptom follows the network or the service rather than the device, no endpoint fix will help, and a reimage is pure ritual.

Slow because it is old: when the diagnosis is the hardware

Sometimes you work through all of the above and the honest answer is that the machine is simply past it. The signature of age is breadth: nothing individually wrong, everything slightly slow, a CPU several generations behind what current software assumes, and a user who has quietly adapted their working day around waiting. That adaptation has a real cost, paid daily, and it is usually far larger than the price difference between replacing a machine at year four versus year six. We covered the economics in our guide to hardware refresh cycles.

This is also the moment to be honest about reimaging. A rebuild fixes exactly one class of cause: accumulated software rot on the endpoint. It does nothing for undersized RAM, a tired disk, blocked vents, the VPN or the file server, which is most of the list above. Reimage when the evidence points at the software layer and you cannot isolate the specific cause, not as a first move. And before you wipe anything, note what the diagnosis showed; a fleet that keeps losing machines to the same cause has a fleet problem, not a machine problem.

Where this fits with Helios

Almost every signature in this article is something a monitoring agent can see before anyone opens Task Manager: real uptime, disk type and health, memory pressure over time, the process that owns a CPU spike, patch and scan activity. Helios collects that history from every device it watches, and when a slowness ticket arrives, Helio, the AI layer, runs the investigation you just read about: it checks the device's recent metrics, correlates the complaint with what actually ran, and either fixes the boring causes or hands you a diagnosis instead of a blank ticket. The four questions still matter; you just start with the answers already on screen.