# Windows Processes Explained: svchost, Runtime Broker and More

Most of the Windows processes that look alarming in Task Manager are normal parts of Windows: System, System interrupts, Service Host, Runtime Broker, Client Server Runtime and the rest each have a job, and high CPU from one of them usually points to work happening underneath, such as a driver, a service or an update. Find out what that work is before ending anything, because several of these processes cannot be ended safely and the rest come back on their own.

Below is what each common name is, where the genuine file lives, why it gets busy and how to check it. The locations and file descriptions come from a current Windows 11 installation; on your PC, right-click a row in Task Manager and choose Open file location to compare.

## At a glance

| Name in Task Manager | File | What it is | Safe to end? |
| --- | --- | --- | --- |
| System | `C:\Windows\System32\ntoskrnl.exe` ("NT Kernel & System") | The Windows kernel, process ID 4 | No |
| System interrupts | None | Time spent handling hardware interrupts | Not a process you can end |
| Memory Compression | None | Compressed memory pages kept in RAM | No |
| Service Host: … | `C:\Windows\System32\svchost.exe` | A container for one or more Windows services | No; find the service instead |
| Runtime Broker | `C:\Windows\System32\RuntimeBroker.exe` | Permission broker for Microsoft Store apps | Yes, Microsoft suggests it when memory is high |
| Windows Explorer | `C:\Windows\explorer.exe` | The taskbar, Start, desktop and File Explorer | Use Restart, not End task |
| Desktop Window Manager | `C:\Windows\System32\dwm.exe` | Draws every window to the screen | No |
| Client Server Runtime Process | `C:\Windows\System32\csrss.exe` | Core user-mode part of Windows | No |
| Windows Start-Up Application / Windows Logon Application | `wininit.exe` / `winlogon.exe` in `C:\Windows\System32` | Startup and sign-in | No |
| Host Process for Windows Tasks | `C:\Windows\System32\taskhostw.exe` | Runs Windows tasks | Leave it |

## System, System interrupts and Memory Compression

**System** is the Windows kernel. It always has process ID 4, and its file, `ntoskrnl.exe`, describes itself in Properties › Details as "NT Kernel & System". High CPU here tells you that kernel-level work is busy, not which part of it, and drivers and pending updates are the places to start. Microsoft's [driver update guide](https://support.microsoft.com/en-us/windows/update-drivers-through-device-manager-in-windows-ec62f46c-ff14-c91d-eead-d7126dc1f7b6) says the best way to get driver updates is Windows Update, and if a recent driver made things worse, Device Manager › the device's Properties › Driver › Roll Back Driver undoes it (administrator rights needed).

**System interrupts** is not a program and has no file. It is the time processors spend responding to hardware. Microsoft's [CPU analysis guide](https://learn.microsoft.com/en-us/windows-hardware/test/wpt/cpu-analysis) explains the mechanism: a device such as a network card raises an interrupt, Windows runs an interrupt service routine (ISR), which usually schedules a deferred procedure call (DPC) for the rest of the work, and while a processor runs DPCs and ISRs no threads can run on it. That is why heavy interrupt time can show up as audio crackle or stutter. Some interrupt time is always there while hardware is in use; a constant high figure on an idle PC points at a driver or a device.

To find which one, record a trace from an administrator Command Prompt. The [WPR command reference](https://learn.microsoft.com/en-us/windows-hardware/test/wpt/wpr-command-line-options) documents `-start` and `-stop`, and the built-in GeneralProfile includes DPC and interrupt events:

```cmd
wpr -start GeneralProfile
wpr -stop C:\Temp\interrupts.etl
```

Run the first line, wait while System interrupts is high, then run the second; the folder must exist. Open the file in Windows Performance Analyzer and look at the DPC/ISR graph, whose Module column names the driver file containing the busy routine. A simpler test without tools: unplug USB devices and docks one at a time and watch the number.

**Memory Compression** keeps rarely used memory pages in RAM in compressed form instead of writing them to the page file. When Microsoft [introduced the compression store](https://blogs.windows.com/windows-insider/2015/08/18/announcing-windows-10-insider-preview-build-10525/) in Windows 10, it explained that the store grows exactly when memory is being freed for other programs, which is why it can look large. A big figure follows memory pressure from other programs rather than causing it. See [high memory usage on Windows](/windows/blog/windows-high-memory-usage) for finding what is actually using it.

## Service Host (svchost.exe): find the service inside

Microsoft's [service host article](https://learn.microsoft.com/en-us/windows/application-management/svchost-service-refactoring) describes `svchost.exe` as a shared-service process that loads services from DLL files. Since Windows 10 version 1703, PCs with more than 3.5 GB of RAM run most services in their own Service Host process, which is why Task Manager shows dozens of them and why each row is now labelled with the service it holds, such as "Service Host: Windows Update". Some services, such as Base Filtering Engine with Windows Firewall, stay grouped.

"svchost high CPU" therefore has no single answer: the busy part is a service. Three ways to name it:

1. In Task Manager's Processes view, expand the busy Service Host row. The services inside are listed under it.
2. Right-click the row and choose Go to details to get its PID, then open the Services page (a tab in Windows 10), which lists every service with the PID that runs it.
3. From Command Prompt, use [tasklist](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/tasklist), where `/svc` lists the services in each process:

```cmd
tasklist /svc /fi "IMAGENAME eq svchost.exe"
tasklist /svc /fi "PID eq 1234"
```

Replace `1234` with the PID from Task Manager. Then deal with the service, not the host: Windows Update finishing an install or wsappx deploying a Store app each has its own fix. Ending a Service Host stops every service inside it at once and does not stop whatever asked the service to work.

## Runtime Broker, Windows Explorer and Desktop Window Manager

**Runtime Broker** (`RuntimeBroker.exe`) runs in your session and, per Microsoft's [Runtime Broker article](https://support.microsoft.com/en-us/windows/runtime-broker-is-using-too-much-memory-ca6ed4e3-2a36-964c-4d2e-8c93980d8a98), manages permissions on your PC for apps from Microsoft Store. It normally uses a few megabytes. Microsoft's own threshold: if it uses more than 15% of memory, an app is probably misbehaving, and ending the Runtime Broker task and restarting the PC is the suggested fix.

**Windows Explorer** (`explorer.exe`, directly in `C:\Windows`) is not only File Explorer windows; it also draws the taskbar, Start and the desktop. If it hangs or the screen goes blank, Microsoft's [blank screen guide](https://support.microsoft.com/en-us/windows/hardware/display-graphics/troubleshooting-blank-screens-in-windows) says to open Task Manager with `Ctrl + Shift + Esc`, right-click Windows Explorer and select Restart, or, if it is missing, use File › Run new task and type `explorer.exe`.

**Desktop Window Manager** (`dwm.exe`) composes every window into the image on your screen. Microsoft's [DWM overview](https://learn.microsoft.com/en-us/windows/win32/dwm/dwm-overview) describes how windows draw to off-screen surfaces that DWM renders onto the display. Its work follows what is on screen. Do not end it; see [Desktop Window Manager high GPU](/windows/blog/desktop-window-manager-high-gpu) for what to check.

## csrss, wininit, winlogon and taskhostw

**Client Server Runtime Process** (`csrss.exe`) is, in Microsoft's words in its [debugging notes](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/debugging-csrss), the user-mode process that controls the underlying layer for the Windows environment, and since Windows 10 it is a protected process. There is one per session, so two or more is normal. It should sit near zero CPU; there is nothing to tune and no reason to end it.

**wininit.exe** (file description "Windows Start-Up Application") and **winlogon.exe** ("Windows Logon Application") handle startup and sign-in. Microsoft's [Winlogon page](https://learn.microsoft.com/en-us/windows/win32/secauthn/winlogon) says Winlogon creates the desktops for the window station and implements time-out operations, and it registers the secure attention sequence, the `Ctrl + Alt + Delete` you press to reach the security screen. Both should be idle almost all the time. Leave them alone.

**Host Process for Windows Tasks** (`taskhostw.exe`) runs tasks for Windows, and Microsoft does not publish a dedicated page for it. If it stays busy, Task Scheduler (Task Scheduler Library › Microsoft › Windows) shows which tasks are running; let them finish rather than ending the host. A `taskhostw.exe` outside `C:\Windows\System32` is a different matter, covered below.

## Busy for a reason: Defender, updates, search and Store apps

These four are usually doing real work that ends on its own, and each has a full guide:

- **Antimalware Service Executable** (`MsMpEng.exe`, under `C:\ProgramData\Microsoft\Windows Defender\Platform\<version>\`) is Microsoft Defender scanning. See [Antimalware Service Executable high CPU](/windows/blog/antimalware-service-executable-high-cpu).
- **Windows Modules Installer Worker** (`TiWorker.exe`, in a servicing-stack folder under `C:\Windows\WinSxS`) does update work for the Windows Modules Installer service (`C:\Windows\servicing\TrustedInstaller.exe`). See [Windows Modules Installer Worker high CPU](/windows/blog/windows-modules-installer-worker-high-cpu).
- **Microsoft Windows Search Indexer** (`C:\Windows\System32\SearchIndexer.exe`) builds the search index. See [Windows Search Indexer high CPU](/windows/blog/windows-search-indexer-high-cpu).
- **wsappx** is a Service Host for Store app deployment and licensing. See [wsappx high CPU](/windows/blog/wsappx-high-cpu-windows).

## Spotting a fake system process

Malware sometimes borrows a system name. The name proves nothing; the location and signature do.

1. In Task Manager, right-click the process and choose Open file location. `svchost.exe`, `csrss.exe`, `RuntimeBroker.exe` or `taskhostw.exe` running from a user folder, `AppData`, `ProgramData` or `Temp` is not the Windows file. Watch for near-miss spellings too, such as `scvhost.exe`.
2. Right-click the file › Properties › Details. A genuine file shows Microsoft Corporation and the description from the table above.
3. Check the signature. Most Windows files are signed through a Windows catalog rather than inside the file, so their Properties has no Digital Signatures tab; a missing tab is not a warning sign. [Get-AuthenticodeSignature](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.security/get-authenticodesignature) reads catalog signatures too. Point it at the path you found:

```powershell
Get-AuthenticodeSignature C:\Windows\System32\svchost.exe | Format-List Status, SignatureType, SignerCertificate
```

A genuine file reports `Valid`, usually `Catalog`, with a Microsoft Windows certificate. To check a whole folder, Microsoft's [Sigcheck](https://learn.microsoft.com/en-us/sysinternals/downloads/sigcheck) lists unsigned files with `sigcheck -u -e c:\windows\system32`, and Microsoft says to investigate any file that is not signed.

If anything looks wrong, scan. Microsoft's [Windows Security guide](https://support.microsoft.com/en-us/windows/virus-and-threat-protection-in-the-windows-security-app-1362f4cd-d71a-b52a-0b66-c2820032b65e) puts Scan options under Virus & threat protection; Microsoft Defender Antivirus (offline scan) restarts the PC and scans before Windows loads, so persistent malware has a harder time hiding, and the results appear in Protection history. Do not delete the suspicious file by hand while it is running, and never delete a file from `C:\Windows\System32` because its name looked odd.

## Where Mole fits

Mole's Status page lists processes grouped by the app that owns them, with CPU and memory summed for each group, so repeated helper processes add up to one row. Choosing Why is this running? from a row's menu shows its executable path and, for Service Host rows, the Windows services it hosts, busiest first; Show in File Explorer opens the file's folder for the location check above. Mole does not offer Terminate or Force Quit for Windows services, for anything running from the Windows folder, or for the System process itself, and labels those rows as System instead. As the [help page](/windows/help) puts it, keep system processes and processes shared with other apps.

Mole does not change drivers, services or Defender settings, and it does not detect malware. For high CPU from ordinary apps, see [High CPU usage on Windows](/windows/blog/windows-high-cpu-usage).

## FAQ

### Why is svchost.exe using so much CPU?

Service Host only holds services; one of them is busy. Expand the row in Task Manager or run `tasklist /svc` to name the service, then handle that service, such as Windows Update or a Store app install.

### What is System interrupts and can I disable it?

It is the time Windows spends handling hardware interrupts and their deferred work, not a program, so there is nothing to disable. Constant high usage points to a driver or device; update or roll back drivers, or record a trace to see which driver module is busy.

### What is Runtime Broker and is it safe to end?

It manages permissions for Microsoft Store apps. Microsoft says that if it uses more than 15% of memory, you can end the task in Task Manager and restart the PC.

### How do I know if a Windows process is a virus?

Check where the file is and who signed it: genuine core processes run from `C:\Windows` or `C:\Windows\System32` and carry a valid Microsoft signature, often a catalog signature. If the location or signature is wrong, run a Microsoft Defender offline scan.


Canonical: https://mole.fit/windows/blog/windows-processes-explained