KTHREAD (5.2 SP1 To 6.1)

The KTHREAD structure is the Kernel Core’s portion of the ETHREAD structure. The latter is the thread object as exposed through the Object Manager. The KTHREAD is the core of it.

Variability

The KTHREAD structure is plainly internal to the kernel and its layout varies greatly between Windows versions and even between builds. Indeed, it is the most highly variable of all significant kernel-mode structures—so much so that tracking its history looks to be imposisble on one page and is therefore spread over several:

• versions 3.10 to 3.50;
• versions 3.51 to 5.1;
• version 5.2 before SP1;
• versions 5.2 SP1 to 6.1;
• versions 6.2 and higher.

Though the KTHREAD had been relatively stable through versions 3.51 to 5.1, the original Windows Server 2003 brought a substantial rearrangement. This perhaps anticipated 64-bit Windows, but when x64 builds actually didi appear for the first service pack the structure was rearranged almost as much again.

Distinctively new for the versions that have both x86 and x64 builds is the packing of small members into spare fields in other members. Some such reused fields are explicitly spare, as with several members of the KAPC structure. WDM.H even defines macros to ease the reference to these fields by their offsets. Other reuse is available only because of alignment padding, as with the last byte of the KAPC_STATE for 32-bit Windows. There is more opportunity for this reuse in the 64-bit builds, whose wider pointers tend to create alignment padding as a side-effect. To take advantage of this to get a smaller KTHREAD for the late builds of version 5.2, numerous members are reordered from the early builds of version 5.2, and a few are ordered differently in the 32-bit and 64-bit builds. To track this reordering continuously with even the immediately preceding build is just not feasible.

In the following table of sizes, different builds of the same version are distinguished as early, late and very late. These descriptions are then used throughout this article as a shorthand.

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

Layout

It is well known that the KTHREAD is a kernel object that can be waited on until it gets signalled, as happens when the thread ends its execution. In the DISPATCHER_HEADER at the beginning of a KTHREAD, the Type is ThreadObject (6) in the KOBJECTS enumeration.

DISPATCHER_HEADER Header;

LIST_ENTRY MutantListHead;

ULONGLONG volatile CycleTime;

ULONG volatile HighCycleTime;

ULONGLONG QuantumTarget;

PVOID InitialStack;

PVOID StackLimit;

PVOID volatile StackLimit;

PVOID KernelStack;

KSPIN_LOCK ThreadLock;

KWAIT_STATUS_REGISTER WaitRegister;

BOOLEAN volatile Running;

BOOLEAN Alerted [2];

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

union {
    KAPC_STATE ApcState;
    /*  overlay, see below  */
};

Overlaying the ApcState is the structure

struct {
    UCHAR ApcStateFill [KAPC_STATE_ACTUAL_LENGTH];
    /*  5 bytes, see below  */
};

With this construction, the 64-bit builds fit five bytes into the 0x30-byte ApcState. In 32-bit builds, only the first fits the 0x18-byte ApcState: the rest just follow as if they had been declared outside the union. Disregard the construction, and the members that are packed with the ApcState are:

BOOLEAN ApcQueueable;

CHAR Priority;

UCHAR volatile NextProcessor;

USHORT volatile NextProcessor;

ULONG volatile NextProcessor;

UCHAR volatile DeferredProcessor;

USHORT volatile DeferredProcessor;

ULONG volatile DeferredProcessor;

UCHAR AdjustReason;

CHAR AdjustIncrement;

For all the contrivance, the packing had to change as soon as version 6.0. First, one of the single-byte members was just a boolean, such that it could add even less to the KTHREAD if converted to a bit field. Second, the two single-byte members NextProcessor and DeferredProcessor were widened to 16 bits. For them to stay in the ApcState, two that hadn’t changed had to be moved out. The widening to 32 bits for version 6.1 pushed DeferredProcessor out of the reclaimed space (and it may be that Microsoft’s C-language definition doesn’t leave DeferrredProcessor in the ApcState union.)

KSPIN_LOCK ApcQueueLock;

ULONG ContextSwitches;

UCHAR volatile State;

UCHAR NpxState;

KIRQL WaitIrql;

KPROCESSOR_MODE WaitMode;

LONG_PTR WaitStatus;

union {
    KWAIT_BLOCK *WaitBlockList;
    KGATE *GateObject;
};

KWAIT_BLOCK *WaitBlockList;

BOOLEAN Alertable;

BOOLEAN WaitNext;

union {
    struct {
        /*  bit fields, see below  */
    };
    LONG MiscFlags;  
};

UCHAR WaitReason;

CHAR Priority;

BOOLEAN EnableStackSwap;

UCHAR volatile SwapBusy;

UCHAR Alerted [2];

union {
    LIST_ENTRY WaitListEntry;
    SINGLE_LIST_ENTRY SwapListEntry;
};

KQUEUE *Queue;

KQUEUE * volatile Queue;

ULONG WaitTime;

union {
    struct {
        SHORT KernelApcDisable;
        SHORT SpecialApcDisable;
    };
    ULONG CombinedApcDisable;
};

PVOID Teb;

union {
    KTIMER Timer;
    /*  overlay, see below  */
};

Overlaying the long-standing Timer is the structure

struct {
    UCHAR TimerFill [KTIMER_ACTUAL_LENGTH];
    /*  4 bytes, see below  */
};

The 64-bit KTIMER originally had four bytes of unused space at its end. This was a snug fit for a newly defined set of bit flags, which seem to have been kept with the Timer even after a reworking of the KTIMER for version 6.1 put the alignment space to use. Though only the one member ever was squeezed in, it changed slightly while Microsoft’s programmers seem to have been uncertain about what needs to be volatile:

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

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

Because the change within the KTIMER for version 6.1 has the side-effect that the ThreadFlags are no longer inside the Timer, the 64-bit builds were left with four bytes of spare space for the 8-byte alignment of the WaitBlock. The 32-bit builds always had these four bytes left by alignment, but perhaps nobody cared. Once noticed, the alignment space got used for the ServiceTable, which had anyway been discontinued for 64-bit builds.

PVOID ServiceTable;

ULONG Spare0;

The KWAIT_BLOCK structure has a spare byte in x86 builds and another four in x64 builds. With the KTHREAD having four of these structures as its WaitBlock array, packing members into this space was evidently irresistable, even if it’s spectacularly messy. Then, for version 6.1, it seems to have been decided that the single bytes weren’t worth picking up in either build, but the 64-bit builds reclaim yet more from realising that the particular use that’s made of the last KWAIT_BLOCK does not involve its Object member.

union {
    KWAIT_BLOCK WaitBlock [4];
    /*  overlay, see below  */
};

KWAIT_BLOCK WaitBlock [4];

union {
    KWAIT_BLOCK WaitBlock [4];
    /*  overlay, see below  */
};

Overlaying the long-standing WaitBlock are a succession of structures that pad to the spare or resuable member:

#if NTDDI_VERSION < NTDDI_WIN7      // SpareByte not used in 6.1
struct {
    UCHAR WaitBlockFill0 [FIELD_OFFSET (KWAIT_BLOCK, SpareByte)];
    /*  reclaimed byte, see below  */
};
struct {
    UCHAR WaitBlockFill1 [FIELD_OFFSET (KWAIT_BLOCK, SpareByte) + sizeof (KWAIT_BLOCK)];
    /*  reclaimed byte, see below  */
};
struct {
    UCHAR WaitBlockFill2 [FIELD_OFFSET (KWAIT_BLOCK, SpareByte) + 2 * sizeof (KWAIT_BLOCK)];
    /*  reclaimed byte, see below  */
};
struct {
    UCHAR WaitBlockFill3 [FIELD_OFFSET (KWAIT_BLOCK, SpareByte) + 3 * sizeof (KWAIT_BLOCK)];
    /*  reclaimed byte, see below  */
};
#endif
#ifdef _AMD64_                      // SpareLong exists only for x64
struct {
    UCHAR WaitBlockFill4 [FIELD_OFFSET (KWAIT_BLOCK, SpareLong)];
    /*  reclaimed 4 bytes, see below  */
};
struct {
    UCHAR WaitBlockFill5 [FIELD_OFFSET (KWAIT_BLOCK, SpareLong) + sizeof (KWAIT_BLOCK)];
    /*  reclaimed 4 bytes, see below  */
};
struct {
    UCHAR WaitBlockFill6 [FIELD_OFFSET (KWAIT_BLOCK, SpareLong) + 2 * sizeof (KWAIT_BLOCK)];
    /*  reclaimed 4 bytes, see below  */
};
# if NTDDI_VERSION < NTDDI_WIN7
struct {
    UCHAR WaitBlockFill7 [FIELD_OFFSET (KWAIT_BLOCK, SpareLong) + 3 * sizeof (KWAIT_BLOCK)];
    /*  reclaimed 4 bytes, see below  */
};
# else                              // last Object reclaimed in 6.1
struct {
    UCHAR WaitBlockFill7 [FIELD_OFFSET (KWAIT_BLOCK, Object) + 3 * sizeof (KWAIT_BLOCK)];
    /*  Reclaimed 16 bytes, see below  */
};
struct {
    UCHAR WaitBlockFill8 [FIELD_OFFSET (KWAIT_BLOCK, SpareLong) + 3 * sizeof (KWAIT_BLOCK)];
    /*  reclaimed 4 bytes, see below  */
};
# endif
#endif

Put aside the scaffolding and here are the members that get squeezed in with the WaitBlock:

BOOLEAN SystemAffinityActive;

UCHAR IdealProcessor;

ULONG ContextSwitches;

KPROCESSOR_MODE PreviousMode;

UCHAR volatile State;

UCHAR NpxState;

KIRQL WaitIrql;

KPROCESSOR_MODE WaitMode;

UCHAR ResourceIndex;

ULONG WaitTime;

PVOID TebMappedLowVa;

UMS_CONTROL_BLOCK *Ucb;

BOOLEAN LargeStack;

union {
    struct {
        SHORT KernelApcDisable;
        SHORT SpecialApcDisable;
    };
    ULONG CombinedApcDisable;
};

Yes, there is a plan to write something here.

LIST_ENTRY QueueListEntry;

KTRAP_FRAME *TrapFrame;

PVOID FirstArgument;

PVOID CallbackStack;

union {
    PVOID CallbackStack;
    ULONG_PTR CallbackDepth;
};

PVOID ServiceTable;

ULONG KernelLimit;

UCHAR ApcStateIndex;

UCHAR IdealProcessor;

BOOLEAN Preempted;

BOOLEAN ProcessReadyQueue;

PVOID Win32kTable;

ULONG Win32kLimit;

BOOLEAN KernelStackResident;

CHAR BasePriority;

CHAR PriorityDecrement;

union {
    CHAR PriorityDecrement;
    struct {
        UCHAR ForegroundBoost : 4;
        UCHAR UnusualBoost : 4;
    };
};

BOOLEAN Preempted;

UCHAR AdjustReason;

CHAR AdjustIncrement;

UCHAR Spare01;

KPROCESSOR_MODE PreviousMode;

CHAR Saturation;

ULONG SystemCallNumber;

ULONG Spare02;

ULONG FreezeCount;

KAFFINITY UserAffinity;

GROUP_AFFINITY volatile UserAffinity;

KPROCESS *Process;

KAFFINITY Affinity;

KAFFINITY volatile Affinity;

GROUP_AFFINITY volatile Affinity;

ULONG IdealProcessor;

ULONG UserIdealProcessor;

KAPC_STATE *ApcStatePointer [2];

The KTHREAD has two KAPC_STATE structures. The second is used when the thread attaches to another process’s address space. It too has a spare byte in 32-bit builds and a spare five in 64-bit builds:

union {
    KAPC_STATE SavedApcState;
    /*  overlay, see below  */
};

Overlaying the long-standing SavedApcState is the structure

struct {
    UCHAR SavedApcStateFill [KAPC_STATE_ACTUAL_LENGTH];
    /*  5 bytes, see below  */
};

With this construction, the 64-bit builds fit five bytes into the 0x30-byte SavedApcState. In 32-bit builds, only the first fits the 0x18-byte SavedApcState: the rest just follow as if they had been declared outside the union. Disregard the construction, and the members that are packed with the SavedApcState are:

CHAR FreezeCount;

UCHAR Spare02;

UCHAR WaitReason;

CHAR SuspendCount;

UCHAR UserIdealProcessor;

CHAR Spare1;

BOOLEAN CalloutActive;

BOOLEAN Spare03;

UCHAR Iopl;

UCHAR OtherPlatformFill;

BOOLEAN CodePatchInProgress;

Yes, there is a plan to write something here.

PVOID Win32Thread;

PVOID StackBase;

union {
    KAPC SuspendApc;
    /*  overlay, see below  */
};

Overlaying the long-standing SuspendApc are structures that each pad to a spare or resuable member or to alignment space:

struct {
    UCHAR SuspendApcFill0 [KAPC_OFFSET_TO_SPARE_BYTE0];
    /*  reclaimed byte, see below  */
};
struct {
    UCHAR SuspendApcFill1 [KAPC_OFFSET_TO_SPARE_BYTE1];
    /*  reclaimed byte, see below  */
};
struct {
    UCHAR SuspendApcFill2 [KAPC_OFFSET_TO_SPARE_LONG];
    /*  reclaimed four bytes, see below  */
};
struct {
    UCHAR SuspendApcFill3 [KAPC_OFFSET_TO_SYSTEMARGUMENT1];
    /*  reclaimed 4 or 8 bytes, see below  */
};
struct {
    UCHAR SuspendApcFill4 [KAPC_OFFSET_TO_SYSTEMARGUMENT2];
    /*  reclaimed 4 or 8 bytes, see below  */
};
struct {
    UCHAR SuspendApcFill5 [KAPC_ACTUAL_LENGTH];
    /*  reclaimed 1 or 5 bytes, see below)  */
;

The KAPC is especially productive of space for members since there are not just the bytes here and there that are left by alignment but also the members that hold the callback routine’s arguments which the KTHREAD knows it doesn’t use. Here are the members that are squeezed in to the SuspendApc:

CHAR Quantum;

CHAR Spare04;

UCHAR ResourceIndex;

UCHAR QuantumReset;

ULONG KernelTime;

PVOID TlsArray;

PVOID WaitPrcb;

PVOID LegoData;

UCHAR PowerState;

BOOLEAN LargeStack;

ULONG UserTime;

union {
    KSEMAPHORE SuspendSemaphore;
    /*  overlay, see below  */
};

Overlaying the long-standing SuspendSemaphore is the structure

struct {
    UCHAR SuspendSemaphorefill [KSEMAPHORE_ACTUAL_LENGTH];
    /*  4 bytes, see below  */
};

The 64-bit KSEMAPHORE has four bytes of unused space left by its 8-byte alignment. Reclaimed from the SuspendSemaphore:

ULONG SListFaultCount;

That’s the end of the contrivances over packing members into space that’s left unused in other members.

LIST_ENTRY ThreadListEntry;

LIST_ENTRY MutantListHead;

PVOID SListFaultAddress;

LONGLONG ReadOperationCount;

LONGLONG WriteOperationCount;

LONGLONG OtherOperationCount;

LONGLONG ReadTransferCount;

LONGLONG WriteTransferCount;

LONGLONG OtherTransferCount;

PVOID volatile MdlForLockedTeb;

KTHREAD_COUNTERS *ThreadCounters;

XSTATE_SAVE *XStateSave;