Ask any senior technician what separates him from the person who reinstalls Windows on every slow PC, and he will not name a tool. He will describe the first five minutes. What you do before touching anything decides whether the rest of the diagnosis is evidence or superstition. This page is that routine, minute by minute.
Most slow PC repairs go wrong in the first five minutes. The cleaner runs, the temp files vanish, the PC restarts - and with them goes every clue about what was actually happening. The professional routine is boring on purpose: observe, ask, reproduce, write it down. Nothing gets fixed in these five minutes, and that is exactly the point. A fault you can reproduce on demand is a fault you can test; a fault that was cleaned before anyone saw it is a ghost you will chase for a week.
Sit and watch the PC in its natural state. If it just booted, let it settle - a machine in its first two minutes after login is always busy and proves nothing. Watch what it does at idle and what the user does all day. Note the obvious physical evidence people walk past: the fan roaring at idle, a hard drive clicking or grinding, a laptop too hot to touch underneath, a desktop in a closed cabinet with no air.
Your only job this minute is to not destroy evidence. No Task Manager yet, no restart, no let me just clean it first.
When did it start? and what changed just before? Users forget they are witnesses. A PC that slowed down on Monday after a Sunday update, a new printer, an office move or a toddler knocking it off the desk has handed you the first suspect for free. If they cannot remember, that is information too - gradual slowness points at load, age and drive wear rather than one bad event.
Also ask slow at what? Boot, one app, every app, internet, printing. The scope answer alone cuts the suspect list by half, and this set has a full case page on scope testing.
Now reproduce it, exactly as the user does it - same app, same file, same steps. Time it with your phone stopwatch. Opens in 40 seconds is a measurement; takes forever is a mood. While it crawls, watch the machine: is the disk light solid, is the fan screaming, does the mouse stutter for everything or only inside that window?
If you cannot reproduce it, say so honestly and change strategy: the fault is intermittent, and your job becomes catching it - ask the user to note the time and what they were doing next time, or leave Resource Monitor's history and Event Viewer to testify. Never fix a fault you have never seen and call it repaired.
Compress everything into one written line. For example: Boot to usable desktop 3 min 10 s; Word opens in 38 s; disk light solid throughout; started after last Tuesday's update. That single line contains your before-measurements, your scope and your first suspect. Every later test either supports it or replaces it.
Technicians who skip this step end the day saying it feels faster now. Feelings are not billable and they are not proof. Numbers are both.
The video shows this opening routine on a real complaint - watch how little is touched, and how much is learned.
Watch Full VideoNo. Observe it in the state the user experiences. A restart clears stuck processes, pending updates and memory pressure that may have taken days to accumulate - the very evidence you need. Restart later, deliberately, as one of your tests.
With numbers. Time the boot, time two app launches, read the four meters in Task Manager. Vague complaints become testable the moment you attach figures to them, and those figures are your before-readings for the whole job.
Because diagnosis takes turns you do not expect. Two hours later, mid-repair, the written line is the only honest record of the original fault and its size - and it is what you compare the after-readings against to prove the repair worked.