Windows中“process object（进程对象）”的定义及与EPROCESS/PEB的关系疑问

Great questions—these are core concepts in Windows internals, so let’s unpack them step by step.

Q1: How do Process Objects relate to EPROCESS and PEB? #

Let’s break down the hierarchy and connections clearly:

• A process object is the formal kernel object managed by the Windows Object Manager. Every kernel object has two key components: an OBJECT_HEADER (handles reference counting, security, type metadata, etc.) and an object body. For process objects, this body is exactly the EPROCESS block. Think of the process object as a wrapper that adds system-wide management capabilities to the raw EPROCESS data.
• The EPROCESS structure is the kernel’s internal blueprint for the process. It stores all kernel-state critical info: process ID, handle table, memory management structures, thread lists, scheduling data, and a pointer to the PEB. This is what the kernel uses day-to-day to manage the process behind the scenes.
• The PEB (Process Environment Block) lives in user-mode address space and holds user-specific process data: loaded module lists, environment variables, heap details, runtime configuration, and more. The EPROCESS block includes a Peb member that points to this user-mode structure—creating the link between the kernel-managed process object and the user-mode process context.

In short: Process Object = OBJECT_HEADER + EPROCESS; EPROCESS acts as the bridge between the kernel’s process object and the user-mode PEB.

Q2: What exactly is a Process Object, where is it stored, and what’s it used for? #

What it is #

A process object is the Windows kernel’s standardized, system-wide representation of a process (running, suspended, or terminating). It’s the official "identity card" for processes that the Object Manager uses to enforce consistent rules across the OS.

Where it’s stored #

• Process objects live entirely in the kernel address space—user-mode code can’t directly access their raw memory. They’re allocated from kernel memory pools (either non-paged, for critical data that can’t be swapped out, or paged, for less critical info).
• The Object Manager maintains a dedicated namespace for process objects (typically under \Processes in the system object namespace), so they can be referenced via handles or object paths.

Key uses #

• Lifecycle management: The kernel relies on process objects to create (NtCreateProcess), suspend, resume, and terminate processes. The reference count in the OBJECT_HEADER ensures the process isn’t destroyed while still being used by other system components or applications.
• Access control: Each process object has a security descriptor that defines which users or processes can perform actions like opening a handle, terminating the process, or querying its metadata. This is why tools like Task Manager need proper permissions to kill certain processes.
• Inter-process interaction: Handles to process objects let other processes interact with the target process—for example, injecting threads, reading/writing memory, or querying process stats. When you call OpenProcess from user-mode, you’re requesting a handle to this kernel object.
• Uniform object management: By wrapping EPROCESS into a process object, the Object Manager can apply the same rules (reference counting, security, naming) that it uses for other kernel objects (like files, events, or mutexes). This keeps the kernel’s object system consistent and manageable.
• Metadata tracking: The OBJECT_HEADER attached to the process object stores extra system-wide metadata, like audit information, object type details, and synchronization data that the kernel needs to manage the process at a system level.

内容的提问来源于stack exchange，提问作者Kyoma