What Changed in the Kernel for 24H2
Windows 11 version 24H2 is a significant kernel update. Unlike the 23H2 update, which was primarily a cumulative patch on top of 22H2's kernel, 24H2 ships with a new kernel version and introduces enforcement-level changes to several kernel security policies that were previously either absent or opt-in. Three changes are directly relevant to third-party driver compatibility: expanded Vulnerable Driver Blocklist enforcement, stricter kernel-mode code integrity policies, and changes to how the hypervisor-protected code integrity (HVCI) interacts with driver initialisation.
These changes explain why a driver that loaded on 23H2 may be blocked or fail initialization on 24H2. Maintained applications may ship revised components, while abandoned software can remain incompatible with the newer trust policy.
The Vulnerable Driver Blocklist
Microsoft maintains a Vulnerable Driver Blocklist containing identities for drivers with known exploitable vulnerabilities, even when those vulnerabilities are unrelated to the driver's primary function. The associated attack pattern is called Bring Your Own Vulnerable Driver (BYOVD): malicious code abuses a legitimately signed but vulnerable driver to gain kernel-mode execution.
Prior to 24H2, the blocklist was applied when HVCI (also called Memory Integrity in the Windows Security app) was enabled. HVCI was enabled by default on new hardware that met the requirements, but was not universally applied on systems upgraded from Windows 10 or earlier Windows 11 versions. In 24H2, Microsoft expanded blocklist enforcement to a broader set of configurations, meaning some drivers that loaded on a 23H2 system without HVCI enabled will be blocked on 24H2 regardless of HVCI state.
The blocklist is serviced through Windows Update. WDAC (Windows Defender Application Control) event records and Microsoft’s published security documentation describe policy decisions and known entries.
Categories of Drivers Commonly Affected
Several categories of third-party software are known to ship kernel drivers that interact with the 24H2 policy changes.
Hardware monitoring utilities that read sensor data from the motherboard often use a kernel driver to access low-level hardware interfaces — specifically, direct I/O port access and physical memory mapping — that are not exposed through any standard Windows API. Legacy tools such as SpeedFan, older versions of HWiNFO64, and older versions of CPU-Z shipped drivers that the blocklist now flags. Later releases can contain revised drivers, whereas disabling a security feature changes the operating system’s protection boundary.
RGB lighting control software from motherboard and peripheral vendors frequently requires a kernel driver to communicate with embedded controllers and proprietary hardware interfaces. ASUS Armoury Crate's ATKWX driver, older MSI Dragon Center installations, and similar utilities have had known driver vulnerabilities in older releases. Updated versions of these software suites ship revised drivers that pass current blocklist checks, but only if the software is updated to a release that postdates Microsoft's expanded enforcement.
Legacy anti-cheat systems built on kernel drivers face particular scrutiny because they operate at a high privilege level by design. Anti-cheat vendors who ship WHQL-certified drivers based on audited codebases are generally unaffected. Older anti-cheat integrations in games that have not been updated in several years are more likely to encounter issues.
HVCI and Driver Compatibility
HVCI uses the hardware virtualisation layer to enforce code integrity in the kernel. When active, HVCI prevents any kernel-mode code that was not cryptographically signed by a trusted authority from executing, even if the unsigned or untrusted code was loaded by a process with administrative privileges. On 24H2 hardware that meets the Secured-Core PC requirements, HVCI is enabled by default.
Drivers that allocate executable memory at runtime — a technique used by some older hardware abstraction layers — are incompatible with HVCI. Attempting to load such a driver on an HVCI-enabled system results in the driver failing to start with an error code indicating a code integrity violation. The system itself remains stable; only the non-compliant driver is blocked.
Windows Security represents HVCI under Device Security and Core Isolation Details, where the Memory Integrity state reports whether the policy is enforced. A non-compliant driver and HVCI cannot operate together; disabling Memory Integrity reduces the system's resistance to kernel-level attacks.
How 24H2 Reports Compatibility
Compatibility information comes from application publishers, Windows safeguard holds, setup assessments, and runtime code-integrity events. Motherboard utilities, RGB controllers, hardware monitors, and anti-cheat systems are notable because their visible applications can include less-visible kernel drivers.
Windows records blocked kernel components under the `Microsoft-Windows-CodeIntegrity` event source. Those records identify the file and policy reason, connecting a visible application failure with the underlying driver that Windows rejected.