THREADINFOCLASS

The THREADINFOCLASS is an enumeration whose values are intended as input to the ZwQueryInformationThread and ZwSetInformationThread functions. Different values select different types of information to query or set.

Documentation Status

A C-language definition of the THREADINFOCLASS enumeration has been publicly available in the NTDDK.H header since at least the Device Driver Kit (DDK) for Windows NT 3.51. It there supported the declaration of the ZwSetInformationThread function which is exported from both the kernel and NTDLL in version 3.10 and higher but was not formally documented even for kernel-mode programming until some time after the Windows Driver Kit (WDK) for Windows 7 in 2009. Such kernel-mode documentation as exists of either function presents only a handful of the defined values. In the WDK for Windows 10, even the definition in NTDDK.H has become selective.

Microsoft’s first formal documentation of either THREADINFOCLASS or of any function that uses it was in the Software Development Kit (SDK) for user-mode programming. A WINTERNL.H file was added to the SDK in 2002, apparently for Microsoft’s compliance with a settlement concerning unfair use of internal Windows APIs by “middleware” products such as, but in no way limited to, Internet Explorer. The file presents a greatly reduced C-language definition, just of the ThreadIsIoPending case, which contemporaneous documentation of the NtQueryInformationThread function quite rightly noted would better be accessed via the documented API function GetThreadPendingIoFlag. This documentation later added ThreadQuerySetWin32StartAddress to its description, though apparently without this case ever making it to the definition in the header.

As for the values that are added for Windows 10 but which the definition in the contemporaneous WDK skips, these are knowable from type information in symbol files. The surprise, however, is which symbol files—not for the kernel, where the enumeration is interpreted and the relevant functions are implemented, nor even NTDLL, but for various higher-level user-mode DLLs. The most conspicuous is URLMON.DLL, for it is a component of Internet Explorer, i.e., of the most prominent “middleware” that compelled even the grudgingly partial disclosure in 2002. The symbol files that have been publicly available for URLMON since 2012 show that it is built not with the reduced THREADINFOCLASS from WINTERNL.H but with the whole thing. However URLMON was built in the years when Microsoft’s compliance with the settlement was reviewed by—it might be hoped—competent regulators, it is now built with more knowledge of low-level Windows than Microsoft publishes even for kernel-mode device driver programmers. Do not tell me that there was not at Microsoft somewhere some time someone who enjoyed mocking the government and courts over this. (I say this as criticism of the latter very much more than of Microsoft.)

Enumeration

Of the many defined cases, some can be used successfully only to query or only to set. Some can’t usefully be called either way—at least, not in all versions. The present purpose however is not to show which values are implemented non-trivially in which versions, but which values are defined in which versions, as much as can be known.