Memory Integrity will not turn on: finding the incompatible driver, and what the vulnerable driver blocklist actually blocks

You flip the Memory Integrity switch in Windows Security. The toggle slides to On. You reboot. The toggle is back to Off, and a small grey line says something about an incompatible driver. Sometimes it names a driver. Very often it names nothing at all, or it shows an empty list under a heading that promises one.

This is the single most valuable hardening switch in Windows 11, and it is also the one that fails most quietly. This post explains what Memory Integrity actually is, what it actually prevents, the exact requirements a driver has to meet, and how to find the offending .sys by name and full path. It then covers the Microsoft vulnerable driver blocklist, which is a completely different mechanism that almost everybody conflates with Memory Integrity, and how to prove the blocklist is on.

The problem: the toggle reverts and names nothing useful

Here is the shape of the failure, in the order a helpdesk usually sees it.

1. A user or a policy turns on Memory Integrity.
2. Windows asks for a restart, because the feature can only start at boot.
3. After the restart the toggle is Off again.
4. Windows Security shows a message about an incompatible driver, and often an empty list.

There are three separate reasons that message is so unhelpful, and it is worth separating them before you go hunting.

First, the driver scan in the Windows Security user interface is a best-effort static check. It looks at driver files it can find and reason about. A driver that only misbehaves at runtime, when a particular code path executes, will pass that static check and still break the feature.

Second, some drivers load so early in boot that nothing has a chance to log the block. Microsoft states this outright: if an incompatibility exists for a boot-critical driver, Memory Integrity is silently turned off if it had been auto-enabled. Silently. No dialog, no event you can rely on.

Third, there is a deliberate safety net that looks identical to a failure. Windows can auto-disable Memory Integrity if the machine crashes during boot shortly after it was turned on. That behaviour is driven by two registry values, and it is doing exactly what it was designed to do when it reverts your change.

And then there is the confusion that sends people down the wrong road entirely. The Windows Security page that hosts the Memory Integrity toggle also hosts a toggle called Microsoft Vulnerable Driver Blocklist. They sit next to each other under Core isolation. They are not the same thing, they fail in different ways, and a fix for one does nothing for the other. We will pull them apart properly.

Why it happens: what HVCI is and what it enforces

The chain, from power-on to enforcement

Normally, kernel-mode code integrity is a function inside the Windows kernel. It checks every driver and kernel binary before it starts, and refuses to load anything unsigned or untrusted. The problem is obvious once you say it out loud. If an attacker compromises the kernel, they have compromised the thing doing the checking.

VBS changes that arrangement. Here is the order of events.

1. The Windows boot loader loads hvloader.dll, which selects and starts the hypervisor image for the platform.
2. The hypervisor creates an isolated virtual environment that becomes the root of trust for the operating system. Microsoft's framing is explicit: this environment assumes the kernel can be compromised.
3. A second kernel, the secure kernel, starts inside that isolated environment.
4. When Memory Integrity is on, code integrity decisions move into that secure environment. Kernel memory pages are only made executable after passing code integrity checks inside the secure runtime environment.
5. From then on, executable pages are never writable.

That last sentence is the whole feature. Say it as a rule: kernel memory can be writable, or it can be executable, but never both at the same time. That is why the acronym W+X (write plus execute) keeps coming up.

Microsoft lists two headline protections for Memory Integrity. It protects modification of the Control Flow Guard (CFG) bitmap for kernel mode drivers. And it protects the kernel mode code integrity process itself, the process that ensures other trusted kernel processes have a valid certificate. Practically, that means a buffer overflow that lets malware scribble on memory still cannot turn that memory into running code.

The requirements a driver has to meet

Compatibility with Memory Integrity has been a requirement for all drivers since the Windows 10 Anniversary Update, version 1607. That is a decade of notice. Plenty of shipping drivers still fail. Microsoft's documented rules for building a compatible driver are short and blunt.

• Opt in to NX by default. NX means no-execute, a page attribute that forbids running code from that memory.
• Use NX APIs and flags for memory allocation, specifically NonPagedPoolNx.
• Do not use sections that are both writable and executable.
• Do not attempt to directly modify executable system memory.
• Do not use dynamic code in the kernel.
• Do not load data files as executable.
• Section alignment must be a multiple of 0x1000, which is PAGE_SIZE. For example DRIVER_ALIGNMENT=0x1000.

When a driver fails, it fails in one of a documented set of ways. Microsoft publishes the failure categories that Driver Verifier and the HLK test report. Knowing them helps you write a useful bug report to the vendor instead of "your driver breaks HVCI".

The hardware and firmware prerequisites, including the TPM question

VBS has a documented component list. Every item has to be present and correctly configured.

Separately from those platform requirements, Windows has an auto-enablement bar. Memory Integrity is turned on by default on clean installs of Windows 11 on hardware that meets a specific minimum, and on all Secured-core PCs.

Two footnotes on that table matter enormously in an enterprise fleet. Auto-enablement pertains only to clean installs, not upgrades of existing devices. And Intel 11th generation Core desktop processors are not included in the current default enablement logic, even though Microsoft calls them a recommended platform. So a fleet that was upgraded in place rather than reimaged will mostly have Memory Integrity off, and that is by design, not a bug.

The blocklist is a different mechanism entirely

Now the part people conflate. The Microsoft vulnerable driver blocklist does not care about W+X pages or section alignment. It is a deny list of specific third-party drivers, by signature, that Microsoft has determined are dangerous.

Microsoft's stated criteria for adding a driver are:

• Known security vulnerabilities an attacker could exploit to elevate privileges in the Windows kernel.
• Malicious behaviours, or certificates used to sign malware.
• Behaviours that are not malicious but circumvent the Windows security model in a way an attacker could exploit to elevate privileges in the kernel.

The two features overlap in exactly one place, and it is worth being precise. Since the Windows 11 2022 update the blocklist is enabled by default for all devices, and can be turned on or off in the Windows Security app. Except on Windows Server 2016, the blocklist is also enforced when Memory Integrity, Smart App Control or S mode is active. So turning on Memory Integrity brings the blocklist with it, but the blocklist stands on its own and does not need Memory Integrity.

Delivery is not what most people assume either. The blocklist is updated quarterly, and blocklist updates are also delivered through the monthly Windows updates as part of the standard servicing process. It ships as part of Windows and Defender servicing, not as a thing you have to go and fetch. There is a downloadable version, and Microsoft is unusually candid about why it exists: the downloadable list usually contains a more complete set of known vulnerable drivers than the version in the operating system, because Microsoft holds back some blocks to avoid breaking existing functionality while partners get users onto patched versions.

How to verify: WMI, registry, Event Viewer, setupact.log

This section is the part you will come back to. Work through it in order, because each surface answers a different question, and reading them out of order is how people conclude the wrong thing.

1. Win32_DeviceGuard: the documented source of truth

Windows exposes a WMI class for VBS state. It is the only supported programmatic surface for this, and it is what you should build reporting on. The command below reads it. Run it from an elevated PowerShell session, because Microsoft documents it as an elevated query.

Read that output as follows. SecurityServicesConfigured is what policy asked for. SecurityServicesRunning is what actually came up. A value present in the first list and absent from the second is the whole diagnosis in one line: you asked for it, the platform refused.

Here are the documented enumerations you need to interpret it, so you are not guessing at integers.

For a quick eyeball check with no PowerShell, msinfo32.exe from an elevated session shows the VBS features at the bottom of the System Summary section. Look for the line "Virtualization-based security Services Running" and check that it reports "Hypervisor enforced Code Integrity".

2. The registry: policy intent versus live state

There are two completely different kinds of registry data here, and mixing them up is the most common analysis error in this feature area. One set records what you asked for. One records what actually happened. Read both.

Everything in the first group hangs off this parent key:

Those WasEnabledBy and EnabledBootId values deserve their own paragraph, because they explain a failure that looks like sabotage. Together they arm a safeguard against an unbootable device. When set, the device will automatically turn off Memory Integrity if the system crashes during boot, which may well have been caused by Memory Integrity blocking an incompatible boot-critical driver. That auto-disable only applies while the current BootId is less than EnabledBootId plus 3. The current boot counter lives here:

Microsoft's guidance for high security systems is that WasEnabledBy and EnabledBootId should NOT be set. That is a real trade-off. Leave them and a crashing driver silently wins. Remove them and a bad driver leaves you booting into recovery.

The second group is state, not intent. These are the values that tell you what is actually true right now.

There is a third registry location, and forgetting it wastes hours. Group Policy and ADMX-backed Intune settings do not write to CurrentControlSet. They write here:

If you hand-edit the CurrentControlSet copy on a managed device, the next policy refresh overwrites you. Check for values under SOFTWARE\Policies before you conclude that anything you set by hand has stuck.

Here is what the scenario key looks like in Registry Editor on a working machine.

3. Event Viewer: the channel that names the file

Microsoft's troubleshooting guidance for driver issues is explicit about where to look. Check the code integrity logs to see if any drivers were blocked from loading as a result of Memory Integrity. That channel is:

Every event ID below is documented by Microsoft for that channel. The ones marked with a dagger are the ones that will name a file you can chase.

Here is what a filtered view looks like when a driver is genuinely being refused.

That is an illustrative panel using a fictional driver name, not a capture from a real device. The real capture is in the Proof section further down.

Now the query. This pulls the blame events and reads their messages, which is where the driver path lives.

4. The log file: setupact.log and the VBS_COMPAT_ISSUES bitmask

There is one more surface, and it is the one almost nobody checks. When Windows decides at install time whether to auto-enable Memory Integrity, it writes the decision and its reasoning to the setup log. Full path:

Search that file for the string HVCI. Microsoft documents three result lines you can find.

That bitmask is genuinely useful, because it tells you which prerequisite failed rather than making you guess. Each issue is a single bit.

Microsoft's own worked example: VBS_COMPAT_ISSUES 0x000000C0 decomposes into 0x00000080 plus 0x00000040, which is "ACPI WSMT table required" plus "UEFI WX Memory Attributes Table required". Both of those are firmware problems, so the fix is a BIOS update from the OEM, not anything you can do in Windows.

5. System files and binaries in the flow

It helps to know which files are actually doing the work, both for understanding and for support calls. The table below lists what is present on a running Windows 11 device, verified on the machine used for this post. Microsoft documents the feature rather than publishing a role-by-role reference for each binary, so the role column is described from behaviour and should be read as explanation, not as a Microsoft-sourced contract.

6. Services and scheduled tasks: honestly, there are none

This is worth stating plainly, because people go looking. There is no Windows service that runs Memory Integrity, and no scheduled task under \Microsoft\Windows\... that drives it. The hypervisor and the secure kernel are boot-loaded components, started by the boot loader before the service control manager exists. You cannot restart them, and there is nothing to set to Automatic.

Two services are adjacent but not causal. SecurityHealthService, display name Windows Security Service, renders the Core isolation page you clicked; if that page misbehaves, that service is the one to look at, and it has nothing to do with whether HVCI starts. HvHost, display name HV Host Service, exists on machines with Hyper-V components. Do not treat either as a health signal for Memory Integrity. The authoritative state is Win32_DeviceGuard, full stop.

The fix: find the driver, then enable through policy

Step 1: enumerate what is actually loaded

Once an event names a driver you are nearly done. When it does not, you need a candidate list. Both commands below list loaded drivers with their file paths, so you can cross-reference against vendor updates.

Microsoft names the categories where it has observed incompatibilities, and the list is a good place to start guessing: anti-cheat solutions with gaming, third-party input methods, and third-party banking password protection. In an enterprise fleet, add VPN clients, legacy storage filter drivers, virtual audio devices and older backup agents.

Step 2: confirm the driver, do not guess

If you have a lab machine and a suspect driver, Driver Verifier will tell you definitively. There is a Code Integrity option flag, 0x02000000, that enables extra checks validating compliance with Memory Integrity.

The documented syntax is verifier.exe /flags 0x02000000 /driver <driver.sys>. In the Verifier GUI, choose "Create custom settings (for code developers)", then Next, then "Code integrity checks". On success there is no output at all. A failure looks like a Verifier assertion naming the exact violation, for example "The caller specified an executable page protection 0x40", which maps to the Execute Page Protection row in the failure table earlier.

There is also a supported tool for inspecting the platform rather than the driver. The Windows SDK ships SkTool.exe in its bin folder, typically under a path like C:\Program Files (x86)\Windows Kits\10\bin\10.0.26100.0\x64. Run with no switches it displays the current state of the hypervisor and VBS, including the reason VBS has or has not started. /status shows hypervisor and secure kernel information, /mitigations shows NT and secure kernel mitigations, and /lkey shows VSM master key provisioning status, which is the switch you want when Windows Hello stops accepting a PIN after a security posture change.

Step 3: fix the driver

There are only three real outcomes, and it is worth being honest about them with whoever is asking.

1. Update it. Microsoft's first troubleshooting step: if a device driver fails to load or crashes at runtime, you might be able to update the driver using Device Manager. Check the vendor's site for a build newer than the one on the device. Compatibility has been required since 1607, so a current build usually complies.
2. Remove it. If the hardware or software is retired, uninstall it. This is the most common resolution in practice for old agents nobody owns any more.
3. Escalate it. If the vendor's newest build still fails, send them the Driver Verifier output and the failure category name. "Your driver fails HVCI with an Execute-Write Section violation" gets a real answer. "Memory Integrity won't turn on" does not.

If a device has already been made unstable, Microsoft documents the recovery path: disable any policies used to enable VBS and Memory Integrity, boot the affected computer into the Windows Recovery Environment, and set HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity value Enabled to 0, then restart. If Memory Integrity was turned on with UEFI lock, you must disable Secure Boot in firmware to complete those steps, which means physical access to the machine.

Step 4: enable it properly, through Group Policy

Once the drivers are clean, turn the feature on through policy rather than by hand. The Group Policy path is:

The full click-through, as an ordered list:

1. Open Group Policy Editor with gpedit.msc, or open the GPO you want in the Group Policy Management Console.
2. Navigate to Computer Configuration > Administrative Templates > System > Device Guard.
3. Double-click Turn On Virtualization Based Security.
4. Select Enabled.
5. Under Virtualization Based Protection of Code Integrity, select Enabled without UEFI lock. Only choose Enabled with UEFI lock if you specifically want to prevent Memory Integrity being turned off remotely or by policy update.
6. Under Select Platform Security Level, choose Secure Boot in most situations. Choosing Secure Boot and DMA Protection means machines without an IOMMU get no VBS at all.
7. Select OK to close the editor.
8. On a domain-joined computer, restart or run gpupdate /force from an elevated Command Prompt.
9. Restart the device. The feature can only start at boot.

The setting is backed by DeviceGuard.admx and writes to HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard. That is worth knowing, because it means you can confirm the policy arrived by reading the registry, before you even reboot.

Step 5: the same setting from Intune

For cloud-managed devices, use the settings catalog. Microsoft's documented route is the Virtualization Based Technology > Hypervisor Enforced Code Integrity setting.

1. Sign in to the Microsoft Intune admin center at intune.microsoft.com.
2. Go to Devices > Configuration.
3. Select Create > New Policy.
4. Platform: Windows 10 and later. Profile type: Settings catalog. Select Create.
5. Give the profile a name, for example W11-Baseline-MemoryIntegrity. Select Next.
6. Select Add settings.
7. In the settings picker, browse to or search for the category Virtualization Based Technology.
8. Tick Hypervisor Enforced Code Integrity. Close the picker.
9. Set the value. Enabled without lock is the value to start with. Enabled with UEFI lock is the hardened option. Disabled turns it off remotely, but only if it was configured previously without UEFI lock.
10. Optionally add Require UEFI Memory Attributes Table if you want to refuse VBS on firmware that does not report a compliant MAT.
11. Select Next, add scope tags if you use them, then assign to a pilot group first. Never assign this to All Devices on day one.
12. Select Next, review, and Create.

If you prefer a custom profile or you are on a different MDM, the CSP node is documented. The OMA-URI is:

Format is int. Scope is Device only, not User. Applicable from Windows 11 version 21H2, build 10.0.22000, on Pro, Enterprise, Education and IoT Enterprise. The related node ./Device/Vendor/MSFT/Policy/Config/VirtualizationBasedTechnology/RequireUEFIMemoryAttributesTable takes 0 or 1.

There is a third route worth knowing. App Control for Business policy can turn Memory Integrity on: through the App Control Wizard's Hypervisor-protected Code Integrity option on the Policy Rules page, through the Set-HVCIOptions PowerShell cmdlet, or by editing the <HVCIOptions> element in the policy XML. One trap there: if your App Control policy is set to turn Memory Integrity on, it will be turned on even if the policy is in audit mode.

Step 6: the blocklist, verified and deployed

The blocklist needs its own handling because it is a separate control with a separate verification path.

To check the in-box blocklist, the supported route is the Windows Security app:

To deploy and verify the more complete downloadable version, Microsoft's documented procedure is:

1. Download the App Control policy refresh tool from aka.ms/refreshpolicy.
2. Download and extract the vulnerable driver blocklist binaries from aka.ms/VulnerableDriverBlockList.
3. Select either the audit-only version or the enforced version, and rename the file to SiPolicy.p7b.
4. Copy SiPolicy.p7b to %windir%\system32\CodeIntegrity.
5. Run the policy refresh tool to activate and refresh all App Control policies on the computer.

Then verify it landed, which is the step people skip:

1. Open Event Viewer.
2. Browse to Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational.
3. Select Filter Current Log.
4. Replace <All Event IDs> with 3099 and select OK.
5. Find a 3099 event where PolicyNameBuffer and PolicyIdBuffer match the Name and ID from the PolicyInfo settings in the blocklist policy XML. A machine may have more than one 3099 event if other App Control policies are present.

Step 7: the Defender angle

There is one more control in this family, and it is genuinely different again. Microsoft recommends enabling the attack surface reduction rule Block abuse of exploited vulnerable signed drivers alongside the blocklist. Its GUID is 56a863a9-875e-4185-98a7-b882c64b5ce5. In Intune it lives under Endpoint security:

1. Go to Endpoint security > Attack surface reduction.
2. Select Create Policy. Platform Windows, profile Attack Surface Reduction Rules.
3. Name the profile, then find Block abuse of exploited vulnerable signed drivers (Device).
4. Set it to Block, or to Audit first if you want telemetry before enforcement.
5. Assign to a pilot group, review, and create.

Understand exactly what that rule does, because the boundary matters. The ASR rule prevents apps from saving vulnerable signed drivers to the computer. It does not prevent loading drivers already on the computer. Enabling the Microsoft vulnerable driver blocklist, or applying the App Control policy, is what prevents an existing driver from loading. The rule is classified as a Standard protection rule, it is supported on Windows 11 and later, it is deployable via Intune, MDM CSP and Group Policy but not Configuration Manager, and it supports user notification pop-ups but does not generate EDR alerts. Its advanced hunting action types are AsrVulnerableSignedDriverAudited and AsrVulnerableSignedDriverBlocked.

So the full picture is three layers, and it is worth being able to recite it: the ASR rule stops a vulnerable driver being written to disk, the blocklist stops one that is already on disk from loading, and Memory Integrity stops any driver, malicious or merely badly written, from making kernel memory both writable and executable.

Proof it worked: a real run on Windows 11 build 26200

The companion script for this post is Get-HvciReadinessReport.ps1. It is read-only. It reads the WMI class, the four registry locations, the on-disk binaries and policy files, the CodeIntegrity event channel, and the setup log, then translates every documented enumeration into plain English and names any .sys it finds. It changes nothing.

The output below is a genuine run on a Windows 11 Enterprise device, build 26200, under Windows PowerShell 5.1. Identifiers are replaced; nothing else is edited.

The interesting half is the evidence section, because this device is healthy and the script has to say so without pretending it looked harder than it did.

Read that last block carefully, because it contains the two lessons of this whole post. There were twenty 3033 events on a device where Memory Integrity is perfectly healthy. A naive script that counted code integrity errors would have raised an incident. And the setup log confirms that auto-enablement was skipped because this device was upgraded rather than clean installed, which matches Microsoft's documented behaviour exactly, and is why enterprise fleets need policy rather than trusting the default.

The script lives here: Windows-11-Scripts\hvci-memory-integrity-driver-blocklist\Get-HvciReadinessReport.ps1. It needs no modules, runs on both Windows PowerShell 5.1 and PowerShell 7, and takes -EventDays, -MaxEvents, -IncludeAllDrivers and -SkipSetupActLog.

References

• Enable memory integrity - the registry values, the Group Policy steps, the Win32_DeviceGuard property enumerations, and the Windows RE recovery procedure.
• Memory integrity enablement - auto-enablement hardware bar, CI\State\HVCIEnabled, the WasEnabledBy and EnabledBootId safeguard, event 3087, the setupact.log strings and the full VBS_COMPAT_ISSUES bit table, and SkTool.
• Virtualization-based Security (VBS) - the platform component table including TPM 2.0, SLAT, IOMMU, WSMT, the UEFI Memory Attributes Table and Secure MOR v2.
• Driver Compatibility with Hypervisor-Protected Code Integrity (HVCI) - how to build a compatible driver, the Driver Verifier 0x02000000 flag, the failure category table and the affected APIs.
• Microsoft recommended driver block rules - what the vulnerable driver blocklist is, how it ships, the download and apply steps, and the event 3099 verification procedure.
• Understanding App Control event IDs - the CodeIntegrity/Operational event catalog, including 3033, 3074, 3076, 3077, 3082, 3089, 3099 and 3111.
• VirtualizationBasedTechnology Policy CSP - the OMA-URI, the allowed values, and the Group Policy mapping including the ADMX file and registry key.
• Attack surface reduction rules reference - the "Block abuse of exploited vulnerable signed drivers" rule, its GUID, and the boundary between writing a driver to disk and loading one.
• driverquery - the documented syntax and parameters for the in-box driver inventory command.
• Memory Integrity and Virtualization-Based Security (VBS) - the driver-developer framing of what VBS isolates and why.
• KB5020779: the vulnerable driver blocklist - confirmation that the blocklist is enabled by default from Windows 11 version 22H2, and the Windows Security toggle steps.

No community or MVP deep-dive on this specific topic verified as both reachable and genuinely on-subject at the time of writing, so no third-party table is included here. Every claim above traces to a Microsoft-official page in the list, to the documented enumerations quoted inline, or - where explicitly labelled - to observation on a live device.