KPROCESS

The KPROCESS structure (formally _KPROCESS) is the Kernel’s portion of the Executive’s EPROCESS structure. The latter is the process object as exposed through the Object Manager. The KPROCESS is the start of it.

Availability

The process is a fundamental object in Windows. The KPROCESS exists in all versions, i.e., 3.10 and higher.

Documentation Status

For being fundamental, the KPROCESS has never been secret as something that exists. It is, however, deeply internal. It is not formally documented. Even among C-language headers in the Device Driver Kit (DDK) or Windows Driver Kit (WDK), the KPROCESS is only ever declared as an opaque type: its contents are never defined.

Though Microsoft is not known ever to have published a C-language definition of the KPROCESS, the practical equivalent is disclosed as type information in public symbol files for the kernel starting with Windows 2000 SP3. One earlier disclosure of type information is known from a statically linked library, named craShlib.Lib (sic), which Microsoft distributed with the Win32 SDK in 1996. Though it is supplied to help with building the user-mode Dr. Watson sample, it has type information that matches the kernel-mode KPROCESS for version 4.0.

Access

Presumably because the KPROCESS is only as much of the process’s representation as needed by the core of the kernel, it has very little exposure independently of its nesting in the EPROCESS as the latter’s Pcb member. Where code outside the kernel refers to a process by address, what will almost always be wanted is the larger EPROCESS. Notable exceptions are the KTHREAD and KAPC_STATE: being other creatures of the kernel’s core, these each have a member named Process that points to a KPROCESS.

Layout

The KPROCESS structure is plainly internal to the kernel and its layout changes greatly between Windows versions and even between builds. Throughout this article, early and late builds within a version have the following cut-offs:

• late 5.1 begins with Windows XP SP2;
• late 5.2 begins with Windows Server 2003 SP1;
• late 6.0 begins with Windows Vista SP1 (which doubles as Windows Server 2008).

Though the KPROCESS is highly variable, it has grown mostly by appending. This article attempts to lay out the structure’s members as one sequence for all versions. The following changes of size are known:

These sizes, and the offsets, types and names in the tables that follow, are from Microsoft’s public symbol files for the kernel starting with Windows 2000 SP3. Since symbol files for earlier versions do not contain type information for the KPROCESS, what’s known for earlier versions is instead inferred from what use the kernel is seen to make of the KPROCESS. Sizes are relatively straightforward, even without symbol files, but Microsoft’s names and types are something of a guess. Where use of a member corresponds closely with that of a version for which Microsoft’s symbols are available, it seems reasonable to suppose continuity. Some use, however, has no correspondence, the code having changed too much. Even where the use hasn’t changed, tracking it down exhaustively would be difficult, if not impossible, even with source code.

Layout

For the detailed layout in the tables that follow, it helps with some processor-dependent definitions if a macro, say MAX_PROC_GROUPS, is presumed for the maximum number of processor groups:

• 1 for 32-bit Windows and for 64-bit Windows before version 6.1;
• 4 for 64-bit Windows in version 6.1;
• 20 for 64-bit Windows in version 6.2 and higher.

Note that the intention here is not to say that these limits on processor groups are permanent, let alone that they should be depended on when programming, just that they’re what are built in to various members of the KPROCESS in the presently observed Windows versions.

Original

It is well known even to user-mode programmers that a process can be waited on until it gets signalled, as happens when the process ends its execution. In version 3.50 and higher, this is effected by having the KPROCESS start with a DISPATCHER_HEADER so that it can be waited on by passing its address to such functions as KeWaitForSingleObject. In this header, the Type is ProcessObject (3) from the KOBJECTS enumeration.

It was not always so, however. In all versions, the EPROCESS can be waited on by passing a handle to NtWaitForSingleObject, but what’s actually waited on in version 3.10 is a KEVENT at offset 0x70 in the EPROCESS. The KPROCESS originally has no role in this. It does not begin with a DISPATCHER_HEADER, but like the other kernel objects that do not have this header, it does begin with a Type and Size. In version 3.10, this Type was surely named ProcessObject, as for later versions, but its numerical value is 0x0E.

USHORT Type;

USHORT Size;

ULONG StackCount;

DISPATCHER_HEADER Header;

LIST_ENTRY ProfileListHead;

Whether the header is the full DISPATCHER_HEADER or just something a little like one, it has somehow always been followed by the list head for process-specific KPROFILE objects. Pretty much everything else that’s original to the KPROCESS was rearranged even as soon as versions 3.50 and 3.51.

LIST_ENTRY ReadyListHead;

LIST_ENTRY SwapListEntry;

LIST_ENTRY ThreadListHead;

LARGE_INTEGER KernelTime;

ULONG KernelTime;

LARGE_INTEGER UserTime;

ULONG UserTime;

ULONG_PTR DirectoryTableBase [2];

ULONG_PTR DirectoryTableBase;

ULONG_PTR Unused0;

ULONG Iopl;

LONG ThreadQuantum;

KAFFINITY ActiveProcessors;

KAFFINITY Affinity;

KGDTENTRY LdtDescriptor;

KIDTENTRY Int21Descriptor;

USHORT IopmOffset;

UCHAR Iopl;

UCHAR Unused1;

UCHAR VdmFlag;

UCHAR Unused;

UCHAR Unused2;

KAFFINITY ActiveProcessors;

KAFFINITY volatile ActiveProcessors;

ULONG KernelTime;

ULONG UserTime;

LIST_ENTRY ThreadListHead;

ULONG_PTR ProcessLock;

ULONG ProcessLock;

ULONG Spare0;

ULONG ProcessTimerDelay;

ULONGLONG DeepFreezeStartTime;

KAFFINITY_EX Affinity;

ULONGLONG AffinityPadding [0x0C];

LIST_ENTRY ReadyListHead;

LIST_ENTRY SwapListEntry;

SINGLE_LIST_ENTRY SwapListEntry;

KAFFINITY_EX volatile ActiveProcessors;

ULONGLONG ActiveProcessorsPadding [0x0C];

PVOID VdmTrapcHandler;

PVOID Reserved1;

PVOID InstrumentationCallback;

LIST_ENTRY ThreadListHead;

KSPIN_LOCK ProcessLock;

KAFFINITY Affinity;

USHORT StackCount;

union {
    struct {
        /*  bit fields, follow link  */
    };
    LONG ProcessFlags;
};

union {
    struct {
        /*  bit fields, follow link  */
    };
    LONG volatile ProcessFlags;
};

BOOLEAN AutoAlignment;

ULONG ActiveGroupsMask;

CHAR BasePriority;

UCHAR State;

CHAR ThreadQuantum;

CHAR QuantumReset;

BOOLEAN AutoAlignment;

UCHAR State;

Whatever may have motivated the reordering of byte-size members at the end in versions 3.10 to 3.51, all these versions end the structure with unused space because of alignment: six bytes in 3.10 because of the structure’s 8-byte alignment (from using LARGE_INTEGER for KernelTime and UserTime); two bytes in versions 3.50 and 3.51.

Appended for Windows NT 4.0

Version 4.0 adds just two bytes which anyway fit into the earlier versions’ alignment padding. Neither stays put.

UCHAR ThreadSeed;

BOOLEAN DisableBoost;

The ThreadSeed helps to spread the process’s threads over the available processors. It is initialised pseudo-randomly (from the low byte of KeTickCount) when the process is created. As each thread is initialised, the process’s ThreadSeeed (modulo the number of processors) becomes that thread’s IdealProcessor and is then incremented in anticipation of the next thread. When Windows 7 greatly increased the potential number of processors, the single-byte processor number widened to the four-byte processor index and the ThreadSeed was reworked elsewhere in the structure.

Appended for Windows 2000

UCHAR PowerState;

BOOLEAN DisableQuantum;

UCHAR Spare [2];

Appended for Windows XP

Additions for version 5.1 begin with the bytes that version 5.0 left explicitly Spare at its end.

UCHAR IdealNode;

BOOLEAN Visited;

UCHAR Spare;

union {
    KEXECUTE_OPTIONS Flags;
    UCHAR ExecuteOptions;
};

UCHAR Spare3;

KEXECUTE_OPTIONS Flags;

Inserted for Windows 7

ULONG ThreadSeed [MAX_PROC_GROUPS];

USHORT ThreadSeed [MAX_PROC_GROUPS];

USHORT ThreadSeedPadding [0x0C];

USHORT IdealProcessor [MAX_PROC_GROUPS];

USHORT IdealProcessorPadding [0x0C];

USHORT IdealNode [MAX_PROC_GROUPS];

USHORT IdealNodePadding [0x0C];

USHORT IdealGlobalNode;

KEXECUTE_OPTIONS Flags;

USHORT Spare1;

UCHAR Unused1;

USHORT IopmOffset;

ULONG Unused2;

ULONG Unused4;

KSCHEDULING_GROUP *SchedulingGroup;

Appended for Windows Server 2003 SP1

While the first version with x64 builds found a few opportunities to save space by converting the AutoAlignment, DisableBoost and DisableQuantum booleans to bit fields in what were then the new ProcessFlags, it widened the StackCount and moved it to the end. Version 6.1 merged the ancient State into the StackCount as a bit field.

ULONG_PTR StackCount;

KSTACK_COUNT StackCount;

KSTACK_COUNT volatile StackCount;

LIST_ENTRY ProcessListEntry;

On x64 builds only, the ProcessListEntry links the KPROCESS into a global list whose head is an internal kernel variable that symbol files name KiProcessListHead. The only known use is for Kernel Patch Protection (perhaps more commonly known as PatchGuard). The list entry is defined all the while for the x86 builds, but not even initialised.

Appended For Windows Vista

ULONGLONG volatile CycleTime;

ULONGLONG CycleTime;

Inserted For Windows 8

ULONGLONG ContextSwitches;

KSCHEDULING_GROUP *SchedulingGroup;

ULONG FreezeCount;

Appended For Windows 7

Version 6.1 did not so much append to the structure as move some old, even ancient, members to the end.

ULONG KernelTime;

ULONG UserTime;

ULONG ReadyTime;

PVOID VdmTrapcHandler;

ULONG ProcessTimerDelay;

Appended for 64-Bit Windows 7

The only truly new members that Windows 7 added are for 64-bit Windows only. Even these relatively few additions are not pretty, since shifts in preceding members allowed version 6.2 to get tighter packing just from rearranging what version 6.1 added.

PVOID InstrumentationCallback;

KDGENTRY64 LdtSystemDescriptor;

PVOID LdtBaseAddress;

KGUARDED_MUTEX LdtProcessLock;

USHORT LdtFreeSelectorHint;

USHORT LdtTableLength;

KGDTENTRY64 LdtSystemDescriptor;

PVOID LdtBaseAddress;

FAST_MUTEX LdtProcessLock;

ULONGLONG UserDirectoryTableBase;

UCHAR AddressPolicy;

UCHAR Spare2 [0x50];

UCHAR Spare2 [0x47];

PVOID InstrumentationCallback;

ULONGLONG SecurePid;

union {
    ULONGLONG SecureHandle;
    struct {
        ULONGLONG SecureProcess : 1;
        ULONGLONG Unused : 1;
    } Flags;
} SecureState;

Appended for Windows 10 Version 2004

ULONGLONG KernelWaitTime;

ULONGLONG UserWaitTime;

ULONG_PTR EndPadding [8];