Processes & threads

The Executive named the Process/Thread Manager as one of its core components. This chapter is where its two central abstractions — processes and threads — get their full treatment.

A process is a container; a thread is what actually runs

The distinction is foundational and worth stating precisely: a process is a security and resource container — an address space, a token, a handle table, a set of policies — while a thread is the actual unit of execution, the thing the scheduler (Scheduling) picks to run on a CPU. A process with zero threads does nothing; all the interesting runtime behavior happens at the thread level, inside the boundary the process defines.

The kernel represents these with two structures worth knowing by name because they show up constantly in debugging and forensic contexts: EPROCESS, one per process, and ETHREAD, one per thread. Tools like Process Explorer, WinDbg, and memory-forensics frameworks are, in large part, ways of reading and presenting the fields of exactly these structures.

What a process actually carries

• An address space — private virtual memory, covered fully in Memory management.
• A primary token — the security identity described in Access tokens.
• A handle table — references to every kernel object (files, events, other processes, sections) the process currently holds open, managed through the Object Manager covered in Kernel objects.
• One or more threads, each with its own stack, register context, and scheduling state.
• Bookkeeping: session ID, priority class, job membership (if any — see Job objects), and more.

A worked example: what Task Manager is actually summarizing

Task Manager's one row per process is a heavy simplification of everything above — it typically shows you an aggregate CPU/memory figure and a friendly name, not the handle table, the token's group memberships, or the thread-level scheduling state. Switching to Process Explorer's more detailed views, or Get-CimInstance Win32_Process in PowerShell, starts to expose the richer structure: multiple threads per process, a session ID showing which session it belongs to, and a parent process ID showing how it was created — none of which is visible from the simple summary view most people use day to day.

Not every process is "an app"

A concrete, easily-overlooked example: the System process (PID 4 on essentially every Windows machine) isn't a desktop application at all — it hosts core kernel-mode worker threads and doesn't correspond to a user-launched program the way notepad.exe does. Seeing it consuming CPU or holding handles is often completely normal, precisely because it's structurally different from an ordinary application process, not a sign that "something" launched unexpectedly.

A common mistake

Treating a process as synonymous with "one running program, doing one thing" undersells the actual structure underneath. A single process can host many threads doing genuinely different work concurrently (a web server handling many connections, each on its own thread), can hold handles to dozens of other kernel objects, and can itself be one member of a larger family — a parent/child hierarchy, or a shared job object — that behaves as a unit for certain purposes even though each process remains its own independent container.

Where this connects

• Kernel objects covers the handle-table mechanism referenced above in full.
• Job objects covers how multiple processes can be grouped under shared policy.
• The VAD tree covers exactly what's inside a process's address space.