Memory integrity and VBS enablement
Memory integrity is a virtualization-based security (VBS) feature available in Windows 10, Windows 11, and Windows Server 2016 or higher. Memory integrity and VBS improve the threat model of Windows and provide stronger protections against malware trying to exploit the Windows kernel. VBS uses the Windows hypervisor to create an isolated virtual environment that becomes the root of trust of the OS that assumes the kernel can be compromised. Memory integrity is a critical component that protects and hardens Windows by running kernel mode code integrity within the isolated virtual environment of VBS. Memory integrity also restricts kernel memory allocations that could be used to compromise the system, ensuring that kernel memory pages are only made executable after passing code integrity checks inside the secure runtime environment, and executable pages themselves are never writable.
Memory integrity is sometimes referred to as hypervisor-protected code integrity (HVCI) or hypervisor enforced code integrity, and was originally released as part of Device Guard. Device Guard is no longer used except to locate memory integrity and VBS settings in Group Policy or the Windows registry.
See Virtualization Based Security System Resource Protections for more details on these protections.
Memory integrity is turned on by default on clean installs of Windows 11, and previously only on clean installs of Windows 10 in S mode, on compatible hardware as described in this article. It's also turned on by default on all Secured-core PCs. On other systems that don't meet the memory integrity auto-enablement requirements, customers can opt in using any of the methods described in how to enable memory integrity. IT Pros and end users always have the final control of whether memory integrity is enabled.
Hardware features for automatic enablement
Memory integrity is turned on by default when a PC meets the following minimum hardware features:
|RAM||Minimum 8GB (Only applicable for x64 processors)|
|Storage||SSD with a minimum size of 64GB|
|Drivers||Memory integrity-compatible drivers must be installed. See Driver compatibility with memory integrity for more information about drivers.|
|BIOS||Virtualization must be enabled|
If you're building an image that won't automatically enable memory integrity, you can still configure your image so that it's turned on by default.
Auto-enablement pertains only to clean installs, not upgrades of existing devices.
The China and Korea markets are excluded, to avoid known compatibility issues with software prevalent in those geographies.
Intel 11th generation Core desktop processors are not included in current default enablement logic. However, they are a recommended platform for memory integrity and it can be enabled by the OEM.
Memory integrity and VBS controls
This section enumerates how device manufacturers and end users can interact with memory integrity and VBS. To learn about how to control memory integrity state as an administrator, see How to turn on memory integrity.
Turn on memory integrity
Although Windows will turn memory integrity on by default for most systems, there are several reasons that may prevent that from happening. As an OEM, you can ensure that memory integrity is turned on for your devices by configuring registry keys in the OS image.
Set the following two registry keys in your image to ensure memory integrity is turned on.
The BootId is a counter that increments on each successful boot and can be found at the registry key: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters\BootId The WasEnabledBy and EnabledBootId registry keys control a setting that safeguards against having an unbootable device. When set, the device will automatically turn off memory integrity if the system crashes during boot, potentially caused by memory integrity blocking an incompatible boot-critical driver. This auto-disablement feature is only available while BootId is less than EnabledBootId + 3. In some versions of Windows, the auto-disable functionality is designed to revert if the boot failures continue even after memory integrity was turned off, indicating that memory integrity was not the root cause of the failures.
For high security systems, WasEnabledBy and EnabledBootId should NOT be set.
Identifying memory integrity state
The following volatile regkey reflects the state of memory integrity:
Other ways of checking memory integrity state are to look at MsInfo32 under Virtualization-based Security Services Running or refer to the Core isolation settings page in the Windows Security app to see the value of Memory integrity. There is also a WMI interface for checking using management tools, see Validate enabled VBS and memory integrity features.
Debugging Driver Issues
Check the Code Integrity logs to see if any drivers were blocked from loading as a result of memory integrity. These are in Event Viewer under the following path:
Applications and Service Logs\Microsoft\Windows\CodeIntegrity\Operational
Generally, memory integrity compatibility events have EventID=3087
Check results of memory integrity default enablement
To see details on the results of memory integrity default enablement, check the setupact.log and search for
HVCI. You should see one of the following result logs, as well as the succeeding/failing checks leading to the enablement decision:
Memory integrity enabled:
SYSPRP HVCI: Enabling HVCI
Memory integrity not enabled:
SYSPRP HVCI: OS does not meet HVCI auto-enablement requirements. Exiting now.
If the device was opted out of memory integrity enablement via the regkey method detailed earlier, then this will be the only log from memory integrity's sysprep. If the device had a compatibility issue, it should be identified in the preceding logs with the error message:
SYSPRP HVCI: Compatibility did not pass. VBS_COMPAT_ISSUES 0xXXXXXXXX
The following is an enumeration of the potential VBS or memory integrity Compat Issues. Each issue is represented by a single index in a bit array, and the error message outputs the hex value resulting from each error bit being present.
|Bit Index||Compat Issue||Hex Value||Architecture|
|0||Unsupported architecture (eg. x86)||0x00000001|
|2||Secure Boot capability required||0x00000004||x64|
|6||UEFI WX Memory Attributes Table required||0x00000040||x64|
|7||ACPI WSMT table required||0x00000080||x64|
|8||UEFI MOR Lock required||0x00000100||x64|
|10||Hardware virtualization required||0x00000400||x64|
|11||Secure Launch required||0x00000800||ARM64|
|13||Device failing to meet 64GB minimum required volume size||0x00002000||x64, ARM64|
|14||System drive SSD required||0x00004000||x64, ARM64|
|15||Intel CET Required (Only applicable on W11 21H2)||0x00008000||x64|
|16||ARM SoC is not compatible with VBS||0x00010000||ARM64|
|17||8GB RAM required||0x00020000||x64|
An example of an error code and error identification:
0x000000C0 -> 0x00000080 AND 0x00000040 -> UEFI WX Memory Attributes Table required, ACPI WSMT table required