KPCR (amd64)

The name KPCR stands for (Kernel) Processor Control Region. The kernel keeps a KPCR (formally a _KPCR) for each logical processor. The KPCR is highly specific to the processor architecture. This page concerns itself only with the KPCR in 64-bit Windows for the processor architecture that’s variously named amd64 or x64. The x86 KPCR is presented separately.

Access

Kernel-mode code can easily find the KPCR for whichever processor it’s executing on, because when the processor last entered ring 0, however it got there, the kernel will have loaded the gs register to address that processor’s KPCR. This is done by the swapgs instruction. It loads the base address for gs from the processor’s Model Specific Register (MSR) 0xC0000102, which the kernel initialises with the address of the processor’s KPCR. Intel’s label for this MSR is IA32_KERNEL_GS_BASE. Microsoft’s assembly-language name, defined in KSAMD64.INC, is MSR_GS_SWAP.

The KPCR conveniently holds its own address in the Self member so that reading just this one member using a segment register override makes the whole KPCR accessible without overrides. This is so fundamental that all versions of the 64-bit Windows kernel have it as an internal routine, typically inlined, which is coded very much like:

FORCEINLINE
KPCR *KeGetPcr (VOID)
{
    return (KPCR *) __readgsqword (FIELD_OFFSET (KPCR, Self));
}

Beware, though, that this is the address of the KPCR for the processor that the thread was running on at the time. It remains the address of the current KPCR only while the thread can ensure it is not switched to another processor. I suspect that more than a few things go very slightly wrong in kernel-mode Windows because this point is insufficiently respected.

Documentation Status

Not even the role of the segment registers in accessing the KPCR is formally documented, but the KPCR is made at least semi-official by C-language definitions that Microsoft has published in every applicable Device Driver Kit (DDK) or Windows Driver Kit (WDK).

That said, it must be pointed out that the best-known of such C-language definitions, in NTDDK.H, is incomplete.

Variability

Whatever was or is the intention, e.g., that the KPCR before the KPRCB is per-processor information that the kernel shares but the KPRCB itself is (more) private to the kernel, one practical consequence is that the start of the KPCR is highly stable across Windows versions while the KPRCB is highly changeable.

Indeed, except for changes within the embedded KPRCB, the x64 KPCR is so stable that although the structure provides for MajorVersion and MinorVersion numbers, they have never changed—they are both 1 in all versions—and arguably have never needed changing. Except for the early reuse of one member of the unnamed structure that overlays the NT_TIB at the beginning, the x64 KPCR is completely stable. The changing size of the whole KPCR structure, as shown in the table below, is due entirely to the changing size of the KPRCB at the structure’s end. All versions have this embedded KPCR at offset 0x0180. It can be convenient, if not formally correct, to think of the KPCR as just these first 0x0180 bytes.

Layout

In the tables that follow, C-language definitions are reconstructed from type information in symbol files that Microsoft publishes for the kernel and from definitions in the NTDDK.H files from development kits for driver programming.

union {
    NT_TIB NtTib;
    struct {
        /*  slightly changing members, see below  */
    };
};

KIDTENTRY64 *IdtBase;

ULONG64 Unused [2];

KIRQL Irql;

UCHAR SecondLevelCacheAssociativity;

UCHAR ObsoleteNumber;

UCHAR Fill0;

ULONG Unused0 [3];

USHORT MajorVersion;

USHORT MinorVersion;

ULONG StallScaleFactor;

PVOID Unused1 [3];

ULONG KernelReserved [0x0F];

ULONG SecondLevelCacheSize;

ULONG HalReserved [0x10];

ULONG Unused2;

PVOID KdVersionBlock;

PVOID Unused3;

ULONG PcrAlign1 [0x18];

KPRCB Prcb;

It seems at least plausible that the unused space ahead of KernelReserved exists to place the latter and thus also HalReserved at 64-byte cache-line boundaries. The different sizing of KernelReserved and HalReserved seems to have been inherited from the 32-bit implementation’s creation of SecondLevelCacheSize at the end of a previously larger KernelReserved.

Curiously, PcrAlign1 does not extend exactly to the Prcb that follows. That Prcb is meant to be cache-aligned is certain. Cache alignment is plainly a recurring concern within the KPRCB and is obviously simpler to arrange if the KPRCB is itself cache aligned. That it isn’t for 32-bit Windows is a recurring trap for Microsoft’s programmers. That it is aligned for 64-bit Windows is evidently nothing to do with PcrAlign1.

NT_TIB Overlay

The NT_TIB at the beginning of the KPCR is given in union with an unnamed structure whose members change a little between versions:

KGDTENTRY64 *GdtBase;

KTSS64 *TssBase;

PVOID PerfGlobalGroupMask;

ULONG64 UserRsp;

KPCR *Self;

KPRCB *CurrentPrcb;

KSPIN_LOCK_QUEUE *LockArray;

PVOID Used_Self;

This unnamed structure of course models the actual use. In effect, the KPCR begins with a kernel-mode NT_TIB that is nothing like the user-mode NT_TIB that is defined in NTDDK.H and WINNT.H. Both have the same size, both end with something that’s presented as some sort of pointer to itself, and there the similarities end.

In version 5.2, what would be the StackLimit in a user-mode NT_TIB instead holds the address of a PERFINFO_GROUPMASK. This is an array of bits for what types of event are enabled in NT Kernel Logger sessions. The intention was presumably to allow the tracing of different selections of events on different processors. Whatever the plan, it didn’t survive even to version 6.0.

In a user-mode NT_TIB, the last member is named Self, is formally a pointer to an NT_TIB, and does indeed point to the start of the NT_TIB. In a kernel-mode NT_TIB, it is named Used_Self and is formally a pointer to void. If it points to anything, it is to an NT_TIB but to a different NT_TIB—not the one at the start of the KPCR but to the user-mode NT_TIB at the start of the TEB for whichever thread is currently running on the processor.