SYSTEM_PROCESS_INFORMATION

The SYSTEM_PROCESS_INFORMATION structure is what a successful call to ZwQuerySystemInformation or NtQuerySystemInformation produces at the start of its output buffer and irregularly throughout the buffer when given the information class SystemProcessInformation (0x05), SystemExtendedProcessInformation (0x39) or SystemFullProcessInformation (0x94).

These information classes produce descriptions not just of the running processes but also of those processes’ threads. A quick summary is that the information for each process is:

• a SYSTEM_PROCESS_INFORMATION:
• an array of SYSTEM_THREAD_INFORMATION or SYSTEM_EXTENDED_THREAD_INFORMATION structures, one per thread;
• a SYSTEM_PROCESS_INFORMATION_EXTENSION;
• and variable-size data, notably the process’s name, indicated by members of the preceding structures.

The totality of the output for all processes is a sequence of these variable-size sets, one per process. In each set, the NextEntryOffset member at the beginning of the SYSTEM_PROCESS_INFORMATION tells how many bytes to advance from that SYSTEM_PROCESS_INFORMATION to the next, or is zero in the last.

Documentation Status

The SYSTEM_PROCESS_INFORMATION structure is defined in WINTERNL.H from the Software Development Kit (SDK). The definition there is greatly reduced, defining just the NextEntryOffset, UniqueProcessId, HandleCount, PeakPagefileUsage and PrivatePageCount members. Documentation of NtQuerySystemInformation describes the SystemProcessInformation case as returning “an array of SYSTEM_PROCESS_INFORMATION structures, one for each process running in the system”, with no mention of what information lies in between. Separate documentation of ZwQuerySystemInformation presents a SYSTEM_PROCESS_INFORMATION that differs slightly from the WINTERNL.H definition in showing the NumberOfThreads member too, again without noting the connection with information between the “documented” structures.

Microsoft does publish the practical equivalent of a C-language definition as type information in public symbol files, though not for the kernel, where the structure is prepared, nor even for low-level user-mode DLLs that interpret the structure, but for various higher-level user-mode DLLs such as URLMON.DLL and only then starting with version 6.2.

Two earlier disclosures of type information are known, though not in symbol files but in statically linked libraries: GDISRVL.LIB from the Device Driver Kit (DDK) for Windows NT 3.51; and SHELL32.LIB from the DDK for Windows NT 4.0.

Layout

Since version 5.0, the SYSTEM_PROCESS_INFORMATION is 0xB8 or 0x0100 bytes in 32-bit and 64-bit Windows, respectively. The original structure is 0x88 bytes. The change can ultimately be traced to a problem that early versions had with the I/O counters. Though version 3.10 provided for 64-bit counts of bytes transferred, it allowed only 32 bits for counting operations. The need to widen the latter to 64 bits each seems to have caused them all to be dropped for several versions. It is not just that they are not retrievable in this structure (or through the ProcessIoCounters case of NtQueryInformationProcess), but that the kernel stops maintaining them. When they were brought back for version 5.0, all now 64-bit, they were appended. Not until version 6.1 is the space that had been occupied by the 32-bit counts fully reassigned.

ULONG NextEntryOffset;

ULONG NumberOfThreads;

LARGE_INTEGER ReadTransferCount;

LARGE_INTEGER SpareLi1;

LARGE_INTEGER WorkingSetPrivateSize;

LARGE_INTEGER WriteTransferCount;

LARGE_INTEGER SpareLi2;

ULONG HardFaultCount;

ULONG NumberOfThreadsHighWatermark;

LARGE_INTEGER OtherTransferCount;

LARGE_INTEGER SpareLi3;

ULONGLONG CycleTime;

LARGE_INTEGER CreateTime;

LARGE_INTEGER UserTime;

LARGE_INTEGER KernelTime;

UNICODE_STRING ImageName;

LONG BasePriority;

PVOID UniqueProcessId;

PVOID InheritedFromUniqueProcessId;

ULONG ReadOperationCount;

ULONG SpareUl1;

ULONG HandleCount;

ULONG WriteOperationCount;

ULONG SpareUl2;

ULONG SessionId;

ULONG OtherOperationCount;

ULONG SpareUl3;

ULONG_PTR UniqueProcessKey;

ULONG_PTR PeakVirtualSize;

ULONG_PTR VirtualSize;

ULONG PageFaultCount;

ULONG_PTR PeakWorkingSetSize;

ULONG_PTR WorkingSetSize;

ULONG_PTR QuotaPeakPagedPoolUsage;

ULONG_PTR QuotaPagedPoolUsage;

ULONG_PTR QuotaPeakNonPagedPoolUsage;

ULONG_PTR QuotaNonPagedPoolUsage;

ULONG_PTR PagefileUsage;

ULONG_PTR PeakPagefileUsage;

ULONG_PTR PrivatePageCount;

LARGE_INTEGER ReadOperationCount;

LARGE_INTEGER WriteOperationCount;

LARGE_INTEGER OtherOperationCount;

LARGE_INTEGER ReadTransferCount;

LARGE_INTEGER WriteTransferCount;

LARGE_INTEGER OtherTransferCount;

The name SpareUl1 is an invention. Microsoft’s names SpareUl2 and SpareUl3 for the other 32-bit counts that were discontinued for version 3.50 survive in the GDISRVL.LIB for version 3.51 but the first in the sequence had already been ressigned as the HandleCount.

Whatever may be suggested to the contrary by its name, the PrivatePageCount is of bytes, just like the other counters whose names talk of size or usage.

Variable-Size Data

Some of the SYSTEM_PROCESS_INFORMATION members are specially important for describing the variable-size data that continues the process’s description.

Immediately following the SYSTEM_PROCESS_INFORMATION is an array of zero or more SYSTEM_THREAD_INFORMATION structures if the information class is SystemProcessInformation, else SYSTEM_EXTENDED_THREAD_INFORMATION structures. Either way, the NumberOfThreads member tells how many.

The process’s name may be present as a null-terminated Unicode string. Its address and size are in the ImageName member. This is the full name if the information class is SystemFullProcessInformation. For the older information classes, this name is an extract, beginning after the last backslash.

Information Class Variations

The UniqueProcessKey is undefined for SystemProcessInformation. For the newer information classes it originally revealed the page number of the process’s page directory base. Version 6.0 instead reveals the address of the EPROCESS structure that represents the process as a kernel object. Whether the member was named UniqueProcessKey in these versions is not known. Whatever it was named, what it contained may have been thought to disclose too much: since version 6.1 the UniqueProcessKey is set identically to the UniqueProcessId.