Performance: slow boots, high CPU, and apps that hang — found and fixed in order

Everything in this guide is an instance of these six stages. You don't have to be formal about it, but keeping them separate is what keeps troubleshooting from turning into guesswork. Tap a stage to see what "done" looks like for it.

Why one variable at a time

Suppose your boot takes 90 seconds. You disable three startup apps, run a disk cleanup, and update a graphics driver — and now it boots in 40 seconds. You feel great, but you've learned nothing: it could have been any one of those three, and the other two changes may have masked a cause that will resurface. The disciplined version — change one thing, measure, move on — is slower in the moment and the only version that actually tells you what fixed the machine.

The three headline symptoms — slow startup, high CPU, and applications that freeze — are all symptoms, not causes. The same root problem can produce more than one of them at once, which is why you shouldn't anchor on the first one you noticed.

A slow or failing disk, for example, makes the boot slow (everything is read from it at startup), makes apps hang (they're waiting on data), and shows up as high disk activity rather than high CPU. Low memory makes apps hang and can show as high CPU from the system paging and compressing. A malware or miner infection adds hidden startup items (slower boot), burns CPU at idle, and generally drags everything down. Each of those is one cause wearing up to three different faces.

The practical takeaway: treat the three symptoms as a set to investigate together, and let the measurements tell you which underlying area they point at. Fixing the "slow boot" might leave the "high CPU" entirely intact if they had different causes — and you'd walk away thinking you solved a problem you only partially touched.

Before you touch a single setting, record the numbers. A baseline is the reference every later "did that work?" is measured against. Without one, "faster" is a feeling, and you can't tell a real improvement from noise — or from a fix that only worked for the one reboot you checked.

Measure under repeatable conditions: after a full reboot, at idle (nothing heavy open), and again under a normal workload. A number you can reproduce is a number you can trust. Write the values down or screenshot Task Manager — memory fades, and you'll want the "before" when you're comparing "after" a day later.

"Boot time" actually has two parts people lump together. The first is power-on to the login screen — that's mostly the firmware and the disk. The second is login to "actually usable," when the system is still silently starting your apps and services in the background. The second part is where most of the fixable slowness lives, and it's the one your settings can change.

To measure on Windows, powercfg /lastboot gives a breakdown of the startup phases and how long each took. To see what's launching, open Task Manager's Startup tab (or Settings → Apps → Startup on Windows 11); each entry shows a "startup impact" that hints at how much it costs. Note the list and the impacts before you change anything — that's your boot baseline.

1. Measure the current boot (to desktop, and to fully usable) and record it.
2. List the startup entries and their impact; mark the ones you recognize.
3. Note the disk — is the system drive an HDD or SSD? This sets the floor for how fast the boot can ever be.
4. Compare your "to usable" time against your expectations; a long tail after the desktop appears is the startup-apps problem, not the firmware.

There's no universal "normal" boot time — an HDD system will always boot slower than an SSD one, and a machine with twenty startup apps will always lag one with five. The number that matters is your own: did the boot get meaningfully faster after a specific change, and does it stay that way?

The single most common cause of both a slow boot and an elevated idle CPU is too much launching at once. Every startup app is a process competing for CPU, memory, and disk at the worst possible moment — when the system is already busy getting ready. Trim this list and you'll often fix two of the three headline symptoms at once.

On Windows 11, Settings → Apps → Startup toggles each entry; on Windows 10 and 11, Task Manager → Startup does the same and shows impact. Disable the things you don't actually need at login. The goal isn't an empty list — it's a list where every entry earns its place.

Verify: reboot and re-measure the boot to "usable," and watch the idle CPU a few minutes after login. Both should improve if startup load was a real contributor. If the boot is unchanged, startup apps weren't the cause — move on rather than trimming further.

"High CPU" just means the processor is busy — the useful question is busy with what. Task Manager sorts processes by CPU so the responsible process is usually right at the top. The first step is always to identify that process, not to end it.

Sort by CPU and watch for a few seconds. A process you recognize doing real work (a game, a video export, a compiler) is normal — that's the CPU being used. A process you don't recognize holding a high percentage at idle, when you're doing nothing, is the interesting one. Note its exact name; you'll look it up rather than guess.

Resist the urge to "End task" on something you don't understand as a first move. You might kill a driver and make the system less stable, or you might clear the symptom while the cause keeps running in the background. Identify first; a name you can research is worth more than a number you just cleared away.

A brief spike is normal; a sustained high load at idle is the problem. Windows Update, an antivirus scan, opening a heavy app, or indexing a folder all produce legitimate spikes that resolve on their own. What you're looking for is the meter that stays high when you're doing nothing — that's a background process, a bad driver, or an infection doing work you didn't ask for.

The shape of the usage changes where you look. A spiky pattern that follows your activity is fine. A flat, persistent high line at idle points at a specific process you can name. And a high System or System Interrupts entry — rather than a named app — usually points at a driver or a device, not a program, which sends you toward Device Manager and driver updates instead of the process list.

One more pattern worth knowing: if CPU is high and the machine is also hot, the two may be linked — a heavy background load raises temperature, and temperature raises throttling risk. Measure both together so you know which is driving which.

When physical RAM runs out, the operating system starts moving memory pages to disk (the pagefile) to make room. Disk is dramatically slower than RAM, so the visible result is apps that hang or take seconds to respond. Memory pressure is one of the most common reasons an app freezes while the CPU looks perfectly fine — the app isn't stuck thinking, it's stuck waiting.

The signature of memory pressure is a combination, not a single number: high memory in use, and high disk activity, and apps freezing. If you see that trio, the fix lives in memory — close what you don't need, find the process that's using an unreasonable amount, or add RAM — not in the CPU. Chasing the CPU when the real constraint is memory is a classic dead end.

In Task Manager, sort by Memory to find the largest consumers. A single app using many gigabytes may be a leak or a genuinely heavy workload; many moderate apps adding up means you've simply run out of headroom. If "Memory Compression" shows high CPU, that's the system working hard to squeeze more out of a full RAM — another hint the memory is the constraint.

High disk activity is its own kind of slowness that's easy to misread as a CPU problem. When the "disk active time" sits near 100%, the system is spending its time waiting for storage, not computing — the CPU may look idle while everything feels sluggish. Storage latency and CPU load are different things, and the fix for one is not the fix for the other.

Context matters a lot here. On an older hard disk drive, brief 100% is common — the drive is just slow and you're seeing its limit. On an SSD, sustained 100% is a red flag that something is genuinely wrong: a failing drive, a bad driver, or heavy background read/write. And a nearly-full drive (especially the one holding the pagefile) slows everything down, so free space is part of this check too.

Check three things: is the system drive an HDD (if so, an SSD is the eventual real fix), is the drive healthy (see the storage-health section and the hardware guide), and is it full? A drive that's failing is a replace-it situation, not a clean-up one — back up first if you suspect it.

Verify: after addressing the disk cause (freeing space, fixing a driver, or replacing the drive), the disk active time at idle should drop and app-open times should fall. If the disk stays pegged with nothing open, that's a strong signal to investigate drive health and drivers before anything else.

Services run in the background whether or not you have a window open. Most are essential; some are vendor services you may not need starting at every boot. A misbehaving service can peg CPU or disk with no visible app to point at, which is why "I don't have anything open but the CPU is busy" often ends up being a service.

You can view services in services.msc. Most should be set to Automatic or Manual. The honest advice here is restraint: don't start setting services to Disabled based on a generic "safe to disable" list. Many of those lists are outdated, written for a different setup than yours, and a wrong change can break something subtle. If you disable a service, do it one at a time and know how to turn it back on.

The safer tool for this whole category is the clean boot, which temporarily disables all non-Microsoft services at once. If your performance problem disappears in a clean boot, you've proven a third-party service or app is involved — and you can re-enable things in groups to find which one, instead of guessing service by service.

Modern browsers are frequently the top consumer of both CPU and memory, and they're built from many processes — typically one per tab, extension, or site. A single leaky tab, a heavy page, or a misbehaving extension can make it look like the whole computer is slow when really it's one browser doing a lot.

The browser's own task manager is the fastest way in: in Chrome and Edge, Shift + Esc opens a per-tab/per-extension CPU and memory view (Firefox has one under its about:performance page). Look for the tab or extension that's out of line. A bad or malicious extension is a classic cause of constant background CPU that has nothing to do with what you're looking at on screen.

Safe actions, in order: close tabs you're not using; restart the browser; then disable extensions you don't need (test with them all off, then re-enable in groups if something changes). If a specific extension is the culprit, remove it. Verify: the idle CPU and memory should drop once the offending tab or extension is gone — and should stay down, not creep back.

A malware or crypto-miner infection is a leading cause of sustained high CPU at idle, extra hidden startup items (slower boot), and general, unexplained lag — and it can dress itself up as a legitimate process. This is exactly why "identify the process" comes before "act on the process": an unknown process at 80% at idle is the kind of thing a scan should be explaining.

A legitimate system process has a verifiable home — typically C:\Windows\System32 or a known vendor folder — and a valid digital signature. A process running out of a temp folder or a user's AppData directory with a random or suspicious name is suspect. Right-click the process in Task Manager and open its file location to check; look up the exact name if you're unsure. Don't "delete" something you can't identify — quarantine it with your security tool instead.

The safe action is a full scan with Windows Defender (or a reputable scanner), plus a review of startup items for anything unrecognizable. A scan is reversible and low-risk; manually hunting and deleting processes is not. If the scan finds something, let it quarantine, reboot, and re-measure your baseline — the idle CPU in particular should fall if a miner was the cause.

Out-of-date or faulty drivers — especially graphics, chipset, and storage-controller drivers — can cause high CPU, high "System Interrupts," and application hangs. So can a Windows Update that installed a bad driver or broke a setting. If your performance problem started right after an update, that timing is a strong clue and worth acting on before you chase other causes.

Open Device Manager and look for any device with a warning marker — that's a direct pointer to a driver problem. Note the date of your last major update, and check whether the problem began around then. The safe path for drivers is to get them from the hardware vendor (the motherboard, GPU, or laptop maker) rather than from a third-party "driver updater" tool, which is its own common source of new problems.

Two built-in repair commands are worth running when the OS layer is suspected. sfc /scannow checks and repairs protected system files, and DISM /Online /Cleanup-Image /RestoreHealth repairs the underlying system image that SFC draws from. Run DISM first, then SFC, in an elevated prompt. Both are safe and reversible-ish (they only restore correct files), and a clean report rules the OS layer in or out. Verify: a completed, clean report plus stable behavior after a reboot.

When a CPU or GPU gets too hot, it deliberately slows itself down (thermal throttling) to avoid damage. To you this looks like the machine being fast when it's cold and getting slow after it's been running a while. The confusing part: because the chip is throttling, Task Manager may show the CPU usage dropping even though performance is falling — the opposite of what you'd expect from a workload, and a signature that points straight at heat rather than software.

This is where performance and cooling meet. A machine that's fine for ten minutes and sluggish after thirty is a thermal problem, and no amount of startup trimming or malware scanning will fix it — the fix is cooling (cleaning dust, repasting, improving airflow). If you've ruled out the software causes above and the pattern is "fine when cold, slow when warm," go measure the temperature under load.

Check temperatures with a hardware monitor, or generate an energy report with powercfg /energy, which flags cooling and power-efficiency issues. If the temperatures are high or the report mentions throttling, the next step is the cooling work described in the overheating guide. Verify: after improving cooling, the machine should sustain performance over a longer load without the slow-down, and temperatures should sit in a normal range.

A failing drive and a nearly-full drive both make a system slow, and both are worth checking before you chase software causes. Free space matters more than people expect: when the drive — especially the one holding the pagefile and temp space — runs out of room, the whole system slows down because it has nowhere to work.

Check free space first (a meaningful margin, commonly at least 10–15% free, is a reasonable target) and clear what you can with the built-in Storage Sense or Disk Cleanup. Then check drive health: on Windows, Get-PhysicalDisk in PowerShell reports a health status for each disk. A drive reporting a degraded or "pred-fail" status, or an HDD making clicking sounds, is dying — and that's a back-up-and-replace situation, not a clean-up one.

The distinction matters: "the disk is full" is fixed by freeing space; "the disk is failing" is fixed by replacing it, and cleaning it won't help. If health looks bad, back up important data immediately and plan the replacement (see the hardware guide for drive types and swapping). Verify: after freeing space, slow-open times should improve; a failing drive's errors will not — they'll keep coming until it's replaced.

Sometimes the problem is one application, not the system. If only a specific program hangs or eats CPU while everything else is fine, the fix is app-specific and changing system settings will do nothing. The single most useful question is: does it happen with other apps too? If only one app misbehaves, it's that app. If everything is slow, it's the system — and you're back in the sections above.

For a single-app problem, the usual suspects are a corrupted cache or profile, a bad update to that app, a heavy background sync it runs, or (for games and creative tools) a driver or thermal issue that only shows under that app's specific load. Work through the table below rather than guessing.

Verify: after the app-specific fix, that app should open and respond at a normal speed while the rest of the system is unchanged. If other apps are still slow, the app wasn't the whole story — return to the system-level sections.

A clean boot starts Windows with only the minimum Microsoft services and no third-party startup programs. It's the cleanest way to prove whether a third-party app or service is causing your performance problem: if the problem vanishes in a clean boot, you know it's something you added — and you can bring things back in groups to find exactly which.

It's a diagnostic state, not a permanent one. While you're in it, your antivirus and various normal features are off, so don't live there. Use it to make a measurement, then return to normal startup.

1. Open msconfig (System Configuration) → Services tab → tick "Hide all Microsoft services" → Disable all.
2. On the Boot tab, choose to disable startup items (or disable them in Task Manager → Startup).
3. Restart, then re-measure your baseline (boot time, idle CPU, a test app opening). Note how the machine behaves with a minimal start.
4. If it's fast now, re-enable in halves: turn half the services back on, reboot, test. Whichever half brings the problem back contains the culprit — then narrow within that half.
5. When you're done, restore Normal startup (msconfig → Boot tab → "Normal startup") and re-enable the services you disabled.

Verify: the test succeeds when you can name the specific service or app that, when re-enabled, returns the slowness. That named component is your cause — fix or remove it specifically, rather than leaving everything disabled.

When the on-screen symptoms are ambiguous, the system's own records often name the cause. Windows Event Viewer stores errors and warnings with timestamps, so you can line up "what the machine was doing" with "when it got slow." A recurring driver error, a disk warning, or a service failure in the logs is a direct clue you can't get from watching a meter.

Open Event Viewer with eventvwr.msc and look under Windows Logs → System and Application for red errors around the times the problem happens. You're not reading every line — you're looking for a repeated offender. Resource Monitor (resmon) is the other high-value tool: it shows live CPU, memory, disk, and network per process, and its disk view in particular shows which process is reading or writing what when the disk is busy.

The commands below cover the main diagnostic actions in this guide. Copy the ones you need — they're all standard, built-in tools.

Now you apply fixes — but in this order, one at a time, verifying after each. The sequence is safe-first and cheapest-first: the low-risk, reversible things come before anything that costs money or changes the machine. Tick each one off as you complete it; the progress is saved in your browser.

A fix has only "worked" if a measured number improved and the symptom stopped. Before you test, write down what you expect to change: which number (boot time down? idle CPU down?), by roughly how much, and over how long. "I did the thing and it feels fine" is not verification — it's a hope.

Observe for a real period, not a single reboot. For a boot fix, watch several reboots. For an idle-CPU fix, leave the machine at rest for a good while and re-check. For a hang fix, use the machine normally for a day. A fix that holds across ordinary use is a fix; one that only works immediately after you applied it may be masking the cause rather than removing it.

And if a fix didn't work, undo it before moving on. Keeping changes reversible is what lets you keep troubleshooting without compounding — you return to a clean baseline and try the next fix with a clear signal. Four questions keep this honest:

The most common way to make a performance problem worse is to remove the wrong thing in a hurry. The fixes in this guide are deliberately conservative, and the following are the things to leave alone unless you genuinely understand what they do and how to bring them back.

• Your antivirus / Windows Defender. Disabling it to "free up CPU" trades a small performance gain for a real security hole. If it's heavy, investigate why rather than switching it off.
• Core system services. Setting unknown services to "Disabled" is how people create new, stranger problems. Disable one at a time, and only ones you can identify and re-enable.
• The pagefile on a low-RAM system. Disabling the pagefile to "speed things up" can make out-of-memory situations crash instead of slow. Let it manage memory.
• Drivers with a warning — blindly uninstalling them. Update or roll back a warning driver; don't just remove it, or you can leave the device non-functional.
• "Registry cleaners" and "PC booster" utilities. These remove things without understanding dependencies and are a classic source of new failures. Use the built-in tools instead (Storage Sense, Disk Cleanup, the repair commands).
• Deleting files you can't identify. An unknown process or file is something to research or quarantine with a security tool, not something to delete by hand.

The pattern to remember: prefer the built-in, reversible, diagnostic-first tools. They're slower to reach a conclusion than a magic "optimize" button, but they don't create the next problem while solving the current one.

Some slowness is simply the hardware doing its best, and no amount of software tuning gets past a physical limit. The two upgrades that genuinely move the needle for most everyday machines are storage (an HDD replaced by an SSD) and memory (adding RAM). Both are worth it — but only when the numbers say the hardware is the bottleneck.

The rule is to upgrade only after the software causes are ruled out, and to match the upgrade to the measured constraint. A disk that's constantly pegged and is a slow HDD points at an SSD. Memory that's full, with apps hanging and high disk, points at more RAM. But adding RAM won't fix a thermal problem, an SSD won't fix a malware infection, and a new drive won't help a failing one you should be replacing — an upgrade only helps the specific bottleneck you measured.

This is exactly where the baseline you took at the start pays off. You can look at your recorded disk active time, memory usage, and boot phases and justify the purchase with evidence instead of a guess. If you'd like the details on drive types and swapping, the hardware guide covers storage and memory in depth.

Most performance loss is gradual and preventable. A machine that was fast when set up usually gets slow from accumulation — more startup items, less free disk, dust in the cooling, an infection that crept in — not from a single dramatic failure. A light, periodic routine stops that accumulation and keeps a machine fast for years.

It's a short checklist you run now and then, not a project:

• Keep the OS and drivers updated — regularly, from the vendor, not from "updater" tools.
• Keep a margin of free disk — run Storage Sense or Disk Cleanup occasionally so the drive never runs out of room to work.
• Trim the startup list periodically — new apps keep adding themselves; review the list a few times a year.
• Scan for malware now and then — a periodic full scan catches what real-time protection might miss.
• Clear the dust periodically — heat builds up over months; better airflow is the cheapest thermal fix.
• Back up regularly — so that the day a drive fails is a replacement, not a disaster.

None of this is expensive or complicated. The point is that a small, recurring habit does more for long-term performance than any one-off deep clean — and it means the problems this guide diagnoses have a much smaller chance of arriving in the first place.

If you have a specific symptom, pick the closest match below and follow the suggested route. This is the decision flow in one place: the pattern you see determines where you look first, so you're not starting from scratch.

This is the entire method as a checklist, in order. Tick each item as you complete it — your progress is saved in this browser, so you can work through it across several sessions. Copy it if you want a text version.

The performance problems in this guide connect to a few other areas of the library. These are the guides that naturally follow on from here.