Win32 Thread Information Block

{{Short description|Data structure in Microsoft Windows programming}}

{{update|date=December 2013}}

The Thread Information Block (TIB) or Thread Environment Block (TEB) is a data structure in Win32 on x86 that stores information about the currently running thread. It descended from, and is backward-compatible on 32-bit systems with, a similar structure in OS/2.

The TIB is officially undocumented for Windows 9x. The Windows NT series DDK (as well as the MinGW/ReactOS implementation) includes a struct NT_TIB in winnt.h that documents the subsystem independent part. Even before TIB was effectively documented, many applications have already started using its fields that they are effectively a part of the API. The first field containing the SEH frame, in particular, is directly referenced by the code produced by Microsoft's own compiler. The Win32 subsystem-specific part of the TEB is undocumented, but Wine includes a TEB definition in winternl.h.{{cite web |title=wine winternl.h: typedef struct _TEB |url=https://github.com/wine-mirror/wine/blob/1aff1e6a370ee8c0213a0fd4b220d121da8527aa/include/winternl.h#L347 |website=GitHub |publisher=wine-mirror |date=29 October 2019}}

The TIB can be used to get a lot of information on the process without calling Win32 API. Examples include emulating GetLastError(), GetVersion(). Through the pointer to the PEB one can obtain access to the import tables (IAT), process startup arguments, image name, etc. It is accessed from the FS segment register on 32-bit Windows and GS on 64-bit Windows.

Contents of the TIB on Windows

This table is based on Wine's work on Microsoft Windows internals.

class="wikitable"

! width="20px" | Bytes/
Type

! style="width: 64pt;" | offset (32-bit, FS)

! style="width: 64pt;" | offset (64-bit, GS)

! width="40px"| Windows Versions

! Description

align="right" |pointer

|FS:[0x00]

|GS:[0x00]

|Win9x and NT

|Current Structured Exception Handling (SEH) frame

Note: the 64-bit version of Windows uses stack unwinding done in kernel mode instead.

align="right" |pointer

|FS:[0x04]

|GS:[0x08]

|Win9x and NT

|Stack Base / Bottom of stack (high address)

align="right" |pointer

|FS:[0x08]

|GS:[0x10]

|Win9x and NT

|Stack Limit / Ceiling of stack (low address)

align="right" |pointer

|FS:[0x0C]

|GS:[0x18]

|NT

|SubSystemTib

align="right" |pointer

|FS:[0x10]

|GS:[0x20]

|NT

|Fiber data

align="right" |pointer

|FS:[0x14]

|GS:[0x28]

|Win9x and NT

|Arbitrary data slot

align="right" |pointer

|FS:[0x18]

|GS:[0x30]

|Win9x and NT

|Linear address of TEB

colspan="5" | End of NT subsystem independent part; below are Win32-dependent
align="right" |pointer

|FS:[0x1C]

|GS:[0x38]

|NT

|Environment Pointer

align="right" |pointer

|FS:[0x20]

|GS:[0x40]

|NT

|Process ID (in some Windows distributions this field is used as DebugContext)

align="right" |pointer

|FS:[0x24]

|GS:[0x48]

|NT

|Current thread ID

align="right" |pointer

|FS:[0x28]

|GS:[0x50]

|NT

|Active RPC Handle

align="right" |pointer

|FS:[0x2C]

|GS:[0x58]

|Win9x and NT

|Linear address of the thread-local storage array

align="right" |pointer

|FS:[0x30]

|GS:[0x60]

|NT

|Linear address of Process Environment Block (PEB)

align="right" |4

|FS:[0x34]

|GS:[0x68]

|NT

|Last error number

align="right" |4

|FS:[0x38]

|GS:[0x6C]

|NT

|Count of owned critical sections

align="right" |pointer

|FS:[0x3C]

|GS:[0x70]

|NT

|Address of CSR Client Thread

align="right" |pointer

|FS:[0x40]

|GS:[0x78]

|NT

|Win32 Thread Information

align="right" |124

|FS:[0x44]

|GS:[0x80]

|NT, Wine

|Win32 client information (NT), user32 private data (Wine), 0x60 = LastError (Win95&98), 0x74 = LastError (WinME)

align="right" |pointer

|FS:[0xC0]

|GS:[0x100]

|NT

|Reserved for Wow64. Contains a pointer to FastSysCall in Wow64.

align="right" |4

|FS:[0xC4]

|GS:[0x108]

|NT

|Current Locale

align="right" |4

|FS:[0xC8]

|GS:[0x10C]

|NT

|FP Software Status Register

align="right" |216

|FS:[0xCC]

|GS:[0x110]

|NT, Wine

|Reserved for OS (NT), kernel32 private data (Wine)
herein: FS:[0x124] 4 NT Pointer to KTHREAD (ETHREAD) structure

align="right" |4

|FS:[0x1A4]

|GS:[0x2C0]

|NT

|Exception code

align="right" |18

|FS:[0x1A8]

|GS:[0x2C8]

|NT

|Activation context stack

align="right" |24

|FS:[0x1BC]

|GS:[0x2E8]

|NT, Wine

|Spare bytes (NT), ntdll private data (Wine)

align="right" |40

|FS:[0x1D4]

|GS:[0x300]

|NT, Wine

|Reserved for OS (NT), ntdll private data (Wine)

align="right" |1248

|FS:[0x1FC]

|GS:[0x350]

|NT, Wine

|GDI TEB Batch (OS), vm86 private data (Wine)

align="right" |4

|FS:[0x6DC]

|GS:[0x838]

|NT

|GDI Region

align="right" |4

|FS:[0x6E0]

|GS:[0x840]

|NT

|GDI Pen

align="right" |4

|FS:[0x6E4]

|GS:[0x848]

|NT

|GDI Brush

align="right" |4

|FS:[0x6E8]

|GS:[0x850]

|NT

|Real Process ID

align="right" |4

|FS:[0x6EC]

|GS:[0x858]

|NT

|Real Thread ID

align="right" |4

|FS:[0x6F0]

|GS:[0x860]

|NT

|GDI cached process handle

align="right" |4

|FS:[0x6F4]

|GS:[0x868]

|NT

|GDI client process ID (PID)

align="right" |4

|FS:[0x6F8]

|GS:[0x86C]

|NT

|GDI client thread ID (TID)

align="right" |4

|FS:[0x6FC]

|GS:[0x870]

|NT

|GDI thread locale information

align="right" |20

|FS:[0x700]

|GS:[0x878]

|NT

|Reserved for user application

align="right" |1248

|FS:[0x714]

|GS:[0x890]

|NT

|Reserved for GL (See wine ref for internals)

align="right" |4

|FS:[0xBF4]

|GS:[0x1250]

|NT

|Last Status Value

align="right" |532

|FS:[0xBF8]

|GS:[0x1258]

|NT

|Static UNICODE_STRING buffer

align="right" |pointer

|FS:[0xE0C]

|GS:[0x1478]

|NT

|Also known as DeallocationStack, it establishes the actual start address of the stack buffer, which defines the true stack limit. This limit is a few pages less than the stack limit field, as the latter includes the guard pages used to manage the growth of the stack. {{cite web | url=https://devblogs.microsoft.com/oldnewthing/20220203-00/?p=106215 | title=A closer look at the stack guard page | date=3 February 2022 }}

align="right" |pointer[]

|FS:[0xE10]

|GS:[0x1480]

|NT

|TLS slots, 4/8 bytes per slot, 64 slots

align="right" |8

|FS:[0xF10]

|GS:[0x1680]

|NT

|TLS links (LIST_ENTRY structure)

align="right" |4

|FS:[0xF18]

|GS:[0x1690]

|NT

|VDM

align="right" |4

|FS:[0xF1C]

|GS:[0x1698]

|NT

|Reserved for RPC

align="right" |4

|FS:[0xF28]

|GS:[0x16B0]

|NT

|Thread error mode (RtlSetThreadErrorMode)

align="right" |4

|FS:[0xF78]

|GS:[0x1748]

|NT

|Guaranteed stack bytes

colspan="5" | This is not the full table; see wine ref for all fields until FS:[0xfb4] / GS:[17c8]. Newer Windows versions extend the size of TIB further, up to 0x1000/0x1838 in Windows 10. Some of the fields appended are removed, leading to conflicting definitions.{{cite web |last1=Chapell |first1=Geoff |title=TEB |url=https://www.geoffchappell.com/studies/windows/win32/ntdll/structs/teb/index.htm}}

FS (for 32-bit) or GS (for 64-bit) maps to a TIB which is embedded in a data block known as the TDB (thread data base). The TIB contains the thread-specific exception handling chain and pointer to the TLS (thread local storage.) The thread local storage is not the same as C local storage.

Stack information stored in the TIB

A process should be free to move the stack of its threads as long as it updates the information stored in the TIB accordingly. A few fields are key to this matter: stack base, stack limit, deallocation stack, and guaranteed stack bytes, respectively stored at offsets 0x8, 0x10, 0x1478 and 0x1748 in 64 bits. Different Windows kernel functions read and write these values, specially to distinguish stack overflows from other read/write page faults (a read or write to a page guarded among the stack limits in guaranteed stack bytes will generate a stack-overflow exception instead of an access violation). The deallocation stack is important because Windows API allows to change the amount of guarded pages: the function SetThreadStackGuarantee allows both read the current space and to grow it. In order to read it, it reads the GuaranteedStackBytes field, and to grow it, it uses has to uncommit stack pages. Setting stack limits without setting DeallocationStack will probably cause odd behavior in SetThreadStackGuarantee. For example, it will overwrite the stack limits to wrong values. Different libraries call SetThreadStackGuarantee, for example the .NET CLR uses it for setting up the stack of their threads.

Accessing the TIB

The TIB of the current thread can be accessed as an offset of segment register FS (x86) or GS (x64).

It is not common to access the TIB fields by an offset from FS:[0], but rather first getting a linear self-referencing pointer to it stored at FS:[18h]. That pointer can be used with pointer arithmetic or be cast to a struct pointer.

Using Microsoft Windows SDK or similar, a programmer could use an inline function defined in winnt.h named NtCurrentTeb which returns the address of the current Thread Information Block as NT_TIB *.{{cite web |title=NtCurrentTeb function |url=https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-ntcurrentteb |website=Microsoft Docs |accessdate=20 November 2019}}

Alternative methods of access for IA-32 architectures are as follows:

// gcc (AT&T-style inline assembly).

void *getTIB(void) {

register void *pTIB;

  1. if defined(__x86_64__) || defined(__amd64__)

__asm__("movq %%gs:0x30, %0" : "=r" (pTIB));

  1. elif defined(__i386__)

__asm__("movl %%fs:0x18, %0" : "=r" (pTIB));

  1. else
  2. error unsupported architecture
  3. endif

return pTIB;

}

// gcc (named address spaces, same as the inline assembly version on -O1 or -ftree-ter).

void *getTIB(void) {

  1. if defined(__x86_64__) || defined(__amd64__)
  2. ifndef __SEG_GS
  3. error unsupported GCC version
  4. endif

return *(void *__seg_gs *) 0x30;

  1. elif defined(__i386__)
  2. ifndef __SEG_FS
  3. error unsupported GCC version
  4. endif

return *(void *__seg_fs *) 0x18;

  1. else
  2. error unsupported architecture
  3. endif

}

// Microsoft C

__declspec(naked)

void *getTIB() {

__asm mov EAX, FS:[18h]

__asm ret

}

// Using Microsoft's intrinsics instead of inline assembly (works for both X86 and X64 architectures)

void *getTIB() {

  1. ifdef _M_IX86

return (void *)__readfsdword(0x18);

  1. elif _M_AMD64

return (void *)__readgsqword(0x30);

  1. else
  2. error unsupported architecture
  3. endif

}

See also

References

{{reflist|refs=

{{cite journal

| title = Under The Hood

| journal = Microsoft Systems Journal

| date = May 1996

| first = Matt

| last = Pietrek

| author-link=Matt Pietrek

| url = http://www.microsoft.com/msj/archive/s2ce.aspx

| accessdate = 2010-07-07

| url-status=dead|archivedate=2009-06-14|archiveurl=https://web.archive.org/web/20090614054226/http://www.microsoft.com/msj/archive/s2ce.aspx

}}

}}

Further reading

  • {{cite book|url=https://archive.org/details/windows95systemp00matt/page/136|title=Windows 95 Programming Secrets|author-last=Pietrek|author-first=Matt|author-link=Matt Pietrek|date=March 1996|publisher=IDG|isbn=978-1-56884-318-6|pages=[https://archive.org/details/windows95systemp00matt/page/136 136–138]|format=pdf|accessdate=2010-07-17|url-access=registration}}