PROCESSINFO

The PROCESSINFO (formally tagPROCESSINFO) is the most of what WIN32K.SYS keeps about a process. A portion at its start is reproduced as a W32PROCESS (formally _W32PROCESS), apparently as an unnamed member. It is not clear what governs the separation.

Documentation Status

Under either name, the PROCESSINFO is not documented. Structural details from type information in symbol files are known to have been disclosed in public only for WIN32K.SYS from Windows 7—not before and not since. Or so I wrote in 2017, having not yet caught up with Windows 10 updates. Symbol files for 1607 and higher have type information for the W32PROCESS. Thus does a little more “official” detail dribble out.

For some early WIndows versions, 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 PROCESSINFO may help programmers in the depths of debugging what they’re doing with Windows!

Layout

Not only is the PROCESSINFO highly variable between versions, and not only is there the complication of what part of it is the W32PROCESS, but in the one version for which type information is publicly available it’s immediately plain that the PROCESSINFO as described therein is not the full story. The memory block it is created in is larger than is declared for the structure and the additional space is accessed as if for members of a larger structure. It could be that the PROCESSINFO is itself a reduction, but close inspection shows something more interesting: the PROCESSINFO as described by type information in the symbol file for WIN32K in Windows 7 is not the PROCESSINFO 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.

In version 4.0, memory for the PROCESSINFO is allocated by the kernel, the required size having been communicated by WIN32K as an argument to the undocumented (and highly variable) PsEstablishWin32Callouts function. Version 5.0 redistributed the work, such that the PROCESSINFO is instead created by WIN32K. Either way, the size of the PROCESSINFO is easily seen in code—indeed, in Windows 10, with WIN32K split into three, it’s immediately visible in data, exported as W32ProcessSize—but how much of the PROCESSINFO is the W32PROCESS can only be guessed.

W32PROCESS

Even for the first part of the PROCESSINFO, Microsoft’s names and types are known with the certainty of type information from public symbol files only for version 6.1 and now for some releases of version 10.0. For versions 4.0 and 5.0, offsets and Microsoft’s names, but not types, are known with good confidence from the output of the debugger’s !dso command as supported by the USEREXTS.DLL debugger extensions for these versions. For almost all Windows versions, everything that’s presented here of the layout is necessarily the result of deduction, inference and outright guesswork from inspection of executables.

Strictly speaking, it’s also a guess that the W32PROCESS does not exist as a separate structure before version 4.0. In this version—before which the PROCESSINFO was a user-mode creation of WINSRV.DLL—three members that had been very nearly at the end at the PROCESSINFO move to very near the start, which is here taken as a reorganisation that defined the W32PROCESS. Conspicuous among these moved members is the dword of flags. Compare with similar flags in the THREADINFO which didn’t move to the W32THREAD.

EPROCESS *Process;

ULONG RefCount;

ULONG W32PF_Flags;

KEVENT *InputIdleEvent;

ULONG StartCursorHideTime;

W32PROCESS *NextStart;

PVOID pDCAttrList;

PVOID pBrushAttrList;

ULONG W32Pid;

<unknown-type> pidHandleTrack;

LONG GDIHandleCount;

ULONG GDIHandleCountPeak;

LONG UserHandleCount;

ULONG UserHandleCountPeak;

EX_PUSH_LOCK GDIPushLock;

RTL_AVL_TABLE GDIEngUserMemAllocTable;

LIST_ENTRY GDIDcAttrFreeList;

LIST_ENTRY GDIBrushAttrFreeList;

LIST_ENTRY GDIW32PIDLockedBitmaps;

PVOID hSecureGdiSharedHandleTable;

PVOID DxProcess;

PVOID DCompositionProcess;

ULONG UMPDSandboxingEnabled;

PVOID pWakeReference;

ULONG defaultDpiContext;

USHORT Dpi;

BOOL bChangedGdiGammaRamp;

UINT GdiInitializeCalloutExecuted : 1;

The InputIdleEvent is, of course, what the documented API function WaitForInputIdle waits on. As a kernel-mode structure, the PROCESSINFO can have pointers directly to such things as event objects—and ideally would, since access through handles for kernel-mode use alone is wholly avoidable overhead. In the early history, however, the InputIdleEvent is necessarily a HANDLE. See below, as hEventInputIdle, the different name being suggested by the output of the Windows NT 3.51 debugger’s !dpi command. Version 3.51 introduced some logic with special meaning for INVALID_HANDLE_VALUE as distinct from NULL, which is retained even after the change to a pointer and is remarkable for persisting even to Windows 10.

The W32Pid in version 4.0 is just the low 16 bits of the usual process ID. Later versions save a ULONG but explicitly clear the lowest two bits.

Version 4.0 does track a GDIHandleCount at offset 0x24 but apparently in some structure (0x10 bytes at offset 0x20) that I have little interest in investigating. There is only so much trouble I can care to take for the pre-history!

PROCESSINFO Continuation

For the PROCESSINFO beyond the W32PROCESS, Microsoft’s names and types are known with the certainty of type information from public symbol files only for version 6.1. 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 USERKDX debugger extensions for these versions. For version 3.51, the output of the !dpi command as supported by the USEREXTS debugger extension suggests names that very likely are Microsoft’s.

PROCESSINFO *ppiNext;

DWORD idProcessClient;

DWORD idSequence;

HANDLE hEventInputIdle;

THREADINFO *ptiList;

THREADINFO *ptiMainThread;

UINT cThreads;

DESKTOP *spdeskStartup;

DESKTOP *rpdeskStartup;

HDESK hdeskStartup;

CLS *pclsPrivateList;

CLS *pclsPublicList;

WOWPROCESSINFO *pwpi;

PROCESSINFO *ppiNext;

PROCESSINFO *ppiNextRunning;

UINT cThreads;

HDESK hdeskStartup;

UINT cSysExpunge;

DWORD dwhmodLibLoadedMask;

PVOID ahmodLibLoaded [0x20];

INT cObjects;

<unknown-type> pOpenObjectTable;

WINDOWSTATION *spwinsta;

WINDOWSTATION *rpwinsta;

HWINSTA hwinsta;

ACCESS_MASK amwinsta;

USERSTARTUPINFO usi;

DWORD PIF_flags;

DWORD dwCompatFlags;

ULONG timeStartCursorOverride;

DWORD dwHotkey;

<unknown-type> pCsrProcess;

The name PIF_flags is hypothesised by analogy with TIF_flags in the THREADINFO. The USEREXTS debugger extension for Windows NT 3.51 has just “flags” but this seems more likely to be intended for easier presentation rather than for faithfully reproducing the member’s name. Note in particular that the names that this same debugger extension gives for the defined bits each begin with PIF.

The name dwCompatFlags is confirrmed by the USERKDX debugger extension for Windows NT 4.0. The dword is a copy of the dwCompatFlags that are also computed for the THREADINFO and CLIENTINFO. Keeping them in the PROCESSINFO too seems to have been dropped after version 4.0.

Appended for Windows NT 3.51

W32PROCESS *ppiCalcNext;

WOWPROCESSINFO *pwpi;

THREADINFO *ptiList;

<unknown-type> pcurList;

LUID luidSession;

Appended for Windows NT 4.0

HMONITOR hMonitor;

DESKTOPVIEW *pdvList;

UINT iClipSerialNumber;

RTL_BITMAP bmDesktopHookFlags;

RTL_BITMAP bmHandleFlags;

CURSOR *pCursorCache;

That the PROCESSINFO as early as version 4.0 has an RTL_BITMAP where the Windows 7 symbol files locate bmHandleFlags is certain, but it is not clear that handle flags existed before version 5.0, at least not with the generality of later versions. The version 4.0 WIN32K operates on this bitmap not through such routines as SetHandleFlag but SetDesktopHookFlag. The USERKDX debugger extensions for WIndows NT 4.0 and Windows 2000 confirm that the difference also showed in the bitmap’s name.

Appended for Windows 2000

PVOID pClientBase;

DWORD dwLpkEntryPoints;

W32JOB *pW32Job;

DWORD dwImeCompatFlags;

LUID luidSession;

USERSTARTUPINFO usi;

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

ULONG dwLayout;

The USERKDX debugger extension from the DDK for Windows 2000 does not list dwLayout among the PROCESSINFO members and would have it that the structure is 0x0138 bytes, not 0x013C. It is here thought that the DDK somehow retained a debugger extension for a pre-release build, but it may be that the inspected WIN32K executable is not truly from the original release.

Appended for Windows XP and Windows Server 2003

PROCESS_HID_TABLE *pHidTable;

The four bytes at offset 0x0140 in version 5.1 are bit flags. The bit masked by 0x00000001 is set to disable ghosting. Version 5.2 moved it to the bit masked by 0x08000000 in the W32PF_Flags.

Appended for Windows Vista

DWORD dwRegisteredClasses;

Appended for Windows 7

VWPL *pvwplWndGCList;

Type information in the WIN32K symbol files from version 6.1—which, remember, is all that Microsoft has disclosed in public—has the PROCESSINFO ending with pvwplWndGCList at offsets 0x01AC and 0x02F8. These offsets are simply not plausible for this member. For instance, where a routine that the symbol files name as GetWindowGCList calls another named VWPLGetData, it very plainly takes the pointer from offset 0x01BC. As if this were not trouble enough, there is evidently a second such pointer. For instance, a routine named GetWindowMessageFilter also calls VWPLGetData but taking the pointer from offset 0x01B4.

The unknown word is bit flags. The unknown dword that follows it is perhaps named ProcessCheckSum. It is set by an internal routine that the symbol files—yes, the ones that omit the member from the structure—name as WndLimit_GetProcessCheckSum.. It receives the checksum from the process’s Portable Executable (PE) header. Both seem to have existed only for Windows 7.

Appended for Windows 8

Microsoft’s names for members that have been added to the PROCESSINFO since Windows 7 may never be known.

Appended for Windows 10

UINT cVisWindows;

Many consecutive members that are new for Windows 10 support the trace logging event named AppUsageAndDisplayInfoOnExit. It is not known whether they are defined as a nested structure. Names given in italics are those of the parameters for the trace-logging event, except that in 1511 and higher what’s shown as the ProcessImageName is instead hard-coded as ATTRI_DEPRECATED.

The name cVisWindows is proposed with some confidence since it acts as a per-process counter in tandem with the very much older per-thread counter for which Microsoft’s name in version 6.1 is known with the certainty of type information from symbol files.