ESILO

The ESILO (formally _ESILO) arguably has the highest profile of all kernel-mode structures for which no type information was ever disclosed in public symbol files. Note the past tense: the ESILO is known only in the original Windows 10.

The Silo Object

The high profile is that the ESILO truly is an object in the sense of being managed by the Object Manager such that it can be exposed through a HANDLE with access rights. Indeed, this apparently seemed important enough at the time that the access rights are defined in WINNT.H for user-mode programming:

These definitions even persist to the WINNT.H for the 1511 release, by which time there is no silo object that can be created, opened, closed or otherwise accessed through a handle.

Even for the original release of Windows 10, the silo object’s existence was precarious. Notably, it is subordinate to the job object (represented by the EJOB structure). The only known way to create a silo object is through the JobObjectCreateSilo information class (0x23) of the NtSetInformationJobObject function. There is no input or output for this information class. It just creates a silo for the given job object to hold as its Container, not because the silo in any sense contains the job but because setting a silo object into a job object is the way that Microsoft elevates the long-standing job object from managing a collection of processes into acting like what the rest of the world had for some time been calling a container.

For some suggestion that the silo object was already on the way out even for the original Windows 10, see that the corresponding WINNT.H also defines a SILOOBJECTINFOCLASS, as if to fit the pattern of an information class to pass to native API functions that allow for querying and setting properties of the silo object. Historians who care to look may find that such functions, perhaps named something like NtQueryInformationSiloObject, exist in pre-release builds of Windows 10. What shows in the actual release is that no native API functions work with silo objects and the information classes that WINNT.H defines for SILOBOJECTINFOCLASS are already all folded into the long-standing JOBOBJECTINFOCLASS.

Layout

The ESILO is 0x98 or 0x0110 bytes in 32-bit and 64-bit Windows 10, respectively.

HANDLE SiloIdNumber;

ESILO *ParentSilo;

ULONG NumberOfChildSilos;

ULONG NumberOfProcesses;

ESERVERSILO_GLOBALS *ServerSiloGlobals;

For a few members, names and types are proposed above by inferring a correspondence with members of other structures for which Microsoft’s names and types are known with certainty. Notably, when the SILOOBJECT_BASIC_INFORMATION structure (defined in WINNT.H) is filled as output for the JobObjectSiloBasicInformation case of NtQueryInformationJobObject, the SiloIdNumber, NumberOfChildSilos and NumberOfProcesses are copied directly from the ESILO and it’s at least plausible that Microsoft’s programmers use the same names and types on both sides of the equals signs. Confidence can of course not be high. For some caution see that although HANDLE is natural for the silo identifier since it is allocated from a handle table, the SYSTEM_ROOT_SILO_INFORMATION that is the output from the SystemRootSiloInformation case of ZwQuerySystemInformation gets the identifier as a ULONG_PTR.