MI_VISIBLE_STATE

The MI_VISIBLE_STATE structure is known only as the type of the Vs member of the MI_SYSTEM_INFORMATION, which is in turn the type of the internal kernel variable MiState in Windows 10.

As a collection of what earlier versions had as separately named internal variables, the MI_VISIBLE_STATE is highly susceptible to changing between builds.

These sizes and the names and types in the table below are from type information in the public symbol files for the kernel.

MI_SPECIAL_POOL SpecialPool;

LIST_ENTRY SessionWsList;

RTL_BITMAP *SessionIdBitmap;

MM_PAGED_POOL_INFO PagedPoolInfo;

ULONG_PTR MaximumNonPagedPoolInPages;

ULONG_PTR SizeOfPagedPoolInPages;

MI_SYSTEM_PTE_TYPE SystemPteInfo;

ULONG_PTR volatile NonPagedPoolCommit;

ULONG_PTR volatile SmallNonPagedPtesCommit;

ULONG_PTR volatile BootCommit;

ULONG_PTR volatile MdlPagesAllocated;

ULONG_PTR volatile SystemPageTableCommit;

ULONG_PTR volatile SpecialPagesInUse;

ULONG_PTR volatile WsOverheadPages;

ULONG_PTR volatile VadBitmapPages;

ULONG_PTR volatile ProcessCommit;

ULONG_PTR volatile SharedCommit;

LONG volatile DriverCommit;

UCHAR PagingLevels;

ULONG_PTR PfnDatabaseCommit;

MMSUPPORT SystemWs [3];

MMSUPPORT_FULL SystemWs [3];

MMSUPPORT_FULL SystemWs [6];

MMSUPPORT_SHARED SystemCacheShared;

MMSUPPORT_AGGREGATION AggregateSystemWs [1];

MMWSL_SHARED SystemCacheSharedWorkingSetList;

ULONG MapCacheFailures;

ULONG LastUnloadedDriver;

UNLOADED_DRIVERS *UnloadedDrivers;

ULONG_PTR PagefileHashPages;

SYSPTES_HEADER PteHeader;

MI_SPECIAL_POOL *SessionSpecialPool;

ULONG_PTR SystemVaTypeCount [MiVaMaximumType];

UCHAR SystemVaType [0x0400];

UCHAR SystemVaType [0x0100];

ULONG SystemVaTypeCountFailures [MiVaMaximumType];

ULONG SystemVaTypeCountLimit [MiVaMaximumType];

ULONG SystemVaTypeCountPeak [MiVaMaximumType];

ULONG SystemAvailableVa;

MI_SYSTEM_VA_ASSIGNMENT SystemVaRegions [AssignedRegionMaximum];

The SystemVaTypeCount member is originally the internal variable MiSystemVaTypeCount, dating from Windows Vista. The several similar arrays of counters in the 32-bit builds correspond similarly to internal variables that date from Windows Vista SP1. All are indexed by the MI_SYSTEM_VA_TYPE enumeration. Note that the number of elements varies with the build.

The MI_SYSTEM_VA_TYPE enumeration also figures in the SystemVaType member. This too, in the 32-bit builds, dates from Windows Vista as an internal variable. Its elements evaluate to the enumeration. Given a virtual address in system space, this SystemVaType array thus provides for ready reckoning of the address’s type. The index for the lookup is in 2MB units from the start of system space, 2MB being the amount of virtual address space that’s mapped through one page directory entry (given the use of PAE). That there are 0x0400 elements allows system space to start as low as 0x80000000.

The SystemAvailableVa member also originates as an internal variable in Windows Vista. It tracks how many bytes of system address space are not yet assigned, but only for 32-bit Windows. In 64-bit Windows, perhaps just for the convenience that comes from having much more address space to work with, different types of addresses in system address space are assigned to different regions whose bases and sizes are hard-coded. This predictability was scrapped for the 1607 release of Windows 10, apparently in a continuing programme of strengthening kernel-mode Address Space Layout Randomisation (ASLR). A new classification of address-space regions is modelled by the MI_ASSIGNED_REGION_TYPES enumeration, which indexes the new SystemVaRegions array. Again, the number of elements varies with the build. The values give the dynamically assigned base addresses and sizes of these regions of system space. The variability complicates the lookup of the other address-space type. The 1703 release eases this by introducing the SystemVaType member to 64-bit Windows. The index for the lookup is in units of 512GB from the start of system space at 0xFFFF8000`00000000, 512GB being the amount of virtual address space that’s mapped through one PML4 entry.