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.
Understanding these changes matters because a driver that loaded without issue on 23H2 may fail to load, cause a bug check, or silently refuse to start on 24H2. In most cases the fix is to update the affected software to a version shipping a revised driver; in some cases the affected software has been abandoned and will not receive an update.
The Vulnerable Driver Blocklist
Microsoft maintains a Vulnerable Driver Blocklist — a set of driver file hashes corresponding to known drivers that contain exploitable vulnerabilities, even if those vulnerabilities are not in the driver's primary functionality. The attack pattern these drivers enable is called Bring Your Own Vulnerable Driver (BYOVD): a malicious actor delivers a legitimately signed but known-vulnerable driver to a target system and exploits the driver's vulnerability to achieve kernel-mode code execution, bypassing security products that operate only in user mode.
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 updated through Windows Update, and checking the current state of which drivers are blocked is possible by reviewing the policy defined in the WDAC (Windows Defender Application Control) audit logs or by consulting the public list Microsoft maintains in its security documentation.
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. Most of these tools have released updated versions with revised drivers; updating to the current release is the appropriate response, not disabling security features to permit the old driver to load.
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.
To check whether HVCI is active, open the Windows Security app, navigate to Device Security, and look for Core Isolation Details. If Memory Integrity shows as On, HVCI is enforced. Users who need a specific non-compliant driver for hardware that has no updated driver available must weigh the security trade-off of disabling Memory Integrity, as doing so reduces the system's resistance to kernel-level attacks.
Preparing Before Applying the 24H2 Update
The safest approach to the 24H2 update is to update all system utilities — motherboard companion software, RGB controllers, hardware monitors, and any software that the vendor specifically identifies as requiring an update for Windows 11 24H2 compatibility — before applying the feature update. Creating a full system backup or at minimum a system restore point before the update provides a recovery path if an unexpected driver conflict causes boot issues after the update completes.
After the update, if a device ceases to function or a utility fails to start, checking Event Viewer under Windows Logs > System for entries with source "Microsoft-Windows-CodeIntegrity" will identify which driver file was blocked and why. This information is directly actionable: look up the blocked driver file name to identify the associated software, then check whether that software vendor has issued a 24H2-compatible update.