System

The Kernel's Own Processes: System, Registry and Memory Compression

The kernel's own process, always PID 4, with no program file behind it.

Normal Processes
Open it in the tree

Normal Profile

These are the values a genuine copy shows. Treat any value that differs as a lead.

Parent: Read the parent your tools show for PID 4 on a clean machine of the same build, and expect the same on every machine of that build.
Path: No program fileSource: Microsoft Learn (archived blog): The Case of the System Process CPU Spikes (opens in a new tab)The kernel's own file, ntoskrnl.exe, lives in System32, and SigmaHQ flags one that runs outside System32 and the few other Windows folders its rule allows.
Account: Read it from the token on a clean machine of the same build, with Get-Process -IncludeUserName live or windows.getsids in memory.
Session: Read its SessionId with Get-CimInstance Win32_Process, or windows.pslist in memory, on a clean machine of the same build.
Instances: One, always PID 4Source: Microsoft Learn (archived blog): How to troubleshoot high CPU in the System process (opens in a new tab)Registry and Memory Compression are separate minimal processes the kernel keeps, not copies of System.
Starts: At boot, before smss.exeSource: Microsoft Learn: Windows startup issues troubleshooting (opens in a new tab)Fast Startup hibernates the kernel session when Windows shuts down, so its start dates from the last full boot, such as a restart.
Command Line: Read it elevated with Get-CimInstance Win32_Process on a clean machine of the same build, and compare.
Signed By: It has no file of its own to check, so check the drivers it runs instead, with Process Explorer's DLL view or Sigcheck.

No public source states this value, so compare with a clean machine of the same Windows build.

Why It Matters

System sits at the root of the process tree, so a second System, a System with any process ID (PID) but 4, or one with a program file behind it is an impostor. Its threads run kernel and driver code, so trouble inside it points at a driver, not at a program.

What It Does

System is the kernel's own process. Microsoft gives its process ID (PID), the number Windows uses to tell running processes apart, as always 4. It has no program file, because its threads run in kernel mode for the memory manager, the cache manager and loaded device drivers. That is why Process Explorer's DLL view on System lists kernel modules and drivers, not DLLs. It is there from boot, before smss.exe, the first program the kernel starts, and it lasts until Windows shuts down. So a second System, a System at any PID but 4, or one with a program file on disk is not the kernel's.

Windows 10 added two more minimal processes that hold data for the kernel. The memory compression store, pages Windows compresses instead of writing them to disk, first lived in System's working set, its pages in RAM, and had a process of its own by December 2017. From Insider build 17063, the Registry process holds hive data such as HKLM\SOFTWARE.

Fast Startup hibernates the kernel session at each shutdown, so System keeps the start time of the last full boot, such as a restart.

Three processes on a Windows machine belong to the kernel and have no program file behind them. This table shows what each one holds, so you can tell them apart from a program that borrows one of their names.

The Kernel's Own Processes

Process	What It Holds
`System`	Threads for the kernel and loaded device drivers, with no program file, always at PID 4
`Registry`	Registry hive data held for the kernel, such as HKLM\SOFTWARE, from Insider build 17063
`Memory Compression`	The memory compression store, pages Windows compresses in memory, which began inside System's working set

How Attackers Abuse It

Each line is a way this process is misused, with the page that shows how to spot it.

Malware takes the name System or Registry for a program on disk, where the genuine processes have no program file.Wrong Path
A driver with no valid signature, or an unexpected signer, loads into the kernel and runs its code in System's threads.Unsigned or Oddly Signed Modules

In the Process Tree

These are the rows of the process list that this page explains.

SystemKernel and driver threadsOpen it in the tree: System

RegistryHive data for the kernelOpen it in the tree: Registry

Memory CompressionCompressed memory pagesOpen it in the tree: Memory Compression

Red Flags

Each sign below links to the page that shows how to confirm it.

A second process named System, or a System whose PID is not 4.Extra or Missing Instances
A program named System or Registry, or an ntoskrnl.exe outside System32.Wrong Path
A driver loaded in it with no valid signature or an unexpected signer.Unsigned or Oddly Signed Modules

How to Check It

Each page shows how to check this process, on a running machine and in a memory image.

What Records It

Each record names its log and what must be switched on to get it.

Record and Where It Lands	What to Read	How to Turn It On
`DeviceProcessEvents` (opens in a new tab)Each row is a process creation or a related event, naming the new process, the process that created it and that creator's parent.Defender XDR, advanced hunting	A program named System, or an ntoskrnl.exe outside System32, is an impostor, because the genuine System has no program file.	The Defender for Endpoint sensor on the device
4688 `A new process has been created` (opens in a new tab)`Security`It is written on the computer the process ran on.	A New Process Name ending in System.exe, or ntoskrnl.exe outside System32, with the Creator Process Name behind it.Process Trees and Call Chains shows how to read it.	Turn on Audit Process Creation. For the command line, also turn on Include command line in process creation events.
1 `Process creation` (opens in a new tab)`Microsoft-Windows-Sysmon/Operational`It is written on any Windows computer running Sysmon.	An Image ending in System.exe, or ntoskrnl.exe outside System32, with the ParentImage that started it.Process Trees and Call Chains shows how to read it.	Run Sysmon with ProcessCreate events in its configuration.

Hunt It

The same hunt is written for four tools, so pick the one you use. Defender XDR and Sentinel queries are in KQL, which you paste into Advanced hunting in the Defender portal or into Sentinel's Logs page. Splunk queries are in SPL, for its Search page, and Velociraptor queries are in VQL, which you run as a hunt.

Sees Related ActivityDeviceProcessEvents

Reads the DeviceProcessEvents table in Defender XDR advanced hunting, from devices onboarded to Defender for Endpoint. The kernel creates System without a program file, so this finds impostors, not System itself. A row with a folder on disk is a program borrowing the name, and a lead until its signer and creator are checked.

KQLDefender XDR, Advanced hunting

// Programs named like System, Registry or the kernel file: the genuine System has no program file and is always PID 4DeviceProcessEvents| where Timestamp > ago(30d)| where FileName in~ ("System", "System.exe", "Registry", "Registry.exe")    or (FileName =~ "ntoskrnl.exe" and FolderPath !in~ (@"C:\Windows\System32\ntoskrnl.exe", @"C:\Windows\System32"))| project Timestamp, DeviceName, FileName, FolderPath, ProcessId, ProcessCommandLine, AccountName, InitiatingProcessFileName, InitiatingProcessFolderPath| order by Timestamp desc

Changes by Version

This process has changed between versions, so read a machine against its own.

Windows 10 (Insider build 10525) The memory compression store arrives, kept at first in System's working set.
Windows 10 (Insider build 17063) Hive data moves out of kernel paged pool into the new Registry process.