Task Manager, Resource Monitor, and reading a machine that is slow

Why this matters

"It's slow" is the most common support request there is and the least informative. It describes an experience, not a fault, and the machine will happily agree with you that it is slow without telling you why.

Task Manager turns that experience into a measurement, and the measurement almost always points at one of four things. The skill being examined is not knowing where the tool is — it is looking at four numbers and being able to say which resource the machine has run out of, because the remedy for each is completely different and guessing wrong wastes an afternoon on the wrong upgrade.

The lesson

The four resources, and deciding which one a slow machine is short of

A machine can only be short of four things, and naming which one is most of the diagnosis.

• Processor. Sustained high usage with a process to blame. Symptom: the whole machine is uniformly sluggish, fans are loud, a laptop is hot.
• Memory. High usage and, more tellingly, heavy paging. Symptom: switching between applications is slow while each one is fine once it is in front of you.
• Disk. High active time and a long queue. Symptom: the machine stalls completely for seconds at a time and then recovers, and the pointer still moves during the stall.
• Network. Saturated link or high latency. Symptom: only the things that reach the network are slow, and local work is fine.

The method: open Task Manager on the Performance tab, watch for thirty seconds while the user reproduces the slowness, and see which graph is pinned. Then go to the Processes tab, sort by that column, and find out what is doing it.

Two traps worth naming. Processor usage near 100 per cent is not automatically a fault — a machine encoding video or running a scan is supposed to look like that, and the question is whether the work is wanted. And the resource that is pinned is not always the one at fault: a machine short of memory pins the disk, because paging is disk activity. That is why memory pressure is read from paging rather than from the memory percentage, which is the next section.

Processes, services and startup items, and telling the three apart

The Processes tab mixes three different kinds of thing, and the exam expects you to tell them apart.

• Applications are what the user started. Closing one is safe; the user loses unsaved work and nothing else.
• Background processes are started by applications, by the system, or by something installed. This is the interesting category: an updater, a sync client, a browser's helper processes, and anything unwanted that got installed will be here.
• Windows processes are the operating system. Ending one is generally a bad idea and some cannot be ended at all.

Services are a fourth category with their own tab, and their distinguishing feature is that they run without anyone logged in and restart themselves according to a recovery policy. That is exactly why "I ended it and it came back" happens.

Startup apps have their own tab too, with a startup impact rating. This is the highest-value tab in the whole tool for a slow machine that is slow at logon: a user with fourteen enabled startup items has a machine that is unusable for three minutes after signing in, and disabling ten of them takes one minute and changes their day.

The distinction to carry: disabling a startup app stops it launching at logon and does not uninstall it. Disabling a service stops it running at all, which can break the application that installed it. Startup items are safe to experiment with; services are not.

Reading memory pressure honestly: used, cached, committed and hard faults

The memory percentage is the most misread number on the machine, and reading it correctly is genuinely examinable.

Modern operating systems deliberately use memory that would otherwise sit idle — caching files, keeping recently closed applications ready. A machine showing 80 per cent memory in use is usually a machine using its memory well. "Free" memory is wasted memory.

So the number that tells you about pressure is not usage. It is:

• Committed against the commit limit. When committed approaches the limit, the machine is genuinely running out of room to promise.
• Hard faults per second (Resource Monitor's memory tab). A hard fault is a memory access that had to go to disk. A few are normal; a sustained high rate is the definition of thrashing and it is what "short of memory" actually looks like.
• Cached — memory holding file data that can be given up instantly. Large cached figures are healthy.

Resource Monitor is where these live, and it is reachable from Task Manager's Performance tab. It is the right tool the moment Task Manager has told you which resource and you need to know why.

The practical consequence: a machine with 90 per cent memory used and almost no hard faults does not need more memory. A machine at 70 per cent with hundreds of hard faults a second does. Recommending a memory upgrade from the percentage alone is the most common wrong answer in this objective.

Disk queue and latency as the cause most often blamed on the processor

Disk is the resource most often mistaken for something else, because its symptom is the one users describe most dramatically.

The numbers to read:

• Active time. The percentage of the interval during which the disk was doing something. Sustained 100 per cent means the disk is the bottleneck.
• Response time, in milliseconds. A solid-state disk answers in single figures. A mechanical disk under load can be in the hundreds, and above roughly 25 milliseconds a user perceives stalling.
• Queue length. How many requests are waiting. A persistent queue means requests are arriving faster than the disk can serve them.

The characteristic symptom of a disk bottleneck is a machine that freezes completely for several seconds and then catches up, while the mouse pointer keeps moving. That last detail is a useful discriminator: a processor-bound machine usually keeps responding sluggishly, whereas a disk-bound one stops and resumes.

Common causes, in the order you should check them: a mechanical disk in a machine expected to behave like one with a solid-state disk; indexing or a scan running; an update installing; a failing disk retrying reads; and paging because of the memory problem in the previous section.

The last of those is the important one. A machine short of memory presents as a disk problem, because paging is disk work. If disk is pinned, look at hard faults before concluding the disk is at fault — otherwise the recommendation is a new disk when the fix was memory.

Ending a process safely, and the ones that restart themselves

Ending a process is a blunt instrument, and knowing when it is appropriate is part of the skill.

• End task on an application asks it to close, then forces it. Unsaved work is lost. This is fine for a hung application and is the normal answer.
• End process tree takes the child processes with it, which is what you need when an application spawns helpers that keep the parent alive.
• Ending a Windows process can bring down the session or the machine, and some are protected outright. If you are considering it, restarting is almost always the better answer.

The ones that restart themselves, and why:

• Services with a recovery action are configured to restart after failure. Ending one and watching it reappear is the service doing its job. The fix is to stop the service properly, and if it must stay stopped, to set its startup type accordingly.
• Processes with a watchdog — some security and management agents deliberately restart each other, by design, so that ending one does not disable protection. Fighting this is the wrong move; the right move is the agent's own console or the management system.
• Scheduled tasks re-launch on their trigger regardless of how many times you end the process.

The professional habit: before ending anything, find out what it is. Right-click gives you the file location and the ability to search online. A process you cannot identify is a reason to look it up, not a reason to end it — and if it turns out to be something that should not be there, the removal procedure in the security objectives is the answer rather than End task.