SYSTEM_INFORMATION_CLASS

The SYSTEM_INFORMATION_CLASS is an enumeration whose values are intended as input to the ZwQuerySystemInformation, ZwQuerySystemInformationEx and ZwSetSystemInformation functions. Different values select different types of information to query or set.

Documentation Status

Microsoft has kept SYSTEM_INFORMATION_CLASS remarkably private. Analogues for information about files, processes, threads, and much else, have all their supported values defined in header files from as far back as the Device Driver Kit (DDK) for Windows NT 3.51. Even as late as the Windows Driver Kit (WDK) for Windows 10, however, SYSTEM_INFORMATION_CLASS has no C-language definition in any WDK header.

The closest that Microsoft has come to formal disclosure of the SYSTEM_INFORMATION_CLASS enumeration is some plainly reluctant documentation of NtQuerySystemInformation and a C-language definition of the enumeration in the WINTERNL.H file from the Software Development Kit (SDK) for user-mode programming. This header 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 Internet Explorer. Better late than never, it might be argued, except that neither the documentation’s listing nor the header’s definition of SYSTEM_INFORMATION_CLASS is anywhere near complete. Perhaps Microsoft felt compelled to disclose only the cases that Microsoft found its middleware using, but whatever the reason, the disclosure was not so much partial as greatly reduced—from approximately two hundred to just nine, increased to 10 in the SDK for Windows 8.1, and to 12 for the documentation online as found today, 28th October 2016, but dating from who knows when.

Microsoft’s names for all the SYSTEM_INFORMATION_CLASS values have slipped out, of course. As usual when it comes to Microsoft’s names for otherwise undocumented material, they’re knowable from type information in symbol files. Not at all usual is which symbol files: not for the kernel, where the enumeration is interpreted and the relevant functions are implemented; nor even for NTDLL or other such low-level user-mode modules that call the functions as their system-level support of the documented Win32 API; but for various higher-level user-mode DLLs that are far enough away from the system that they ought, if only in principle, not need any functionality that isn’t documented for everyone.

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 for Windows 8 through to Windows 10 before the 1803 release show that it is built not with the reduced SYSTEM_INFORMATION_CLASS 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, URLMON evidently is built now with more system-level knowledge of 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 what Microsoft has got away with on this. (I say this as criticism of the government and courts very much more than of Microsoft.)

For no known reason, the public symbol files for URLMON in the 1803 release have no type information at all, but SYSTEM_INFORMATION_CLASS continues to be disclosed in other symbol files, e.g., for OLE32.DLL.

Much further back, it turns out that type information for the SYSTEM_INFORMATION_CLASS was disclosed in statically linked libraries that Microsoft distributed with early DDKs: a GDISRVL.LIB in the DDK for Windows NT 3.51; and SHELL32.LIB in the DDK for Windows NT 4.0. That the latter is otherwise just an import library for SHELL32.DLL suggests strongly that these disclosures were one-off oversights. Still, published they were.

Enumeration

Of the very 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. For Windows 8 and higher, the type information in symbol files is surely definitive. The import libraries for versions 3.51 and 4.0 are here taken as definitive also. What names are defined for other versions is something of a guess. Explanations of some editorial decisions follow the table.

Note that some information classes were introduced or changed in service-pack releases. The following shorthands are used below:

• late 5.0 starts with Windows 2000 SP4;
• late 5.1 starts with Windows XP SP2;
• very late 5.1 starts with Windows XP SP3;
• late 5.2 starts with Windows Server 2003 SP1;
• late 6.0 starts with Windows Vista SP1;
• late 6.1 starts with Windows 7 SP1.

Though SystemCallTimeInformation (0x0A) is shown above as original, it is invalid in version 3.10 and plausibly was not yet named or had some other name to mark it explicitly as spare. Version 3.50 changes it from invalid to not implemented, i.e., so that it returns STATUS_NOT_IMPLEMENTED instead of STATUS_INVALID_INFO_CLASS, which is how it remains even now. This is here taken to mean that if it was not yet defined for version 3.10 then it was for 3.50. That information classes can be defined even when invalid is established by SystemVdmBopInformation (0x14), which appears in type information both old and new even though the information class is invalid in all known versions.

On the other hand, type information for version 3.51 establishes that Microsoft did have a naming scheme to indicate explicitly that an invalid information class is spare. The numbering in the known names SystemSpare3Information (0x19) and SystemSpare6Information (0x1D) of information classes that were still invalid in version 3.51 is naturally explained by hypothesising SystemSpare1Information (0x17), SystemSpare2Information (0x18), SystemSpare4Information (0x1A) and SystemSpare5Information (0x1B) for nearby information classes that have non-trivial implementations (and meaningful names) in version 3.51 but are invalid in version 3.50.

Exactly when SystemNextEventIdInformation (0x1E) and SystemEventIdsInformation (0x1F) got new names is unclear. The information classes are explicitly not implemented in versions 3.50 to 4.0, but the names are certain from type information for versions 3.51 and 4.0. In version 5.0 both information classes become invalid. Both are soon reassigned, with implementations that are consistent with names known from later type information, but did they retain their old names while invalid?

Contrast with SystemCrashDumpInformation (0x20) which never has been reassigned since it was made invalid in version 5.1. It is known to have been renamed to SystemObsolete0 in time for version 6.2, but exactly when is not known.

The spelling of SystemPrioritySeperation (0x27) is Microsoft’s.

Though both SystemPlugPlayBusInformation (0x28) and SystemDockInformation (0x29) are explicitly not implemented in versions 3.51 and 4.0, their names are known from type information. They then become invalid until version 5.1 finds new use. What they were named meanwhile is not known. Similar considerations apply to SystemPowerInformation (0x2A) except that this information class is invalid even in the versions 3.51 and 4.0 for which the name is known. It is still invalid in version 5.0, and so the name is thought to have persisted.

The information class SystemSessionInformation (0x31) is another that is invalid in all known versions. Its known name for version 6.2 and higher is here thought to be contemporaneous with the nearby information classes that also deal with sessions.

Information classes 0x36 and 0x37 are valid in the version 5.0 from Windows 2000 SP4 but their implementations do not match the names that are known from later type information. They do instead match the later SystemObjectSecurityMode (0x46) and the trivially successful information class 0x47 as implemented in the version 5.1 from Windows XP SP2. It is here thought that the additions for Windows XP SP2 were appended to the Windows 2000 enumeration when back-fitting to the roughly contemporaneous Windows 2000 service pack.

Information class 0x42 cannot be SystemBigPoolInformation before version 5.2. It becomes valid in the version 5.1 from Windows XP SP2 but as an alias for SystemObjectSecurityMode (0x46).

The change of name for case 0x86 is what’s shown in the symbol files. The implementation in version 6.2 is consistent with SystemPolicyInformation in subsequent versions. The original name, SystemThrottleNotificationInformation, at best remains from some other use that was dropped during development.

It is not known when Microsoft started ending the enumeration with MaxSystemInfoClass. The name is established in the type information for version 6.2 and higher but is absent from type information for versions 3.51 and 4.0.