THREADINFO

The THREADINFO (formally tagTHREADINFO) is the most of what WIN32K.SYS keeps about a thread. A portion at its start is reproduced as a W32THREAD (formally _W32THREAD), apparently as an unnamed member. It is not clear what governs the separation.

No thread is born with a THREADINFO and many execute to their end without ever having one—and not just for being system threads that execute no user-mode code at all. To get a THREADINFO a thread must try to use at least some of the extensive but optional GUI functionality that Windows is known and loved for. When a thread calls a system service that is not yet defined for the thread, the kernel attempts to convert the thread to a GUI thread. This gets the thread connected with WIN32K.SYS in kernel mode and its support for USER32.DLL and GDI32.DLL, among others, in user mode—and gives the thread an additional service descriptor table so that those DLLs can communicate with WIN32K. Though the distribution of the work involved in this conversion varies between versions, the mechanism is essentially unchanged since version 3.51 prepared for the introduction of WIN32K in version 4.0.

Documentation Status

Neither the W32THREAD nor the THREADINFO is documented, but structural details of the W32THREAD—more or less equivalent to having a C-language definition—are disclosed as type information in the public symbol files for WIN32K.SYS starting with Windows XP. The larger THREADINFO is apparently more secret. Though symbol files for Windows 8 and higher name the THREADINFO in the C++ decorations of internal routines, type information for the structure is present in symbol files for Windows 7 only—not before and not since.

For some versions before Windows XP, Microsoft’s names for some, and even all, members of both structures are known with varying confidence from the output of one or another debugger command as implemented in the USEREXTS.DLL or USERKDX.DLL debugger extensions which Microsoft published with one or another Device Driver Kit (DDK). Nobody would sensibly count this as documentation. It does show, however, that Microsoft understood for a while that knowledge of the THREADINFO may help programmers in the depths of debugging what they’re doing with Windows!

Access

The THREADINFO has long been a kernel-mode structure allocated from per-session paged pool, but although it is not accessible from user mode its address is readily available to user-mode software, even with low integrity, even as late as Windows 10, through all sorts of techniques from all sorts of places.

Most direct and obvious is that in each TEB for a GUI thread, the Win32ThreadInfo member, reliably at offset 0x40 since version 3.51, is formally a pointer to void but what it actually holds is the kernel-mode address of the THREADINFO. Less direct but ubiquitous is that the table of handles to user objects is in shared memory such that any user-mode process that can find the SHAREDINFO structure and knows that the aheList member addresses an array of HANDLEENTRY structures can get THREADINFO addresses by the bucketload because in each HANDLEENTRY for a user object that can be owned by a thread (as can a window, for instance) the pOwner member is the address of the owning thread’s THREADINFO.

These kernel-mode addresses’ presence in user-mode memory—despite increasing effort by Microsoft to eliminate such leakage in general—is perhaps a relic from the earliest Windows versions. Before version 4.0, the THREADINFO was a user-mode structure. Much of the work that is since done in kernel mode by WIN32K.SYS was instead done in user mode by WINSRV.DLL in the CSRSS.EXE process. Especially notable in the present context is a continuous history of a routine named xxxCreateThreadInfo now in WIN32K but with the same name in WINSRV version 3.51 and with an even earlier existence in version 3.10 as plain CreateThreadInfo.

Kernel Mode

In kernel mode, each KTHREAD has a Win32Thread member whose value is returned by the exported function PsGetThreadWin32Thread in version 5.1 and higher. Starting with version 5.2 from Windows Server 2003 SP1, the kernel also exports a PsGetCurrentThreadWin32Thread which, of course, reads this member specifically from the current thread’s KTHREAD. The contemporaneous elaboration PsGetCurrentThreadWin32ThreadAndEnterCriticalRegion does the same but also puts the thread into a critical region (as if to have called KeEnterCriticalRegion) and indirectly returns the thread’s process ID. None of these functions are documented, but all three are declared in the NTOSP.H that was disclosed in some editions of the Windows Driver Kit (WDK) for Windows 10.

The Win32Thread in the KTHREAD also is formally a pointer to void. Historically, what it actually points to, if it points to anything, is the THREADINFO. In version 10.0, however, it points to a W32THREADNONPAGED that is in session-global non-paged pool and whose pW32Thread is in turn a pointer to the THREADINFO (which, remember, is in per-session paged pool).

Layout

Not only is the THREADINFO highly variable between versions but in the one version for which publicly available symbol files have type information not just for the W32THREAD but for the THREADINFO too, reconciling the information against the matching executable shows immediately that the THREADINFO as described in the symbol files is not the full story. The memory block the THREADINFO is created in is larger than is declared for the structure, yet the additional space is accessed as if for members of a larger structure. It could be that the THREADINFO is itself a reduction from an even more secret structure, but close inspection shows something more interesting: the THREADINFO as described by type information in the symbol file for WIN32K is not the THREADINFO that the matching WIN32K executable actually uses. Even the following table just of changing sizes is therefore not just more than usually complex but more than usually uncertain.

That the THREADINFO shrinks by nearly half before it starts the continuing growth that would ordinarily be expected is because three relatively large structures that are later built on the stack or in dynamically allocated memory started out in the THREADINFO itself.

W32THREAD

For versions 5.1 and higher, offsets, types and Microsoft’s names for the first part of the THREADINFO are known from type information in public symbol files. For versions 4.0 and 5.0, offsets and Microsoft’s names are known with good confidence from the output of the debugger’s !dso command as supported by the USEREXTS.DLL and USERKDX.DLL debugger extensions for these versions.

Memory for the THREADINFO is allocated by the kernel in version 4.0, the required size having been communicated by WIN32K as an argument to the undocumented (and highly variable) PsEstablishWin32Callouts function. The first 0x20 bytes of the THREADINFO get copied from the kernel’s service descriptor table. The remainder is zero-initialised, to be completed by WIN32K. It is not known how service descriptor table entries are represented in Microsoft’s definitions. Version 5.0 redistributed the work, such that the THREADINFO is instead created by WIN32K and the service descriptor tables stay with the kernel.

<unknown-type> ServiceDescriptorTable [2];

ETHREAD *Thread;

ETHREAD *pEThread;

CLIENT_ID RealClientId;

PVOID GdiCachedProcessHandle;

ULONG RefCount;

TL *ptlW32;

PVOID pgdiDcattr;

PVOID pgdiBrushAttr;

PVOID pUMPDObjs;

LIST_ENTRY UMPDOBJList;

PVOID pUMPDHeap;

ULONG dwEngAcquireCount;

PVOID pSemTable;

PVOID DxThread;

PVOID pUMPDObj;

PVOID pProxyPort;

PVOID pClientID;

PVOID DxThread;

LIST_ENTRY GdiTmpAllocList;

LIST_ENTRY GdiTmpTgoList;

ULONG pRBRecursionCount;

ULONG pNonRBRecursionCount;

TLSPRITESTATE tlSpriteState;

PVOID pSpriteState;

PVOID pDevHTInfo;

ULONG ulDevHTInfoUniqueness;

PVOID pdcoAA;

PVOID pdcoRender;

PVOID pdcoSrc;

BOOLEAN bEnableEngUpdateDeviceSurface;

BOOLEAN bIncludeSprites;

BOOLEAN bEnableAppContainerRendering;

ULONG ulWindowSystemRendering;

ULONG iVisRgnUniqueness;

ULONGLONG RefCountInc;

ULONGLONG RefCountDec;

PVOID pUmfdTls;

THREADINFO Continuation

For the rest of the THREADINFO, type information is known in public symbol files for version 6.1 only. Microsoft’s names for some members in versions 3.51 to 5.0 inclusive are known from the output of debugger commands. Most noticeable is the !dti command. More notable for versions 4.0 and 5.0 is the !dso command as supported by the USERKDX.DLL debugger extensions for these versions. Still, structural details of the THREADINFO are more than usually scarce among public sources. For almost all Windows versions, the tables from here are necessarily the result of deduction, inference and outright guesswork from inspection of executables. Near the end of the structure, this becomes true even of version 6.1 despite Microsoft’s disclosure of type information.

THROBJHEAD head;

LIST_ENTRY PtiLink;

TL *ptl;

TL *ptlOb;

TL *ptlPool;

INT cEnterCount;

Version 3.10 has at offset 0x14 a handle to a per-thread event that may correspond in later versions to the per-process InputIdleEvent.

PROCESSINFO *ppi;

Q *pq;

KL *spklActive;

MLIST mlPost;

USHORT fsChangeBitsRemoved;

USHORT cDeskClient;

CLIENTTHREADINFO *pcti;

CLIENTTHREADINFO cti;

HANDLE hEventQueueClient;

HANDLE hEventQueueServer;

KEVENT *pEventQueueServer;

ULONG fsChangeBits;

ULONG fsChangeBitsRemovd;

ULONG fsWakeBits;

ULONG fsWakeMask;

The spelling fsChangeBitsRemovd is Microsoft’s, specifically from the USEREXTS debugger extension from the DDK for Windows NT 3.51. This is as good a moment as any to remind that the text for a debugger extension’s description of a member does not necessarily reproduce the member’s name from whatever header has the member’s source-code definition.

KEVENT **apEvent;

DESKTOP *spdesk;

DESKTOP *rpdesk;

DESKTOPINFO *pDeskInfo;

HDESK hdesk;

ACCESS_MASK amdesk;

DESKTOPINFO *pDeskInfo;

ULONG_PTR ulClientDelta;

CLIENTINFO *pClientInfo;

ULONG TIF_flags;

DWORD idProcessClient;

DWORD idThreadClient;

DWORD idSequenceClient;

PWSTR pstrAppName;

UNICODE_STRING *pstrAppName;

ULONG fsHooks;

HOOK *asphkStart [0x0D];

HOOK *sphkCurrent;

SMS *psmsSent;

SMS *psmsCurrent;

SMS *psmsReceiveList;

LONG_PTR ExtraInfo;

LONG timeLast;

POINT ptLast;

ULONG_PTR idLast;

INT cQuit;

INT exitCode;

HDESK hdesk;

INT cPaintsReady;

UINT cTimersReady;

MENUSTATE *pMenuState;

<unknown-type> SBState;

union {
    TDB *ptdb;
    WINDOWSTATION *pwinsta;
    DESKTOP *pdeskClient;
};

union {
    TDB *ptdb;
    WINDOWSTATION *pwinsta;
};

SVR_INSTANCE_INFO *psiiList;

DWORD dwExpWinVer;

DWORD dwManifestWinVer;

union {
    DWORD dwCompatFlags;
    struct {
        /* bit fields, follow link */
    };
};

union {
    DWORD dwCompatFlags2;
    struct {
        /* bit fields, follow link */
    };
};

union {
    DWORD dwCompatFlags2;
    ULONGLONG qwCompatFlags2;
    struct {
        /* bit fields, follow link */
    };
};

UINT cWindows;

UINT cVisWindows;

ULONG hTaskWow;

HANDLE hThreadClient;

HANDLE hThreadServer;

<unknown-type> *pcsrt;

TEB *pteb;

Q *pqAttach;

INT iCursorLevel;

INT cSpins;

ULONG fsReserveKeys;

THREADINFO *ptiSibling;

MOVESIZEDATA *pmsd;

WOWTHREADINFO *pwti;

ULONG fsHooks;

HOOK *asphkStart [0x0E];

HOOK *asphkStart [0x10];

HOOK *sphkCurrent;

LPARAM lParamHkCurrent;

WPARAM wParamHkCurrent;

SBTRACK *pSBTrack;

The unknown LIST_ENTRY elaborates psmsReceiveList from single-linked to double-linked. It seems likely that Microsoft changed the name, but to what is unknown. The unknown dword that follows counts the SMS structures in the list.

A thread has a ptdb or a pwinsta according to whether its TIF_16BIT (0x00000002) bit is set or clear in the TIF_flags.

The name dwManifestWinVer is proposed as a reasonable guess in the style of what it follows. The member is set by a routine that symbol files show to be named SetManifestWinVer. 

There is, of course, one element in the aphkStart array for each possible hook, as set through the API function SetWindowsHookEx. The hooks are documented and it is well known that the numbering is not zero-based but instead starts at -1 (WH_MSGFILTER). Notwithstanding that a conditional block in Microsoft’s WINUSER.H would have it that WH_KEYBOARD_LL (0x0D) and WH_MOUSE_LL (0x0E) are defined for version 4.0 and higher, they are in fact rejected by the WIN32K.SYS from the original release of Windows NT 4.0. Indeed, look back through Microsoft’s documentation, even as recently as the Software Development Kit (SDK) for Windows 7, and it can be found that the low-level keyboard and mouse hooks require “version 4.0 SP3 or later.”

Appended for Windows 2000

Most members that appear at the end of the THREADINFO in version 5.0 weren’t so much appended as just moved from earlier in the structure, in no particular order for no reason that I yet understand.

PVOID hEventQueueClient;

KEVENT *pEventQueueServer;

LIST_ENTRY PtiLink;

INT iCursorLevel;

POINT ptLast;

POINT ptLastReal;

WND *spwndDefaultIme;

IMC *spDefaultImc;

HKL hklPrev;

INT cEnterCount;

MLIST mlPost;

USHORT fsChangeBitsRemoved;

WCHAR wchInjected;

ULONG fsReserveKeys;

KEVENT **apEvent;

ACCESS_MASK amdesk;

UINT cWindows;

UINT cVisWindows;

HOOK *aphkStart [0x10];

CLIENTTHREADINFO cti;

It is immediately after the cti member that offsets in type information from symbol files for Windows 7 start to go wrong. These symbol files have the CLIENTTHREADINFO as 0x10 bytes in both 32-bit and 64-bit Windows, but for the structure as actually used by WIN32K this size has not been correct since Windows XP added a dword. How the symbol files get built with only a partial CLIENTTHREADINFO is not known. The consequence for the next few THREADINFO members is that offsets that are read mechanically from the Windows 7 symbol files, e.g., for presentation on the Internet as supposedly worthwhile research, are off by four or eight bytes in 32-bit and 64-bit Windows respectively.

Appended Mostly For Windows 7

PVOID hPrevHidData;

HTOUCHINPUT hTouchInputCurrent;

HGESTUREINFO hGestureInfoCurrent;

MSGPPINFO MsgPPInfo;

UINT cNestedStableVisRgn;

LIST_ENTRY readyHead;

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

Microsoft’s name THREADINPUTINFOLIST (formally tagTHREADINPUTINFOLIST) for the structure that first appears in version 6.2 at offsets 0x020C and 0x03B0 is known from symbol files, specifically from the names of routines that are written in C++ and take the structure’s address among their arguments. The structure begins with a LIST_ENTRY that links structures whose name is similarly known to be THREADPOINTERDATA (formally tagTHREADPOINTERDATA). Microsoft’s names for these structures’ members are not known.

The MsgPPInfo member is accessed as eight bytes in both 32-bit and 64-bit Windows, yet symbol files for Windows 7 have the MSGPPINFO structure as four bytes in both 32-bit and 64-bit Windows. It is here supposed that the symbol files must be wrong about the MSGPPINFO structure, the alternative being that they’re wrong even about the existence of a MsgPPInfo member (there being no other space for it).

The structure that first appears in version 6.0 at offsets 0x0158 and 0x0280 is operated on by routines that symbol files name as AddUpdateHangInfo, DestroyUpdateHangInfo, etc, and since symbol files for Windows 8.1 (but not Windows 8 or Windows 10) have C++ decorations for these routines Microsoft’s name for the structure is nowadays known to be INPUTHANGINFO (formally tagINPUTHANGINFO). The structure in the THREADINFO itself is the head of a list. The head is for the thread itself. Others are for the thread’s windows. This is where the timeout for hung applications is tested—and it is hard-coded to 5 seconds in version 6.0. Microsoft’s names for the THREADINFO member or for the INPUTHANGINFO members are not known. How the member gets missed in the type information from the symbol files for Windows 7 is not known. Note especially that it cannot be that the symbol files as published are somehow out of date: this INPUTHANGINFO was no last-minute addition during development of Windows 7 but has existed since Windows Vista.

Before version 6.1, timers for all threads go into one list. Version 6.1 has a global list too but improves on it by putting each timer into both the global list and the new per-thread list. The name readyHead from the suspect symbol files is consistent with the cTimersReady counter that is the whole per-thread tracking of timers in earlier versions.

Appended for Windows 8

Microsoft’s names for members that have been added to the THREADINFO since Windows 7 may never be known. On the plus side, if only for neatness of presentation, new members have mostly been added simply by appending. 

MSGPPINFO MsgPPInfo;

The unknown LIST_ENTRY is presumed to remain defined for version 10.0 though its use seems to have been discontinued.

Appended for Windows 8.1

Appended for Windows 10