CPU at 100% in Windows when nothing is running

---

You open Task Manager because the machine is crawling, and the CPU column says 100%. You scan the process list and nothing there accounts for it. The top entry is using 4%.

This is a specific and very common situation, and it has a small number of specific causes. Almost all of them are identifiable in about five minutes, without installing anything.

First: make sure you are reading the right number

Two things trip people up before the diagnosis even starts.

Sort the Details tab, not the Processes tab. The Processes tab groups an application with all its child processes and shows you the total. That is useful for "which app", useless for "which process". Details gives you one row per process. Click the CPU column twice to sort descending.

Task Manager hides what you cannot see. By default the Details tab shows only your own processes. Click "Show processes from all users" — a great many of the real answers below run as SYSTEM, LOCAL SERVICE or NETWORK SERVICE, and are simply not on screen until you do this.

If the total says 100% and the visible rows add up to 12%, you are almost always looking at a filtered list.

The usual suspects, by name

Sorted roughly by how often they turn out to be the answer.

MsMpEng.exe — Antimalware Service Executable. Windows Defender's scanner. Legitimately heavy during a full scan, and it schedules those when it thinks you are idle, which is frequently wrong. It also has a well-known pathology where it and a third-party antivirus scan each other's activity in a loop. Do not disable Defender; do check whether a scan is running, and do add build directories and VM images to exclusions if you are a developer.

TiWorker.exe / Windows Modules Installer Worker. Windows Update, applying things. It will run hot for a long stretch and then stop for good. If it never stops across several days, the update component itself is stuck — that is a different problem with a different fix.

SearchIndexer.exe. Content indexing. Spikes for hours after you move a large amount of data, then settles. If it is permanently busy, something is churning files, or the index is corrupt and needs rebuilding from Indexing Options.

System Interrupts. This one is not a process. It is Windows accounting for time spent in interrupt and deferred-procedure calls — that is, in drivers. If this is high, no application is at fault and no application will fix it. It is a driver, usually storage, network or chipset, and occasionally failing hardware.

WmiPrvSE.exe — WMI Provider Host. Runs on behalf of whatever is querying it, which on a work laptop is usually the management agent. It is the messenger.

Service Host: something. A svchost group. Right-click → Go to service(s) to see which service inside it is actually responsible.

A browser's GPU or renderer process. Chrome and Edge both have an internal task manager — Shift+Esc — that maps a busy process to the specific tab or extension. That is the only practical way to identify which of eleven identical entries is the offender.

The measurement is often the problem

Two honest caveats, because "100%" is less precise than it looks.

Modern CPUs have performance and efficiency cores, and boost clocks that move. A process pinned to two E-cores can report a modest percentage while genuinely saturating everything it has been given. Percentages are a poor proxy for "is this thing the bottleneck".

Task Manager also costs something to run, updates on an interval, and can attribute a burst to whatever happened to be sampled. If a number looks impossible, check it against Resource Monitor before you act on it.

The useful signal is not the percentage. It is whether one named process is consistently at the top across a minute of watching.

When there is genuinely nothing there

If you have shown all users, sorted Details, and the arithmetic still does not work, there are three remaining explanations.

Drivers, appearing as System Interrupts, as described above. Process Explorer breaks this down further, and Windows Performance Recorder further still, if you want to name the specific driver.

Thermal or power limiting. The CPU is not busy, it is slow. Everything takes longer, so everything queues, so utilisation reads high for work that should have been over instantly. A laptop that is hot, on battery saver, or on a weak charger will do exactly this. Check clock speed on the Performance tab: if it is sitting well under base clock under load, you have found it.

Something hiding. Rare, but real. A miner will often suspend itself when Task Manager opens. If the fans are loud until you look and then stop, run a scan with a second opinion scanner rather than only the resident one.

What does not help

The advice that turns up under this search, and what is actually wrong with it:

• "Free up RAM with an optimiser." Wrong resource entirely, and counterproductive on its own terms.
• "Disable Superfetch/SysMain." Occasionally correct on old spinning disks. On an SSD it usually changes nothing, and it is proposed indiscriminately.
• "Set your power plan to High Performance." Makes the CPU boost more eagerly. It does not reduce the work; on a laptop it can make the thermal case above worse.
• "Disable Windows Update." Trades a temporary problem for a permanent one.
• "End task on anything with a strange name." csrss.exe, dwm.exe, lsass.exe and ntoskrnl.exe all have strange names and all are Windows itself.

The pattern is that all of it is a fix applied before a diagnosis. Find the process name first. Everything after that is easy, and most of it is specific to the one thing you found.

When it is contention rather than a culprit

There is a version of this where the diagnosis comes back clean. No single process is at fault. There are just twenty of them, each perfectly reasonable, and collectively they are using everything — and the application you actually care about is queued behind the lot.

Nothing is broken there, so nothing gets "fixed". What is wrong is the ordering: Windows is time-slicing fairly between the render you are waiting on and a chat client redrawing an avatar.

That is the problem AppFreeze exists for. It notices which app you are working in, steps everything else down a scheduling priority while you are busy, and puts them all back the way it found them when you stop. Nothing is killed and nothing is disabled — the queue is simply reordered in favour of the thing you are waiting for.

It is in development. If the description above is a familiar afternoon, the newsletter below is how you will hear when it ships.