Performance problems that are not hardware, and proving which is which

Why this matters

"Slow" tickets are the ones most often closed with a guess, and the guess is usually a hardware upgrade. Sometimes that is right. Frequently the machine has a full disk, a synchronisation client reindexing, forty browser tabs, or a scheduled scan running at the wrong time — and the upgrade fixes nothing because the bottleneck was never the hardware.

The measurement side of this was covered earlier in this course when we looked at Task Manager and Resource Monitor. This lesson is about what to do with the measurement: the specific software causes, in the order they are worth checking, and the point at which the honest answer is that the hardware really is the problem.

The lesson

Establishing what 'slow' means before trying to fix it

The first job is to convert a feeling into something testable, because "slow" covers at least five different faults.

Ask, and if possible watch:

• Slow at what? Starting up, signing in, opening an application, opening a file, switching between windows, or anything on the network.
• Slow since when? A machine that became slow last Tuesday has a cause with a date. A machine that has always been slow has a specification.
• Slow always, or sometimes? Intermittent points at something scheduled or at something triggered by an action.
• How slow? Get a number. "Forty seconds to open a spreadsheet" is testable; "ages" is not.
• Compared with what? An identical machine beside it, or the same machine last month.

The categories those answers sort into:

• Slow at logon → startup items, profile size, mapped drives or policy timing out.
• Slow opening one application → that application, or the files it opens.
• Slow opening files on a share → the network or the server, not this machine.
• Slow at everything, constantly → a resource is exhausted, and Task Manager says which.
• Slow at everything, occasionally → something scheduled.

Doing this first is what prevents an afternoon spent optimising a machine whose actual fault is a slow file server.

Storage pressure, fragmentation on the media where it still matters, and free space

Storage is the most common non-hardware cause and the easiest to fix.

Free space. A volume near full degrades badly: no room for temporary files, no room for the page file to grow, no room for updates. Below roughly 10 per cent free, and certainly below a few gigabytes, this is the fault. What is actually using it — Storage settings breaks it down, and the usual culprits are Windows.old after an upgrade, downloads, a synchronisation client's local copy, shadow copies, and a very large profile.

Fragmentation, on the media where it still matters. On a mechanical disk, fragmentation is real and defragmenting helps. On a solid-state disk it is irrelevant, and traditional defragmentation causes unnecessary wear — which is why Windows runs TRIM on solid-state disks and defragmentation only on mechanical ones, automatically, and why manually defragmenting a solid-state disk is a wrong answer on the exam.

Other storage causes:

• A mechanical disk in a machine expected to feel modern, which is a specification problem with a cheap fix.
• A failing disk retrying reads, which shows as high active time with low throughput. Check its health data.
• A drive nearly full of the wrong kind — a user with 200,000 files in one folder produces a slow folder, not a slow machine.

The order: check free space, check disk health, check whether it is mechanical. Three checks, two minutes, and a large share of slow machines answered.

Memory pressure and paging, and the difference between used and committed

Memory was covered from the measurement side earlier; here is what to do about it.

The distinction that matters: used memory includes cache, and a machine using 85 per cent of its memory is usually a machine using its memory well. Committed is what has been promised, and committed approaching the commit limit is genuine exhaustion. Hard faults per second is the symptom: memory accesses that had to go to disk.

So the diagnosis is: high hard fault rate, sustained, while the user is doing ordinary work → this machine needs more memory, or needs to run less.

Before recommending memory:

• What is using it? Sort by memory in Task Manager. A browser with many tabs, a synchronisation client indexing, or a single application with a leak.
• A memory leak shows as one process growing steadily over hours and releasing on restart. That is an application fault, not a hardware shortage, and the fix is an update or a scheduled restart.
• Is the page file sensibly configured? System-managed is almost always right. A page file disabled entirely produces out-of-memory failures on a machine with free memory, which is a confusing fault with a simple cause.

When memory is genuinely the answer, say what it will fix: switching between applications, and running more at once. It will not make a single application faster, and promising that it will produces a disappointed user holding an invoice.

Background load: indexing, sync clients, updates and telemetry

Background work is the cause most often missed, because by the time anyone looks, it has finished.

The usual suspects:

• Search indexing, which is intense after a rebuild, a large data move, or a profile restore. It ends; the question is whether it has been running for ten minutes or three days.
• Synchronisation clients — cloud storage doing an initial sync or re-downloading a large folder. Heavy on disk and network, and completely invisible to the user.
• Windows Update downloading and installing, and the servicing work afterwards.
• Antivirus scans scheduled for a time the machine is in use.
• Backup agents running their first full backup.
• Telemetry and vendor utilities, particularly on consumer machines, where three or four vendor background applications are normal.

How to find them: Task Manager sorted by disk, then by network; Resource Monitor for which process is doing what; and Task Scheduler for what is triggered and when.

The fixes are mostly scheduling rather than removal. A scan at 02:00 on a machine that is off at 02:00 never runs, so it runs at 10:00 instead; moving it to a time the machine is actually on and idle fixes the complaint without disabling anything. Startup items are the other lever, and Task Manager's startup impact column ranks them for you.

The one category to remove rather than reschedule: vendor "optimiser" and "driver updater" utilities, which consume resources continuously and provide nothing.

When it really is hardware, and the measurement that shows it

Sometimes it is the hardware, and the professional skill is saying so with evidence rather than as a guess.

The measurements that justify it:

• Sustained 100 per cent disk active time with a mechanical disk and ordinary work → a solid-state disk is the fix, and it is the single largest improvement available to an old machine.
• Sustained high hard fault rate with nothing unusual running → memory.
• Processor pinned by legitimate work the user needs to do — video, large spreadsheets, virtual machines → processor, and this is the least common of the three.
• Thermal throttling — high load with a clock speed well below the rated one, and temperatures near the limit. This is a cleaning or cooling problem, and it is the one that returns as a Core 1 hardware question.
• Failing storage — reallocated sectors rising, or read errors in the log. Replace it, and do so before it fails rather than after.

How to present it: name the measurement, the symptom it explains, and what the change will and will not fix. "The disk is at 100 per cent whenever you open anything and it is a mechanical drive; a solid-state disk will fix startup, application launch and file opening, and will not change how fast the spreadsheet recalculates" is a recommendation someone can act on.

And the honest version of the opposite: "I have not found a software cause, and the hardware measurements are normal" is a legitimate outcome that should be written down rather than covered with an upgrade.