KTHREAD (3.51 to 5.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.

For a good run of the early Windows versions, however, the KTHREAD is very stable. Through versions 3.51, 4.0, 5.0 and 5.1, the size hardly changes: 0x01B0 bytes until the first growth, to 0x01C0 bytes, for version 5.1. Within the structure, there is some reordering—for instance, KernelStack and Teb get swapped for version 4.0 (plausibly as a side-effect of inserting TlsArray)—but not enough to confound presentation. In the layout table below, a handful of members each make two appearances because of reordering. These duplications are indicated in the Remarks column.

The progression to version 5.2 rearranges the structure on another scale. It does happen, of course, that even large sequences are kept together. More common, however, are such examples as the single-byte members Iopl, NpxState, Saturation and Priority, which are consecutive in versions 3.51 to 5.1 but are scattered throughout the structure—to offsets 0x01B9, 0x2D, 0x010D, 0x5B, respectively—for the first build of version 5.2. Extending the layout to version 5.2 can only produce a hopeless jumble. Instead, for each member that survives to version 5.2 the Future column points the way to that member’s appearance on the separate page for early builds of version 5.2.

Layout

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 KTHREAD, Microsoft’s names and types are something of a guess from inspection of how the kernel in those versions uses the KTHREAD. Where use of a member corresponds closely with that of a version for which type information is available in Microsoft’s symbol files, 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 so much, tracking down the correspondence exhaustively would be difficult, if not impossible, even with source code.

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. In these early versions, only the Type and Size distinguish this Header from that of any other dispatcher object.

DISPATCHER_HEADER Header;

LIST_ENTRY MutantListHead;

PVOID InitialStack;

PVOID StackLimit;

PVOID KernelStack;

PVOID Teb;

PVOID TlsArray;

PVOID KernelStack;

BOOLEAN DebugActive;

UCHAR State;

BOOLEAN Alerted [MaximumMode];

UCHAR Iopl;

UCHAR NpxState;

CHAR Saturation;

CHAR Priority;

KAPC_STATE ApcState;

ULONG ContextSwitches;

UCHAR IdleSwapBlock;

UCHAR Spare0 [3];

LONG WaitStatus;

KIRQL WaitIrql;

KPROCESSOR_MODE WaitMode;

BOOLEAN WaitNext;

UCHAR WaitReason;

KWAIT_BLOCK *WaitBlockList;

LIST_ENTRY WaitListEntry;

union {
    LIST_ENTRY WaitListEntry;
    SINGLE_LIST_ENTRY SwapListEntry;
};

ULONG WaitTime;

CHAR BasePriority;

UCHAR DecrementCount;

CHAR PriorityDecrement;

CHAR Quantum;

KWAIT_BLOCK WaitBlock [5];

KWAIT_BLOCK WaitBlock [4];

When version 4.0 brought most of the windowing functionality into the kernel-mode WIN32K.SYS from such user-mode modules as WINSRV.DLL in the CSRSS server process, it had much less need for fast server-client synchronisation. This had been supported by the fourth KWAIT_BLOCK in the WaitBlock array. Its removal for version 4.0 seems to have been treated as an opportunity to insert (mostly) new members.

PVOID LegoData;

ULONG KernelApcDisable;

KAFFINITY UserAffinity;

BOOLEAN SystemAffinityActive;

UCHAR PowerState;

KIRQL NpxIrql;

UCHAR InitialNode;

UCHAR Pad [7];

UCHAR Pad [1];

PVOID ServiceTable;

Note that the preceding insertions for version 4.0 don’t fully reclaim the deleted KWAIT_BLOCK. It’s almost as if an effort was made to keep Queue at offset 0xE0, not that it stayed there long.

KQUEUE *Queue;

KSPIN_LOCK ApcQueueLock;

KTIMER Timer;

LIST_ENTRY QueueListEntry;

ULONG SoftAffinity;

KAFFINITY Affinity;

BOOLEAN Preempted;

BOOLEAN ProcessReadyQueue;

BOOLEAN KernelStackResident;

UCHAR NextProcessor;

PVOID CallbackStack;

PVOID ServiceTable;

PVOID Win32Thread;

That ServiceTable changes to Win32Thread for version 4.0 is more natural than first seems. The one pointer serves both purposes. What Win32Thread points to, if anything, is a THREADINFO. This is what WIN32K keeps for a thread that has become a GUI thread. As first introduced, it begins with the thread’s service table.

KTRAP_FRAME *TrapFrame;

KAPC_STATE *ApcStatePointer [2];

UCHAR KernelApcDisable;

KPROCESSOR_MODE PreviousMode;

BOOLEAN EnableStackSwap;

BOOLEAN LargeStack;

UCHAR ResourceIndex;

KPROCESSOR_MODE PreviousMode;

ULONG KernelTime;

ULONG UserTime;

KAPC_STATE SavedApcState;

BOOLEAN Alertable;

UCHAR ApcStateIndex;

BOOLEAN ApcQueueable;

BOOLEAN AutoAlignment;

PVOID StackBase;

KAPC SuspendApc;

KSEMAPHORE SuspendSemaphore;

LIST_ENTRY ThreadListEntry;

CHAR FreezeCount;

CHAR SuspendCount;

UCHAR IdealProcessor;

BOOLEAN DisableBoost;