KPRCB (amd64)

The name KPRCB stands for (Kernel) Processor Control Block. The kernel keeps one KPRCB (formally a _KPRCB) for each logical processor as the Prcb member of the same processor’s KPCR. The KPRCB holds most of what the kernel needs ready access to while managing a processor and while managing resources that are themselves managed more simply (and quickly) per processor. Neither of these structures is formally documented. Both are highly specific to the processor architecture. This page concerns itself only with the KPRCB in 64-bit Windows for the processor architecture that’s variously named amd64 or x64. The x86 KPRCB is presented separately.

Access

Kernel-mode code can easily find the KPRCB for whichever processor it’s executing on, by finding the current KPCR first. The latter is well-known to be accessible through the gs register. Its CurrentPrcb member points to the KPRCB without depending on it to be embedded in the KPCR. Given a C-language definition of the KPCR, getting the current processor’s KPRCB can be conveniently wrapped into one inline function:

FORCEINLINE
KPRCB *KeGetCurrentPrcb (VOID)
{
    return (KPRCB *) __readgsqword (FIELD_OFFSET (KPCR, CurrentPrcb));
}

which, less some dressing, is mostly how Microsoft’s own programmers have been doing it, apparently all along, as confirmed by the NTOSP.H that Microsoft published (possibly by oversight) in early editions of the Windows Driver Kit (WDK) for Windows 10.

The part of the KPCR that’s ahead of the embedded KPRCB is highly stable. Of particular importance is that the offset of the CurrentPrcb member is reliable over all Windows versions. The KPRCB that it points to is the Prcb member, and its offset too is stable over all versions. Members of the KPRCB are sometimes accessed through offsets from the KPCR. For some members, this is even the most usual access. Notably, the KeGetCurrentThread function is implemented very like

KTHREAD *KeGetCurrentThread (VOID)
{
    return (KTHREAD *) __readgsqword (FIELD_OFFSET (KPCR, Prcb.CurrentThread));
}

both as exported and when inlined throughout the kernel. Of course, the computation shown here would require definition of the whole KPCR and at least some of KPRCB. As explained later, Microsoft has so far avoided both. Microsoft’s definition of KeGetCurrentThread in WDM.H doesn’t compute the offset symbolically, as above, but hard-codes it (to 0x0188). For all practical effect, this means that this offset with the KPRCB and the offset of the KPRCB within the KPCR are fixed in stone, if not forever, then for as long as old code that may have used the WDM.H definition is to run on new Windows versions. For other KPRCB members, offsets may be less stable, but accessing them relative to the containing KPCR is formalised in Microsoft’s assembly-language header KSAMD64.INC through such definitions as PcCurrentThread for this same offset that’s computed above.

Processor Switching

In many cases, including KeGetCurrentThread, kernel-mode code that must access a KPRCB member does better to use the gs register and an offset from the KPCR. This is because the address that some such routine as KeGetCurrentPrcb obtains is merely the address of the KPRCB for the processor that the current thread was being run on at the time. It remains the address of the current KPRCB only while the thread can ensure it is not switched to another processor. Often the circumstances are such that it can’t be switched. But often is not always, even for the kernel’s own use. How much trouble has been caused by unsynchronised access to a KPRCB for some processor that the thread is no longer running on may be impossible to assess even roughly but I doubt it’s negligible.

Other Processors

Finding the KPRCB for an arbitrary processor is easy too in 64-bit Windows. Its kernel exports a function, named KeQueryPrcbAddress, that returns the address of the KPRCB for the processor that is represented by a given processor index.

Documentation Status

The KPRCB is not documented. Microsoft’s first known disclosure of a C-language definition of the KPRCB for the x64 is in the NTOSP.H from early editions of the WDK for Windows 10. Publication of this header was possibly an oversight—Microsoft did not repeat it for the 1607 edition—and, anyway, its definition is incomplete. Comments at the start and end explain that what’s defined is just an “architecturally defined section” that “may be directly addressed by vendor/platform specific HAL code and will not change from version to version of NT.”

The practical equivalent of a C-language definition of the whole structure is available as type information in public symbol files for the kernel. Starting with Windows 8, these also tell that the type information came from compiling AMD64_X.H. Some symbol files, e.g., those for the HAL in Windows 7 and higher, have type information for only the architecturally defined section at the structure’s start. From these it is known that the incomplete definition is not only in NTOSP.H but also in NTHAL.H.

Layout

The KPRCB is highly variable. The layout changes not just from one version to another but even between builds. To save space and tedium, this article’s presentation of the variations refers to early and late builds of some versions, as defined in the following table of the structure’s varying size:

These sizes, and the names, types and offsets below, are mostly from Microsoft’s public symbols for the kernel. A few come instead from public symbols for other modules. These are needed for the incomplete definitions that some modules pick up from NTHAL.H or NTOSP.H. Before the 1709 release of Windows 10, these truly are just of the architecturally defined section. Later releases present two complications. First, although they have no members that reach beyond the architecturally defined section, they have unnamed alignment padding that does. Second, they do not have all the same members even within the architecturally defined section.

Please bear in mind that the KPRCB is among the largest of kernel-mode structures, not just in terms of size but of member count. There have been frequent rearrangements such that finding a good presentation can only ever be a work in progress.

Architecturally Defined Section

The very start of the 64-bit KPRCB is relatively stable. It has long been subject to compatibility constraints because offsets for members have been published in the NTDDK.H file. When the processor Number was widened in place for Windows Vista, the NestingLevel moved further on. When Number was widened even further for Windows 7, it too moved further on, and the space it occupied was renamed, presumably so that it is never reassigned.

ULONG MxCsr;

UCHAR Number;

USHORT Number;

UCHAR LegacyNumber;

UCHAR NestingLevel;

UCHAR ReservedMustBeZero;

BOOLEAN InterruptRequest;

BOOLEAN IdleHalt;

KTHREAD *CurrentThread;

KTHREAD *NextThread;

KTHREAD *IdleThread;

Shifting the processor Number from offset 0x04 to widen it to 32 bits had special implications for compatibility because of the vast amounts of kernel-mode code, written not only by Microsoft, that accesses the 8-bit Number through the inline function KeGetCurrentProcessorNumber as defined for seemingly general use in the NTDDK.H from driver kits for versions before Windows 7 (and still defined if targetting those versions). This routine gets Number via the gs register, relying not only on its offset within the KPRCB but the offset of the KPRCB within the KPCR, the sum (0x0184) being hard-coded in the definition. Its replacement, KeGetCurrentProcessorIndex, is similarly hard-coded but to access the 32-bit Number at its new location. The kernel must maintain the LegacyNumber for as long as the old routine remains in use by drivers that might ever get loaded.

The other inline function that is declared in NTDDK.H for general use and which has a hard-coded offset from gs to a KPRCB member is KeGetCurrentThread. It, of course, reads CurrentThread.

There the hard constraints on moving members seem to end. The very next member even got moved out of the KPRCB. Of the space that was left by moving the 8-byte UserRsp to the KPCR in Windows Vista, only two bytes were immediately reused. The rest was left as padding that got reassigned little by little. The byte at offset 0x21 even got reused, unused and re-reused. The last byte of padding went away in Windows 10.

ULONG64 UserRsp;

UCHAR NestingLevel;

UCHAR Group;

BOOLEAN ClockOwner;

UCHAR PendingTick;

union {
    UCHAR PendingTickFlags;
    struct {
        UCHAR PendingTick : 1;          // 0x01
        UCHAR PendingBackupTick : 1;    // 0x02
    };
};

UCHAR PrcbPad00 [6];

UCHAR PrcbPad00 [3];

UCHAR PrcbPad00 [1];

UCHAR IdleState;

ULONG Number;

Much of the rest of the architecturally defined section is very nearly stable until Version 1703 moves the ProcessorState to the end of the architecturally defined section. This relocation of course shifts all members that followed, but they would have shifted anyway because the KPROCESSOR_STATE grew in this version—not from any internal change but just from rounding its size up to the next whole multiple of 0x40, presumably for cache alignment.

ULONG64 RspBase;

KSPIN_LOCK PrcbLock;

KAFFINITY SetMember;

ULONG64 PrcbPad01;

CHAR *PriorityState;

KPROCESSOR_STATE ProcessorState;

CHAR CpuType;

CHAR CpuID;

USHORT CpuStep;

union {
    USHORT CpuStep;
    struct {
        UCHAR CpuStepping;
        UCHAR CpuModel;
    };
};

ULONG MHz;

ULONG64 HalReserved [8];

USHORT MinorVersion;

USHORT MajorVersion;

UCHAR BuildType;

UCHAR CpuVendor;

UCHAR InitialApicId;

UCHAR CoresPerPhysicalProcessor;

UCHAR LogicalProcessorsPerPhysicalProcessor;

UCHAR LogicalProcessorsPerCore;

The CpuType is what the processor manuals refer to as the family. In eax from cpuid leaf 1, bits 8 to 11 inclusive make a 4-bit family. If all four bits are set, then an 8-bit family is formed by adding the 4-bit family, i.e., 15, to the 8-bit extended family from bits 20 to 27. Though this complexity is defined by Intel, it is of course inherited from the early history of Windows on the x86 processor.

The CpuID is a boolean for whether the cpuid instruction is available. It is necessarily TRUE for x64 processors.

The CpuStepping and CpuModel are named straightforwardly from Intel’s manuals. The CpuStepping is bits 0 to 3 inclusive of eax from cpuid leaf 1. The CpuModel is bits 4 to 7 inclusive, except for two cases in which four high bits of the 8-bit CpuModel come from an extended model in bits 16 to 19. This use of the extended model is indicated if: the 4-bit family is 15; or it is 6 and the vendor is either GenuineIntel or, in version 6.2 and higher, CentaurHauls.

Vendor identification is from the vendor string that is produced by what the cpuid instruction’s leaf 0 returns in ebx, edx and ecx. This string is retained as the VendorString much further into the KPRCB. The CpuVendor is a convenient interpretation. It takes its values from the CPU_VENDORS enumeration.

Insertion of explicit padding (PrcbPad04, below) when Version 1703 moved the ProcessorState suggests that what had been the last 0x30 bytes of the architecturally defined section had been intended to be cache-aligned, for their own purpose, not just for positioning the LockQueue that starts the non-architectural section.

ULONG64 TscFrequency;

ULONG64 PrcbPad04 [6];

ULONG64 PrcbPad04 [5];

Until moving the ProcessorState required the architecturally defined section to grow, some trouble seems to have been taken to keep the remainder to 0x30 bytes even when reworking it heavily for Windows 8.1. An initially 8-bit CFlushSize was followed by padding (PrcbPad0x) that accounts explicitly for the next member’s alignment. This padding went away when CFlushSize was widened in-place. An initial 32 bytes of padding (as PrcbPad00) completed the architecturally defined section in a way that satisfies the peculiar cache-alignment requirement of the LockQueue. As some of this padding was brought into use, it shifted and shrank (as PrcbPad01), until by version 6.1 it was no longer needed—given 8-byte alignment of whatever follows. Therein lay a problem. Placement of the small Group and GroupIndex on 8-byte boundaries left 13 bytes of unused alignment space. This had to be reorganised for Windows 8.1 to squeeze in ParentNode from (much) further into the structure. Bringing in ScbOffset from further into the structure for Windows 10 then seems to have prompted a reordering of ApicMask, CFlushSize, AcpiReserved and InitialApicId. The four bytes of alignment space that this left unused was labelled explicitly as padding (PrcbPad10) until Version 1709 found a use for it.

KNODE *ParentNode;

KAFFINITY GroupSetMember;

UCHAR Group;

UCHAR GroupIndex;

UCHAR PrcbPad05 [2];

ULONG InitialApicId;

ULONG ScbOffset;

ULONG ApicMask;

UCHAR CFlushSize;

ULONG CFlushSize;

UCHAR PrcbPad0x [3];

PVOID AcpiReserved;

ULONG InitialApicId;

ULONG Stride;

ULONG64 PrcbPad00 [4];

ULONG64 PrcbPad01 [3];

USHORT Group;

KAFFINITY GroupSetMember;

UCHAR GroupIndex;

ULONG CFlushSize;

ULONG PrcbPad10;

union {
    LONG volatile BamFlags;
    struct {
        ULONG BamQosLevel : 2;          // 0x00000003
        ULONG PendingQosUpdate : 2;     // 0x0000000C
        ULONG BamFlagsReserved : 28;
    };
};

KPRCBFLAG PrcbFlags;

The reordering for Windows 10 seems to have troubled someone at Microsoft. The mostly unpublished NTOSP.H has a C_ASSERT to enforce at compile-time that AcpiReserved is at offset 0x0660, specifically, and then the comment “Do not move field”. That’s for Windows 10. Was the offset changed for Windows 8.1 despite some earlier comment (for the old offset) or was the comment added after? Now that the offset has changed yet again, have the assertion and comment changed too?

The BamFlags in the last four bytes only appear to be short-lived. They survive in the PrcbFlags. The Background Activity Moderator (BAM) is new to both 32-bit and 64-bit Windows in the 1709 release, but only the 64-bit implementation has these flags at first. Formalising the bit fields into their own type also moved their definition in a separate header (ntosdef.h) that is independent of the processor architecture, but there may be more to this than mere tidiness. Notably, the new PrcbFlags are excluded from the NTHAL.H and NTOSP.H definitions. In these, the PrcbFlags are just unnamed alignment space.

Moving the ProcessorState for explicit cache-line alignment in Version 1703 created another 0x10 bytes of alignment space immediately before the new position. This is defined explicitly as PrcbPad11, below, even after Version 1803 starts using it. The reduced KPRCB definition in NTHAL.H and NTOSP.H sees nothing of this new use, just the padding.

ULONG64 PrcbPad11 [2];

union {
    struct {
        /*  changing members, follow link  */
    };
    ULONG64 PrcbPad11 [2];
};

Relocating the ProcessorState to what was then the end of the architecturally defined section also created 0x30 bytes of padding to satisfy the peculiar alignment requirement for the LockQueue at the start of the non-architectural section. This too is defined explicitly (as PrcbPad12, below). As parts of it have been brought into use, there is again a difference between the two KPRCB definitions.

KPROCESSOR_STATE ProcessorState;

XSAVE_AREA_HEADER *ExtendedSupervisorState;

ULONG ProcessorSignature;

ULONG PrcbPad11a;

ULONG ProcessorFlags;

ULONG64 PrcbPad12a;

union {
    struct {
        /*  changing members, follow link  */
    };
    ULONG64 PrcbPad12a;
};

ULONG64 PrcbPad12 [6];

ULONG64 PrcbPad12 [5];

ULONG64 PrcbPad12 [4];

ULONG64 PrcbPad12 [3];

For reasons not yet understood, the reduced definition has ProcessorSignature before it was yet in the full definition. No use is yet known of it in the 1803 release: evidently, more study is required!

Non-Achitectural

From here onwards, the KPRCB does indeed seem to be private to the kernel. In contrast to 32-bit Windows, not even the HAL is known to use anything beyond the architecturally defined section.

Spin Lock Queues

Functions such as KeAcquireQueuedSpinLock that operate on the per-processor spin lock queues are exported from the HAL (originally) in 32-bit Windows but have always been kernel exports in 64-bit Windows. Another difference from 32-bit Windows is that the LockQueue is outside the architecturally defined section: the kernel itself accesses the LockQueue via the LockArray pointer in the KPCR.

KSPIN_LOCK_QUEUE LockQueue [0x21];

KSPIN_LOCK_QUEUE LockQueue [0x31];

KSPIN_LOCK_QUEUE LockQueue [0x11];

The LockQueue array is indexed by members of the enumeration KSPIN_LOCK_QUEUE_NUMBER, which is defined first in NTDDK.H and then in WDM.H (starting with the WDK for Windows Vista). As with 32-bit Windows, the array is positioned such that its second element is cache-aligned. This is plainly by design. Caching is important to the 64-bit implementation, whose KeReleaseQueuedSpinLock has always prefetched its selected element. Why the first element should be in a separate cache line from the second is not known.

Lookaside Lists

Broadly speaking, there are two separate types of per-processor lookaside lists. First come the system lookaside lists. Each caches a different fixed-size structure that has a very specific purpose represented by the list’s index, which takes it values from the undocumented PP_NPAGED_LOOKASIDE_NUMBER enumeration.

PP_LOOKASIDE_LIST PPLookasideList [0x10];

The undocumented PP_LOOKASIDE_LIST structure is a pair of pointers, P and L, to the actual lookaside lists. Ideally, they point to separate lists: the first just for the processor; the second shared. Allocations are sought first from the per-processor list, for speed, else from the shared. Allocations are freed to the per-processor list for easy re-allocation, except that if that list has reached its capacity the allocation is instead freed to the shared list.

The remaining arrays help with the efficiency of small allocations from various types of pool (NonPagedPool, PagedPool and, in version 6.2 and higher, NonPagedPoolNx). The purpose of the allocation is arbitrary. What matters is just the size: successive lists in the array are for successively larger sizes of allocation, from 0x10 to 0x0200, in increments of 0x10.

GENERAL_LOOKASIDE_POOL PPNxPagedLookasideList [0x20];

PP_LOOKASIDE_LIST PPNPagedLookasideList [0x20];

GENERAL_LOOKASIDE_POOL PPNPagedLookasideList [0x20];

PP_LOOKASIDE_LIST PPPagedLookasideList [0x20];

GENERAL_LOOKASIDE_POOL PPPagedLookasideList [0x20];

Mostly Counters

ULONG64 volatile PacketBarrier;

ULONG64 PrcbPad20;

ULONG64 MsrIa32TsxCtrl;

SINGLE_LIST_ENTRY DeferredReadyListHead;

LONG volatile MmPageFaultCount;

LONG volatile MmCopyOnWriteCount;

LONG volatile MmTransitionCount;

LONG volatile MmCacheTransitionCount;

LONG volatile MmDemandZeroCount;

LONG volatile MmPageReadCount;

LONG volatile MmPageReadIoCount;

LONG volatile MmCacheReadCount;

LONG volatile MmCacheIoCount;

LONG volatile MmDirtyPagesWriteCount;

LONG volatile MmDirtyWriteIoCount;

LONG volatile MmMappedPagesWriteCount;

LONG volatile MmMappedWriteIoCount;

LONG LookasideIrpFloat;

ULONG KeSystemCalls;

ULONG KeContextSwitches;

USHORT LdtSelector;

USHORT PrcbPad40;

ULONG PrcbPad40;

ULONG CcFastReadNoWait;

ULONG CcFastReadWait;

ULONG CcFastReadNotPossible;

ULONG CcCopyReadNoWait;

ULONG CcCopyReadWait;

ULONG CcCopyReadNoWaitMiss;

LONG LookasideIrpFloat;

LONG volatile IoReadOperationCount;

LONG volatile IoWriteOperationCount;

LONG volatile IoOtherOperationCount;

LARGE_INTEGER IoReadTransferCount;

LARGE_INTEGER IoWriteTransferCount;

LARGE_INTEGER IoOtherTransferCount;

ULONG KeContextSwitches;

UCHAR PrcbPad2 [0x0C];

Cache-alignment again seeems deliberate, at least in version 5.2.

Inter-Processor Interrupts

LONG volatile PacketBarrier;

ULONG64 volatile TargetSet;

LONG volatile TargetCount;

ULONG volatile IpiFrozen;

UCHAR PrcbPad3 [0x74];

Note the substantial padding in the early versions, not just to the next cache line but to the one after (perhaps anticipating 128-byte cache lines). These versions have a REQUEST_MAILBOX for each of the 64 possible processors. For Windows 7 to support more, the array was moved to the very end of the KPRCB.

REQUEST_MAILBOX RequestMailbox [0x40];

ULONG64 volatile SenderSummary;

UCHAR PrcbPad4 [0x78];

 Deferred Procedure Calls And Timing

ULONG PrcbPad40 [0x1D];

ULONG PrcbPad30;

PVOID IsrDpcStats;

ULONG DeviceInterrupts;

LONG LookasideIrpFloat;

ULONG InterruptLastCount;

ULONG InterruptRate;

ULONG64 LastNonHrTimerExpiration;

ULONG64 PrcbPad31;

KPRCB *PairPrcb;

KSTATIC_AFFINITY_BLOCK StaticAffinity;

ULONG64 PrcbPad35 [2];

ULONG64 PrcbPad35 [1];

ULONG64 PrcbPad35 [5];

SLIST_HEADER InterruptObjectPool;

RTL_HASH_TABLE *DpcRuntimeHistoryHashTable;

KPDC *DpcRuntimeHistoryHashTableCleanupDpc;

KDEFERRED_ROUTINE *CurrentDpcRoutine;

ULONG64 CurrentDpcRuntimeHistoryCached;

ULONG64 CurrentDpcStartTime;

ULONG PrcbPad41 [0x16];

ULONG PrcbPad41 [0x14];

ULONG64 PrcbPad41 [6];

ULONG64 PrcbPad41 [1];

KDPC_DATA DpcData [2];

PVOID DpcStack;

PVOID SavedRsp;

PVOID SparePtr0;

LONG MaximumDpcQueueDepth;

ULONG DpcRequestRate;

ULONG MinimumDpcRate;

BOOLEAN volatile DpcInterruptRequested;

BOOLEAN volatile DpcThreadRequested;

BOOLEAN volatile DpcRoutineActive;

BOOLEAN volatile DpcThreadActive;

union {
    ULONG64 volatile TimerHand;
    ULONG64 volatile TimerRequest;
};

LONG TickOffset;

LONG MasterOffset;

ULONG DpcLastCount;

BOOLEAN ThreadDpcEnable;

BOOLEAN volatile QuantumEnd;

UCHAR PrcbPad50;

BOOLEAN volatile DpcRoutineActive;

BOOLEAN volatile IdleSchedule;

LONG DpcSetEventRequest;

union {
    LONG volatile DpcRequestSummary;
    SHORT DpcRequestSlot [2];
    /*  changing members, follow link  */
};

Miscellany

LONG PrcbPad40;

ULONG KeExceptionDispatchCount;

ULONG volatile TimerHand;

ULONG LastTimerHand;

ULONG PrcbPad93;

PVOID DpcThread;

KEVENT DpcEvent;

LONG MasterOffset;

ULONG LastTick;

ULONG UnusedPad;

ULONG ClockInterrupts;

ULONG ReadyScanTick;

UCHAR BalanceState;

ULONG64 PrcbPad50 [2];

UCHAR PrcbPad50 [7];

ULONG InterruptLastCount;

ULONG InterruptRate;

PVOID InterruptObject [0x0100];

KTIMER_TABLE TimerTable;

ULONG PrcbPad92 [10];

KGATE DpcGate;

PVOID PrcbPad51;

PVOID PrcbPad52;

KDPC CallDpc;

LONG ClockKeepAlive;

UCHAR ClockCheckSlot;

UCHAR ClockPollCycle;

UCHAR PrcbPad6 [2];

UCHAR PrcbPad60 [2];

USHORT NmiActive;

union {
    struct {
        UCHAR NmiActive;
        UCHAR MceActive;
    };
    USHORT CombinedNmiMceActive;
};

LONG DpcWatchdogPeriod;

LONG DpcWatchdogCount;

ULONG64 TickOffset;

LONG volatile KeSpinLockOrdering;

ULONG DpcWatchdogProfileCumulativeDpcThreshold;

PVOID CachedPtes;

ULONG64 PrcbPad7 [4];

ULONG64 PrcbPad70 [2];

ULONG PrcbPad70;

ULONG PrcbPad70 [1];

Scheduling

LIST_ENTRY WaitListHead;

KSPIN_LOCK WaitLock;

ULONG ReadySummary;

LONG AffinitizedSelectionMask;

ULONG QueueIndex;

ULONG ReadyQueueWeight;

ULONG PrcbPad75;

ULONG PrcbPad75 [3];

ULONG PrcbPad75 [2];

ULONG DpcWatchdogSequenceNumber;

KDPC TimerExpirationDpc;

KPRCB *BuddyPrcb;

RTL_RB_TREE ScbQueue;

ULONG64 PrcbPad71 [0x0C];

ULONG64 PrcbPad72 [4];

LIST_ENTRY DispatcherReadyListHead [0x20];

ULONG InterruptCount;

ULONG KernelTime;

ULONG UserTime;

ULONG DpcTime;

ULONG InterruptTime;

ULONG AdjustDpcThreshold;

UCHAR SkipTick;

UCHAR DebuggerSavedIRQL;

UCHAR PollSlot;

BOOLEAN GroupSchedulingOverQuota;

BOOLEAN volatile DeepSleep;

UCHAR PrcbPad8 [0x0D];

UCHAR PrcbPad80 [5];

UCHAR PrcbPad80 [7];

UCHAR PrcbPad80 [1];

UCHAR PrcbPad80 [5];

UCHAR PrcbPad80;

ULONG ScbOffset;

ULONG DpcTimeCount;

ULONG DpcTimeLimit;

ULONG PeriodicCount;

ULONG PeriodicBias;

ULONG AvailableTime;

ULONG KeExceptionDispatchCount;

ULONG ReadyThreadCount;

ULONG64 ReadyQueueExpectedRunTime;

ULONG64 PrcbPad81 [2];

KNODE *ParentNode;

KAFFINITY MultiThreadProcesserSet;

KPRCB *MultiThreadSetMaster;

LONG Sleeping;

ULONG64 StartCycles;

ULONG64 TaggedCyclesStart;

ULONG64 TaggedCycles [2];

ULONG64 TaggedCycles [3];

ULONG64 GenerationTarget;

ULONG64 AffinitizedCycles;

ULONG64 ImportantCycles;

ULONG64 UnimportantCycles;

ULONG64 ReadyQueueExpectedRunTime;

ULONG64 PrcbPad82 [3];

ULONG64 PrcbPad81;

ULONG64 PrcbPad81 [2];

ULONG PrcbPad81 [0x1D];

ULONG PrcbPad81 [0x15];

ULONG DpcWatchdogProfileSingleDpcThreshold;

LONG volatile MmSpinLockOrdering;

PVOID volatile CachedStack;

ULONG PrcbPad90 [1];

ULONG DebugDpcTime;

ULONG PageColor;

ULONG NodeColor;

ULONG NodeShiftedColor;

ULONG SecondaryColorMask;

LONG Sleeping;

ULONG PrcbPad83;

ULONG64 PrcbPad81 [3];

UCHAR PrcbPad81 [7];

UCHAR PrcbPad81 [6];

BOOLEAN ExceptionStackActive;

UCHAR TbFlushListActive;

PVOID ExceptionStack;

ULONG64 PrcbPad82 [2];

ULONG64 PrcbPad82 [1];

ULONG64 CycleTime;

ULONG64 Cycles [4][2];

ULONG PrcbPad84 [0x10];

UCHAR PrcbPad9 [0x0C];

Counters

Windows Vista added numerous counters, mostly to do with caching by the file system, to an original handful. For some reason, the originals were moved to another area of counters nearer the start.

ULONG CcFastReadNoWait;

ULONG CcFastReadWait;

ULONG CcFastReadNotPossible;

ULONG CcCopyReadNoWait;

ULONG CcCopyReadWait;

ULONG CcCopyReadNoWaitMiss;

ULONG CcFastMdlReadNoWait;

ULONG CcFastMdlReadWait;

ULONG CcFastMdlReadNotPossible;

ULONG CcMapDataNoWait;

ULONG CcMapDataWait;

ULONG CcPinMappedDataCount;

ULONG CcPinReadNoWait;

ULONG CcPinReadWait;

ULONG CcMdlReadNoWait;

ULONG CcMdlReadWait;

ULONG CcLazyWriteHotSpots;

ULONG CcLazyWriteIos;

ULONG CcLazyWritePages;

ULONG CcDataFlushes;

ULONG CcDataPages;

ULONG CcLostDelayedWrites;

ULONG CcFastReadResourceMiss;

ULONG CcCopyReadWaitMiss;

ULONG CcFastMdlReadResourceMiss;

ULONG CcMapDataNoWaitMiss;

ULONG CcMapDataWaitMiss;

ULONG CcPinReadNoWaitMiss;

ULONG CcPinReadWaitMiss;

ULONG CcMdlReadNoWaitMiss;

ULONG CcMdlReadWaitMiss;

ULONG CcReadAheadIos;

ULONG MmCacheTransitionCount;

ULONG MmCacheReadCount;

ULONG MmCacheIoCount;

ULONG PrcbPad91 [3];

ULONG PrcbPad91 [1];

ULONG PrcbPad91 [3];

ULONG PrcbPad91;

ULONG64 RuntimeAccumulation;

PVOID MmFlushList;

PVOID MmInternal;

Windows Vista brought forward the PowerState to a cache boundary.

PROCESSOR_POWER_STATE PowerState;

PVOID HyperPte;

PVOID ScbList [2];

KDPC ForceIdleDpc;

UCHAR PrcbPad92 [0x10];

ULONG PrcbPad92 [0x16];

ULONG PrcbPad92 [0x13];

ULONG PrcbPad92 [7];

ULONG PrcbPad92 [0x12];

ULONG KeAlignmentFixupCount;

ULONG KeDcacheFlushCount;

ULONG KeExceptionDispatchCount;

ULONG KeFirstLevelTbFills;

ULONG KeFloatingEmulationCount;

ULONG KeIcacheFlushCount;

ULONG KeSecondLevelTbFills;

UCHAR VendorString [0x0D];

UCHAR PrcbPad10 [2];

UCHAR PrcbPad10 [3];

ULONG FeatureBits;

LARGE_INTEGER UpdateSignature;

PROCESSOR_POWER_STATE PowerState;

KDPC DpcWatchdogDpc;

KTIMER DpcWatchdogTimer;

CACHE_DESCRIPTOR Cache [5];

ULONG CacheCount;

Given a GenuineIntel processor whose CpuType, i.e., family, is at least 6, the UpdateSignature is all 64 bits that are read from the Model Specific Register 0x8B (IA32_BIOS_SIGN_ID), having first written zero to that register and then executed the cpuid instruction’s leaf 1. Starting with version 6.2, Windows also gets the UpdateSignature—by a straightforward read of the MSR—if the vendor is AuthenticAMD and the family is at least 15.

Appended For Windows Vista

ULONG volatile CachedCommit;

ULONG volatile CachedResidentAvailable;

PVOID HyperPte;

PVOID WheaInfo;

PVOID EtwSupport;

SLIST_HEADER InterruptObjectPool;

PVOID ExSaPageArray;

ULONG KeAlignmentFixupCount;

ULONG PrcbPad95;

LARGE_INTEGER HypercallPagePhysical;

SLIST_HEADER HypercallPageList;

ULONGLONG *StatisticsPage;

ULONG64 GenerationTarget;

ULONG64 PrcbPad85 [5];

ULONG64 PrcbPad85 [4];

PVOID HypercallPageVirtual;

PVOID HypercallCachedPages;

PVOID VirtualApicAssist;

ULONGLONG *StatisticsPage;

PVOID RateControl;

ULONG64 CacheProcessorMask [5];

KAFFINITY PackageProcessorSet;

KAFFINITY_EX PackageProcessorSet;

ULONG PackageId;

ULONG64 PrcbPad86;

ULONG PrcbPad86;

ULONG CacheProcessorMask [5];

ULONG64 SharedReadyQueueMask;

KSHARED_READY_QUEUE *SharedReadyQueue;

ULONG SharedQueueScanOwner;

ULONG ScanSiblingIndex;

ULONG64 CoreProcessorSet;

ULONG64 ScanSiblingMask;

ULONG64 LLCMask;

ULONG64 CacheProcessorMask [5];

ULONG ScanSiblingIndex;

ULONG SharedReadyQueueOffset;

ULONG LLCLevel;

KAFFINITY CoreProcessorSet;

PROCESSOR_PROFILE_CONTROL_AREA *ProcessorProfileControlArea;

PVOID PebsIndexAddress;

PVOID ProfileEventIndexAddress;

PVOID *DpcWatchdogProfile;

PVOID *DpcWatchdogProfileCurrentEmptyCapture;

PVOID SchedulerAssist;

ULONG64 PrcbPad93 [0x0C];

Inserted For Windows 7

Windows 7 defines numerous performance counters for synchronisation.

ULONG SpinLockAcquireCount;

ULONG SpinLockContentionCount;

ULONG SpinLockSpinCount;

ULONG IpiSendRequestBroadcastCount;

ULONG IpiSendRequestRoutineCount;

ULONG IpiSendSoftwareInterruptCount;

ULONG ExInitializeResourceCount;

ULONG ExReInitializeResourceCount;

ULONG ExDeleteResourceCount;

ULONG ExecutiveResourceAcquiresCount;

ULONG ExecutiveResourceContentionsCount;

ULONG ExecutiveResourceReleaseExclusiveCount;

ULONG ExecutiveResourceReleaseSharedCount;

ULONG ExecutiveResourceConvertsCount;

ULONG ExAcqResExclusiveAttempts;

ULONG ExAcqResExclusiveAcquiresExclusive;

ULONG ExAcqResExclusiveAcquiresExclusiveRecursive;

ULONG ExAcqResExclusiveWaits;

ULONG ExAcqResExclusiveNotAcquires;

ULONG ExAcqResSharedAttempts;

ULONG ExAcqResSharedAcquiresExclusive;

ULONG ExAcqResSharedAcquiresShared;

ULONG ExAcqResSharedAcquiresSharedRecursive;

ULONG ExAcqResSharedWaits;

ULONG ExAcqResSharedNotAcquires;

ULONG ExAcqResSharedStarveExclusiveAttempts;

ULONG ExAcqResSharedStarveExclusiveAcquiresExclusive;

ULONG ExAcqResSharedStarveExclusiveAcquiresShared;

ULONG ExAcqResSharedStarveExclusiveAcquiresSharedRecursive;

ULONG ExAcqResSharedStarveExclusiveWaits;

ULONG ExAcqResSharedStarveExclusiveNotAcquires;

ULONG ExAcqResSharedWaitForExclusiveAttempts;

ULONG ExAcqResSharedWaitForExclusiveAcquiresExclusive;

ULONG ExAcqResSharedWaitForExclusiveAcquiresShared;

ULONG ExAcqResSharedWaitForExclusiveAcquiresSharedRecursive;

ULONG ExAcqResSharedWaitForExclusiveWaits;

ULONG ExAceResSharedWaitForExclusiveNotAcquires;

ULONG ExSetResOwnerPointerExclusive;

ULONG ExSetResOwnerPointerSharedNew;

ULONG ExSetResOwnerPointerSharedOld;

ULONG ExTryToAcqExclusiveAttempts;

ULONG ExTryToAcqExclusiveAcquires;

ULONG ExBoostExclusiveOwner;

ULONG ExBoostSharedOwners;

ULONG ExEtwSynchTrackingNotificationsCount;

ULONG ExEtwSynchTrackingNotificationsAccountedCount;

Windows 8 tidies all the preceding counters into one cache-aligned SYNCH_COUNTERS structure.

ULONG PrcbPad94 [6];

ULONG PrcbPad94 [3];

ULONG64 PrcbPad94 [11];

ULONG64 PrcbPad94 [10];

SYNCH_COUNTERS SynchCounters;

ULONG64 PrcbPad94;

ULONG64 PteBitCache;

ULONG PteBitOffset;

FILESYSTEM_DISK_COUNTERS FsCounters;

UCHAR VendorString [0x0D];

UCHAR PrcbPad10 [3];

UCHAR PrcbPad10 [2];

UCHAR PrcbPad10 [3];

UCHAR PendingVirtualLittle;

ULONG FeatureBits;

ULONG64 FeatureBits;

ULONG PrcbPad11;

ULONG PrcbPad110;

LARGE_INTEGER UpdateSignature;

ULONG64 PteBitCache;

ULONG PteBitOffset;

ULONG PrcbPad105;

CONTEXT *Context;

ULONG ContextFlags;

ULONG ContextFlagsInit;

ULONG PrcbPad115;

XSAVE_AREA *ExtendedState;

Inserted for Windows 8 and 8.1

PVOID IsrStack;

KENTROPY_TIMING_STATE EntropyTimingState;

ULONG64 PrcbPad110;

ULONG64 PrcbPad111 [7];

struct {
    ULONG UpdateCycle;
    union {
        SHORT PairLocal;
        struct {
            UCHAR PairLocalLow;
            UCHAR PairLocalForceStibp : 1;
            UCHAR Reserved : 4;
            UCHAR Frozen : 1;
            UCHAR ForceUntrusted : 1;
            UCHAR SynchIpi : 1;
        };
    };
    union {
        SHORT PairRemote;
        struct {
            UCHAR PairRemoteLow;
            UCHAR Reserved2;
        };
    };
    UCHAR Trace [0x18];
    ULONG64 LocalDomain;
    ULONG64 RemoteDomain;
    KTHREAD *Thread;
} StibpPairingTrace;

SINGLE_LIST_ENTRY AbSelfIoBoostsList;

SINGLE_LIST_ENTRY AbPropagateBoostsList;

KDPC AbDpc;

Inserted For Windows 10

IOP_IRP_STACK_PROFILER IoIrpStackProfilerCurrent;

IOP_IRP_STACK_PROFILER IoIrpStackProfilerPrevious;

KSECURE_FAULT_INFORMATION SecureFault;

ULONG64 PrcbPad120;

KSHARED_READY_QUEUE LocalSharedReadyQueue;

ULONG64 PrcbPad125 [2];

ULONG TimerExpirationTraceCount;

ULONG PrcbPad127;

KTIMER_EXPIRATION_TRACE TimerExpirationTrace [0x10];

ULONG TimerExpirationTraceCount;

PVOID ExSaPageArray;

KSECURE_FAULT_INFORMATION SecureFault;

ULONG64 PrcbPad128 [7];

Appended for Windows 7

The mailboxes for inter-processor communications were moved to the end of the KPRCB in Windows 7 so that the array can accommodate arbitrarily many processors but still be in the KPRCB. Both the pointer and the array are cache-aligned without explicit padding in most versions.

REQUEST_MAILBOX *Mailbox;

ULONG64 PrcbPad130 [7];

MACHINE_CHECK_CONTEXT McheckContext [2];

ULONG64 PrcbPad134 [4];

KLOCK_QUEUE_HANDLE SelfmapLockHandle [4];

ULONG64 PrcbPad134a [4];

UCHAR PrcbPad135 [0x04A0];

UCHAR PrcbPad138 [0x03C0];

PrcbPad138a;

ULONG64 KernelDirectoryTableBase;

ULONG64 RspBaseShadow;

ULONG64 UserRspShadow;

ULONG ShadowFlags;

ULONG PrcbPad138b;

ULONG64 PrcbPad138c;

USHORT PrcbPad138d;

USHORT PrcbPad138e;

USHORT VerwSelector;

ULONG DbgMceNestingLevel;

ULONG DbgMceFlags;

ULONG PrcbPad139;

ULONG PrcbPad139b;

ULONG64 PrcbPad140 [0x01FC];

ULONG64 PrcbPad140 [0x01FB];

ULONG64 PrcbPad140 [0x01F9];

ULONG64 PrcbPad140a [8];

ULONG64 PrcbPad141 [0x01F8];

UCHAR PrcbPad141a [0x40];

REQUEST_MAILBOX RequestMailbox [ANYSIZE_ARRAY];