EPROCESS

The EPROCESS structure (formally _EPROCESS) is the kernel’s representation of a process object. For instance, if the ObReferenceObjectByHandle function successfully resolves a handle though directed to do so only if the object type is PsProcessType, then what the function produces as its pointer to the object is a pointer to an EPROCESS.

Many functions that are exported from the kernel, e.g., for use by drivers, provide for referring to a process object through a pointer to an EPROCESS. The structure itself, however, is meant to be opaque outside the kernel, if not to Microsoft-supplied modules such as WIN32K.SYS, then at least to device drivers.

Documentation Status

The EPROCESS is not formally documented, but headers that Microsoft publishes for device driver programming have always declared the EPROCESS as an opaque type. For instance, NTDDK.H from as far back as the Device Driver Kit (DDK) for Windows NT 3.1 has

typedef struct _EPROCESS *PEPROCESS;

a few lines after a comment “Define types that are not exported”. Documentation for later versions makes increasingly clear what this pointer type points to. For instance, the DDK for Windows NT 3.51 has that IoGetCurrentProcess “returns a pointer to the current process” and the Windows Driver Kit (WDK) for Windows Vista has that the input to PsGetProcessId is “a process object structure”. The WDK for Windows Vista is anyway the first to document that PsProcessType directs ObReferenceObjectByHandle to produce a pointer to an EPROCESS, and it warns very clearly that the structure is “opaque, and drivers cannot access the structure members.”

Access

The EPROCESS exists only in kernel-mode memory. User-mode software has only indirect access through handles.

Variability

Since the EPROCESS structure is internal to the kernel, it should not surprise that the layout changes greatly between Windows versions and even between builds. In the following table of sizes, different builds of the same version are distinguished as early and late because they are known to vary the structure even if they don’t change the size. These descriptions, as early and late, are then used throughout the article as a shorthand.

Layout

These sizes, and the offsets, types and names in the tables that follow, are from Microsoft’s symbol files for the kernel starting with Windows 2000 SP3.

Since symbol files for earlier versions do not contain type information for the EPROCESS, what’s known for these versions is instead inferred from what use the kernel is seen to make of the EPROCESS. Sizes are straightforward, even without symbol files, since ObCreateObject and PsProcessType are exported (and so code that creates an EPROCESS, and thus knows the size, is easily found). Microsoft’s names and types are something of a guess, even with symbol files for later versions. 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.

That said, for some members in some early versions, offsets and names (but not types) are known with more or less confidence from the output of debugger extensions: the !processfields command of the KDEXTX86 debugger extension in version 3.51; and, both more comprehensively and plausibly more definitively, the !dso commands of the USEREXTS and USERKDX extensions for versions 4.0 and 5.0, and the !strct command of the KDEX2X86 extension again for versions 4.0 and 5.0.

KPROCESS Pcb;

KEVENT LockEvent;

NTSTATUS ExitStatus;

KEVENT LockEvent;

ULONG LockCount;

EX_PUSH_LOCK ProcessLock;

LARGE_INTEGER CreateTime;

LARGE_INTEGER ExitTime;

KTHREAD *LockOwner;

EX_RUNDOWN_REF RundownProtect;

PVOID VdmObjects;

PVOID UniqueProcessId;

LIST_ENTRY ActiveProcessLinks;

EX_RUNDOWN_REF RundownProtect;

PVOID VdmObjects;

Two sets of bit fields, in union with Flags and Flags2, that Windows XP and Windows Vista introduced towards what was then the end of the structure were moved near to the front for Windows 8. Perhaps not coincidentally, Windows 8 is the version that brings all 64 bits into use. More flags were added soon, as Flags3, but again near the end of the structure.

union {
    ULONG Flags2;
    struct {
        /*  bit fields, follow link  */
    };
};

union {
    ULONG Flags;
    struct {
        /*  bit fields, follow link  */
    };
};

LARGE_INTEGER CreateTime;

There now comes a set of members that track the process’s use of memory from the pools and the paging file. These resources are subject to quotas, but the limits apply to all processes that share a quota block. An EPROCESS_QUOTA_BLOCK has the limits and tracks the use, both current and peak, by all the applicable processes. The corresponding members here in the EPROCESS track the current and peak use by just the one process. For no reason yet known, the process’s pointer to its quota block, i.e., the QuotaBlock member, is in almost all versions placed further into the structure.

Each quota block has a spin lock, named QuotaLock, that guards both the quota block’s members and these members here in the EPROCESS. All versions except 3.10 have a default quota block in the kernel’s data. Its spin lock also guards the process’s QuotaBlock pointer. Version 3.10 instead provides its own spin lock in the EPROCESS. Microsoft’s name for it is not known, but the sharing of names such as QuotaPoolUsage between the EPROCESS and the EPROCESS_QUOTA_BLOCK speaks strongly for QuotaLock.

KSPIN_LOCK QuotaLock;

ULONG QuotaPeakPoolUsage [2];

ULONG QuotaPoolUsage [2];

ULONG_PTR QuotaUsage [3];

ULONG_PTR ProcessQuotaUsage [2];

ULONG_PTR QuotaPeak [3];

ULONG_PTR ProcessQuotaPeak [2];

ULONG PagefileUsage;

ULONG_PTR CommitCharge;

ULONG_PTR volatile CommitCharge;

ULONG PeakPagefileUsage;

EPROCESS_QUOTA_BLOCK *QuotaBlock;

PS_CPU_QUOTA_BLOCK *CpuQuotaBlock;

The PagefileUsage, CommitCharge and PeakPagefileUsage members count pages. The others count bytes.

The precise arrangement of the various members for current and peak use of the non-paged and pages pools and of the pagefile has varied with the EPROCESS_QUOTA_BLOCK implementation. Version 5.1 brought the pools and pagefile together into a PS_QUOTA_TYPE enumeration that indexes the QuotaUsage and QuotaPeak arrays, which thus absorb what had been PagefileUsage and PeakPagefileUsage.

All the statistical members in the preceding set are retrievable through either or both of two native API functions in all versions: as members of VM_COUNTERS, as filled by the ProcessVmCounters (0x03) case of the NtQueryInformationProcess function; and as members of SYSTEM_PROCESS_INFORMATION, as filled by the SystemProcessInformation (0x05) case of the NtQuerySystemInformation function. For the latter, what is here called the CommitCharge is there called the PrivatePageCount—and in the VM_COUNTERS_EX, which is supported in version 5.1 and higher, it is named PrivateUsage.

This area of statistical members also has the original counters of I/O operations and the bytes that these transferred. Presumably, this is because they were also retrievable in the SYSTEM_PROCESS_INFORMATION.

LARGE_INTEGER ReadTransferCount;

LARGE_INTEGER WriteTransferCount;

LARGE_INTEGER OtherTransferCount;

ULONG ReadOperationCount;

ULONG WriteOperationCount;

ULONG OtherOperationCount;

The original implementation’s allowance of only 32 bits for counting the operations soon became problematic. Indeed, these counters disappear from the EPROCESS until version 5.0 brings them back, all 64 bits wide, but near to what was then the end of the structure.

In version 3.10, these I/O counters are retrievable through either or both of two native API functions: as members of IO_COUNTERS, as filled by the ProcessIoCounters (0x02) case of the NtQueryInformationProcess function; and as members of SYSTEM_PROCESS_INFORMATION. They are in version 5.0 and higher, too. In the intervening versions, the corresponding members of the SYSTEM_PROCESS_INFORMATION are unused or repurposed, and the ProcessIoCounters case is failed immediately as being not implemented. The NTDDK.H from the DDK for both Windows NT 3.51 and 4.0 presents a C-language definition of the original IO_COUNTERS structure, with 32-bit operation counts, as output from ProcessIoCounters, though trying to get that output can only have been a waste of time.

ULONG_PTR PeakVirtualSize;

ULONG_PTR VirtualSize;

The PeakVirtualSize and VirtualSize count pages. In all versions, conversions to bytes are retrievable as identically named members of the VM_COUNTERS structure that is filled by the ProcessVmCounters (0x03) case of the NtQueryInformationProcess function.

All versions 3.10 to 5.0 have four bytes of unused alignment space before the next member (which has 8-byte alignment before version 6.0).

MMSUPPORT Vm;

PVOID LastProtoPteFault;

LIST_ENTRY SessionProcessLinks;

PVOID DebugPort;

PVOID ExceptionPort;

union {
    PVOID ExceptionPortData;
    ULONG_PTR ExceptionPortValue;
    ULONG_PTR ExceptionPortState : 3;
};

HANDLE_TABLE *ObjectTable;

PVOID Token;

EX_FAST_REF Token;

KMUTANT WorkingSetLock;

FAST_MUTEX WorkingSetLock;

ULONG_PTR WorkingSetPage;

ULONG MmReserved;

BOOLEAN ProcessOutswapEnabled;

BOOLEAN ProcessOutswapped;

BOOLEAN AddressSpaceInitialized;

BOOLEAN AddressSpaceDeleted;

KEVENT AddressCreationLock;

FAST_MUTEX AddressCreationLock;

KGUARDED_MUTEX AddressCreationLock;

EX_PUSH_LOCK AddressCreationLock;

KSPIN_LOCK HyperSpaceLock;

HyperSpace is a per-process region of kernel-mode address space. In these versions that have a HyperSpaceLock, the x86, PAE and x64 builds have hyperspace at the pre-set addresses 0xC0400000, 0xC0800000 and 0xFFFFF700`00000000, respectively. The HyperSpaceLock is for a particular use of a relatively small part of hyperspace that provides temporary linear addresses for the kernel’s own preparation of physical memory that is otherwise not (yet) accessible. Speed is of the essence. Version 3.10 simply rotates through a pool of 0x80 pages of linear address space and risks that threads in the process don’t map into hyperspace in such a rush that one gets an address that another is still using. Version 3.50 continues the rotating allocation but protects with a spin lock: only one thread can have a hyperspace mapping at any one time; releasing the lock releases the mapping. Though this surely meant that one page of linear address space could serve all threads, version 3.51 increases the pool to 0x0100 pages. For the PAE builds, starting in version 5.0, the pool is 0x7F pages. Version 6.0 speeds the mapping into hyperspace by mapping to a per-processor region instead. Since threads on different processors map from different regions, the only “lock” that is now needed for mapping to “hyperspace” is to raise the IRQL: the HyperSpaceLock is needed no more.

EX_PUSH_LOCK PageTableCommitmentLock;

ETHREAD *RotateInProgress;

ETHREAD *ForkInProgress;

ULONG VmOperation;

USHORT VmOperation;

BOOLEAN ForkWasSuccessful;

UCHAR MmAgressiveWsTrimMask;

KEVENT *VmOperationEvent;

HARDWARE_PTE PageDirectoryPte;

PVOID PaeTop;

ULONG LastFaultCount;

ULONG ModifiedPageCount;

That the LastFaultCount has earlier history than is known from type information in symbol files for version 5.0 is confirmed by debugger extensions. It is here assumed to have been defined all along, but beware that no use is yet known in any of these early versions.

ULONG_PTR HardwareTrigger;

PVOID VadRoot;

PVOID VadHint;

MM_AVL_TABLE *PhysicalVadRoot;

EJOB *CommitChargeJob;

PVOID CloneRoot;

RTL_AVL_TREE CloneRoot;

ULONG_PTR NumberOfPrivatePages;

ULONG_PTR volatile NumberOfPrivatePages;

ULONG_PTR NumberOfLockedPages;

ULONG_PTR volatile NumberOfLockedPages;

BOOLEAN ForkWasSuccessful;

UCHAR NextPageColor;

USHORT NextPageColor;

BOOLEAN ExitProcessCalled;

BOOLEAN CreateProcessReported;

PVOID Win32Process;

EJOB *Job;

HANDLE SectionHandle;

PVOID SectionObject;

PEB *Peb;

PVOID SectionBaseAddress;

EPROCESS_QUOTA_BLOCK *QuotaBlock;

ULONG Cookie;

ULONG Spare8;

ULONG UmsScheduledThreads;

PVOID VdmObjects;

LONG LastThreadExitStatus;

PAGEFAULT_HISTORY *WorkingSetWatch;

PVOID LpcPort;

PVOID Win32WindowStation;

The Win32WindowStation is an example of an EPROCESS member that is known outside the kernel, specifically to WIN32K.SYS in versions 4.0 and 5.0. Indeed, the kernel itself is not known to use this member until version 5.1 introduces the exported functions PsGetProcessWin32WindowStation. and PsSetProcessWindowStation. The KDEXTX86 debugger extension for version 3.51 reports the corresponding offset as holding the LpcPort. Continuity is here assumed from the beginning, but no use is yet known in any version before 4.0.

PVOID InheritedFromUniqueProcessId;

ACCESS_MASK GrantedAccess;

ULONG DefaultHardErrorProcessing;

PVOID LdtInformation;

PVOID Spare0;

PVOID VadFreeHint;

PVOID Spare;

PVOID VdmObjects;

PVOID Spare;

KMUTANT ProcessMutant;

ULONG_PTR ConsoleHostProcess;

union {
    EPROCESS *CreatorProcess;
    ULONG_PTR ConsoleHostProcess;
};

ULONG_PTR volatile OwnerProcessId;

PEB *Peb;

PVOID Session;

PVOID AweInfo;

PVOID Spare1;

EPROCESS_QUOTA_BLOCK *QuotaBlock;

HANDLE_TABLE *ObjectTable;

PVOID DebugPort;

PVOID PaeTop;

PVOID Wow64Process;

EWOW64PROCESS *Wow64Process;

PVOID DeviceMap;

ULONG SessionId;

LIST_ENTRY PhysicalVadList;

PVOID Spare0 [3];

PVOID EtwDataSource;

PVOID FreeTebHint;

PVOID FreeUmsTebHint;

The EtwDataSource, when it is not NULL, is historically the address of an ETW_DATA_SOURCE structure which supports inter-process communication by Event Tracing for Windows (ETW). Starting with version 6.3, it is different things at different times. A process that intends to receive notifications but has not yet sent any can supply an event that the kernel is to signal whenever notifications are ready for receipt. The EtwDataSource then holds the address of the event object but with the low bit set. If the process then sends any notifications, the EtwDataSource is changed to be the address of the supporting structure, and the event object’s address is transferred to this structure.

union {
    HARDWARE_PTE PageDirectoryPte;
    ULONGLONG Filler;
};

ULONGLONG PageDirectoryPte;

ULONG PaePageDirectoryPage;

Versions 5.0 to 6.1 of the 32-bit kernel exist in two forms. One has the processor translate 32-bit linear addresses to 32-bit physical addresses. The other uses Physical Address Extension (PAE) to support a larger physical address space. For the former, each Page Table Entry (PTE) is four bytes. With PAE, each PTE is eight bytes. Not shown above is that Microsoft at first separated the original HARDWARE_PTE into separately named structures, HARDWARE_PTE_X86 and HARDWARE_PTE_X86PAE. The version 5.1 from Windows XP SP1 returned to the simplicity of having the one HARDWARE_PTE, now defined differently according to whether the kernel does or does not use PAE (or is for 64-bit Windows). Version 6.2 discontinued the 32-bit kernel that does not use PAE, and so the Filler lost its reason for existence.

PVOID Session;

FILE_OBJECT *ImageFilePointer;

UCHAR ImageFileName [0x20];

UCHAR ImageFileName [0x10];

UCHAR ImageFileName [0x0F];

UCHAR PriorityClass;

There is a plan to write something here.

ULONG VmTrimFaultValue;

BOOLEAN SetTimerResolution;

UCHAR PriorityClass;

union {
    struct {
        UCHAR SubSystemMinorVersion;
        UCHAR SubSystemMajorVersion;
    };
    USHORT SubSystemVersion;
};

PVOID Win32Process;

There is a plan to write something here.

PVOID SecurityPort;

SE_AUDIT_PROCESS_CREATION_INFO SeAuditProcessCreationInfo;

EJOB *Job;

ULONG JobStatus;

LIST_ENTRY JobLinks;

PVOID LockedPagesList;

PVOID HighestUserAddress;

LIST_ENTRY ThreadListHead;

There is a plan to write something here.

PVOID SecurityPort;

WOW64_PROCESS *Wow64Process;

PVOID Wow64Process;

There is a plan to write something here.

PVOID PaeTop;

ULONG ActiveThreads;

ULONG volatile ActiveThreads;

ULONG ImagePathHash;

ACCESS_MASK GrantedAccess;

ULONG DefaultHardErrorProcessing;

LONG LastThreadExitStatus;

PEB *Peb;

EX_FAST_REF PrefetchTrace;

MM_AVL_TABLE *LockedPagesList;

PVOID LockedPagesList;

There is a plan to write something here.

LARGE_INTEGER ReadOperationCount;

LARGE_INTEGER WriteOperationCount;

LARGE_INTEGER OtherOperationCount;

LARGE_INTEGER ReadTransferCount;

LARGE_INTEGER WriteTransferCount;

LARGE_INTEGER OtherTransferCount;

ULONG_PTR CommitChargeLimit;

ULONG_PTR volatile CommitCharge;

ULONG_PTR CommitChargePeak;

ULONG_PTR volatile CommitChargePeak;

There is a plan to write something here.

LIST_ENTRY ThreadListHead;

RTL_BITMAP *VadPhysicalPagesBitMap;

ULONG VadPhysicalPages;

KSPIN_LOCK AweLock;

UNICODE_STRING *pImageFileName;

The pImageFileName is known from the public symbol files, but only starting with Windows 2000 SP3. Use certainly is made of it in this service pack but the corresponding code in the original Windows 2000 does not retain this pointer in the EPROCESS. It is not known to the !dso or !strct commands. Since these are correct for the structure’s size, relative to the kernel’s use, it is here thought that pImageFileName was at first just unused space left by the structure’s 8-byte alignment, and then was added for a service pack.

Appended for Windows XP and Windows Server 2003

PVOID AweInfo;

SE_AUDIT_PROCESS_CREATION_INFO SeAuditProcessCreationInfo;

MMSUPPORT Vm;

MMSUPPORT_FULL Vm;

LIST_ENTRY MmProcessLinks;

ULONG Spares [2];

PVOID HighestUserAddress;

ULONG LastFaultCount;

ULONG ModifiedPageCount;

ULONG NumberOfVads;

ULONG JobStatus;

union {
    ULONG Flags2;
    struct {
        /*  bit fields, follow link  */
    };
};

union {
    ULONG Flags;
    struct {
        /*  bit fields, follow link  */
    };
};

NTSTATUS ExitStatus;

USHORT NextPageColor;

USHORT Spare7;

union {
    struct {
        UCHAR SubSystemMinorVersion;
        UCHAR SubSystemMajorVersion;
    };
    USHORT SubSystemVersion;
};

UCHAR PriorityClass;

BOOLEAN WorkingSetAcquiredUnsafe;

MM_AVL_TABLE VadRoot;

RTL_AVL_TREE VadRoot;

PVOID VadHint;

ULONG_PTR VadCount;

ULONG_PTR volatile VadPhysicalPages;

ULONG_PTR VadPhysicalPagesLimit;

ULONG Cookie;

ULONG Cookie;

Appended for Windows Vista

ALPC_PROCESS_CONTEXT AlpcContext;

Appended for Windows 7

LIST_ENTRY TimerResolutionLink;

ULONG RequestedTimerResolution;

ULONG ActiveThreadsHighWatermark;

ULONG SmallestTimerResolution;

PO_DIAG_STACK_RECORD *TimerResolutionStackRecord;

Appended for Windows 8

ULONG RequestedTimerResolution;

ULONG SmallestTimerResolution;

LARGE_INTEGER ExitTime;

INVERTED_FUNCTION_TABLE *InvertedFunctionTable;

EX_PUSH_LOCK InvertedFunctionTableLock;

ULONG ActiveThreadsHighWatermark;

ULONG LargePrivateVadCount;

EX_PUSH_LOCK ThreadListLock;

PVOID WnfContext;

ULONG_PTR SectionMappingSize;

ULONG_PTR Spare0;

EJOB *ServerSilo;

UCHAR SignatureLevel;

UCHAR SectionSignatureLevel;

PS_PROTECTION Protection;

UCHAR HangCount;

UCHAR HangCount : 4;
UCHAR GhostCount : 4;

UCHAR HangCount : 3;
UCHAR GhostCount : 3;
UCHAR PrefilterException : 1;

UCHAR SpareByte20 [2];

UCHAR SpareByte20 [1];

union {
    ULONG Flags3;
    struct {
        /*  bit fields, follow link  */
    };
};

LONG DeviceAsid;

LONG SvmReserved;

PVOID SvmReserved1;

PVOID SvmData;

ULONG_PTR SvmReserved2;

EX_PUSH_LOCK SvmProcessLock;

ULONG_PTR SvmLock;

LIST_ENTRY SvmProcessDeviceListHead;

ULONG KeepAliveCounter;

PROCESS_DISK_COUNTERS *DiskCounters;

ULONGLONG LastFreezeInterruptTime;

Appended for Windows 8.1

PROCESS_DISK_COUNTERS *DiskCounters;

PVOID PicoContext;

ULONGLONG TrustletIdentity;

PVOID EnclaveTable;

ULONGLONG EnclaveNumber;

EX_PUSH_LOCK EnclaveLock;

ULONG KeepAliveCounter;

ULONG NoWakeKeepAliveCounter;

Appended for Windows 10

ULONG HighPriorityFaultsAllowed;

PVOID InstrumentationCallback;

PROCESS_ENERGY_VALUES *EnergyValues;

PO_PROCESS_ENERGY_CONTEXT *EnergyContext;

PVOID VmContext;

ESILO *Silo;

LIST_ENTRY SiloEntry;

ULONGLONG SequenceNumber;

ULONGLONG CreateInterruptTime;

ULONGLONG CreateUnbiasedInterruptTime;

ULONGLONG TotalUnbiasedFrozenTime;

ULONGLONG LastAppStateUpdateTime;

ULONGLONG LastAppStateUptime : 61;
ULONGLONG LastAppState : 3;

ULONG_PTR volatile SharedCommitCharge;

EX_PUSH_LOCK SharedCommitLock;

LIST_ENTRY SharedCommitLinks;

union {
    struct {
        ULONG_PTR AllowedCpuSets;
        ULONG_PTR DefaultCpuSets;
    };
    struct {
        ULONG_PTR *AllowedCpuSetsIndirect;
        ULONG_PTR *DefaultCpuSetsIndirect;
    };
};

PVOID DiskIoAttribution;

ULONG ReadyTime;

PVOID DxgProcess;

ULONG Win32KFilterSet;

PS_INTERLOCKED_TIMER_DELAY_VALUES volatile ProcessTimerDelay;

ULONG volatile KTimerSets;

ULONG volatile KTimer2Sets;

ULONG volatile ThreadTimerSets;

ULONG_PTR VirtualTimerListLock;

LIST_ENTRY VirtualTimerListHead;

union {
    WNF_STATE_NAME WakeChannel;
    PS_PROCESS_WAKE_INFORMATION WakeInfo;
};

union {
    ULONG Flags4;
    struct {
        ULONG PicoCreated : 1;
        ULONG RestrictSetThreadContext : 1;
    };
};

union {
    ULONG MitigationFlags;
    struct {
        /*  bit fields, follow link  */
    } MitigationFlagsValues;
};

union {
    ULONG MitigationFlags2;
    struct {
        /*  bit flags, follow link  */
    } MitigationFlags2Values;
};

PVOID PartitionObject;

ULONGLONG SecurityDomain;

ULONGLONG ParentSecurityDomain;

PVOID CoverageSamplerContext;

PVOID MmHotPatchContext;

RTL_AVL_TREE DynamicEHContinuationTargetsTree;

EX_PUSH_LOCK DynamicEHContinuationTargetsLock;

The EPROCESS has 0x40-byte alignment in 1903 and higher. This is here thought to be incidental, being picked up from cache-alignment of the MMSUPPORT_SHARED that is inside the Vm member. A side-effect is that the structure ends with 8 bytes of unused alignment space in the x86 build for 1903 and 0x30 bytes of it in the x64 build for 2004.