0X00000241: Hash missing from system catalogs — fix guide

1. Driver signature enforcement is blocking an unsigned driver (most common)

What's actually happening here is that Windows 10/11 (builds 1903 and later) enforces driver signature enforcement by default. When a driver — often a network adapter, GPU, or audio driver — hasn't been submitted to Microsoft's Hardware Certification, its hash won't appear in the %SystemRoot%\System32\CatRoot catalog files. The OS sees an image it can't verify and throws 0X00000241.

You'll typically see this during boot, after installing a new device, or after a Windows Update that tightens security policies. The error might appear in Event Viewer under System logs with source Kernel-General or bcd.

How to fix it

1. Boot into Advanced Startup: Hold Shift while clicking Restart, or mash F8/F11 during boot.
2. Go to Troubleshoot > Advanced Options > Startup Settings.
3. Click Restart. After reboot, press 7 to Disable driver signature enforcement.
4. Once Windows loads, the driver will work — but this is a temporary fix. The setting resets on next boot.

For a permanent fix, you have two real options:

• Use a test-signed driver: Run bcdedit /set testsigning on as admin, then reboot. This tells Windows to accept test-signed drivers. Don't use this on a production machine — it's a security hole.
• Whitelist the driver's hash: This is the proper path but requires the driver vendor to provide a signed catalog file. If they won't, switch to a driver from a manufacturer that actually submits to WHQL.

The reason step 3 works is that disabling signature enforcement tells the OS to skip the catalog check entirely. But the driver still loads with reduced trust — any malware using the same technique would also sneak through.

2. Corrupted catalog files in CatRoot

Sometimes the system catalogs themselves get corrupted. This happens after a botched Windows Update (I've seen it after KB5025228 on Windows 11 22H2), or when a third-party AV tool deletes entries it thinks are suspicious. The hash exists, but Windows can't read the catalog.

The error shows as 0X00000241 even for signed drivers — the system can't open the catalog file to compare hashes.

How to fix it

1. Open an admin Command Prompt.
2. Run sfc /scannow — this repairs system files but often misses catalog corruption.
3. If SFC finds nothing, run DISM /Online /Cleanup-Image /RestoreHealth. DISM rebuilds the component store, which includes CatRoot.
4. Reboot. If the error persists, manually rebuild CatRoot:

net stop cryptsvc
ren %SystemRoot%\System32\CatRoot2 CatRoot2.old
net start cryptsvc

What's happening here is that cryptsvc (Cryptographic Services) manages the catalog database. Renaming CatRoot2 deletes the old database — Windows recreates it on next boot from the central catalog store in %SystemRoot%\System32\CatRoot.

Skip this fix if you don't see catalog-related errors in Event Viewer (look under Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational).

3. Secure Boot or UEFI Secure Boot conflicts

Newer Windows machines with Secure Boot enabled (almost all UEFI systems from 2016 onward) check driver hashes against a separate Secure Boot DB (database) stored in firmware. If a driver's hash isn't in the DB, Secure Boot blocks the image before Windows even starts to verify it.

This shows up as 0X00000241 on boot — you'll see the error before the login screen. Common triggers: installing a dual-boot system with Linux, using a third-party bootloader like rEFInd, or adding a PCIe NVMe drive whose controller driver isn't signed for Secure Boot.

How to fix it

1. Enter your BIOS/UEFI (usually F2, F10, or Del on boot).
2. Find Secure Boot — location varies. On ASUS boards it's under Boot; on Dell it's Security.
3. Set to Disabled or Other OS (not Windows UEFI mode).
4. Save and exit.

If Secure Boot is required (corporate policy, BitLocker), you must add the driver's hash to the UEFI DB. That requires Shim or Machine Owner Key (MOK) enrollment:

mokutil --import /path/to/driver.efi
Reboot and follow the blue MOK enrollment screen.

The reason disabling Secure Boot works is that the hash check happens in firmware, not the OS — Windows never gets to run its own catalog validation. But this is a nuclear option. On a company laptop, don't do it — get IT to add the driver to Secure Boot's allowlist.

Skip the Secure Boot fix if you only see the error after Windows boots (e.g., in a specific app). That's cause #1 or #2.

Quick-reference summary table

One last thing: if none of these work, run sigverif.exe from an admin prompt. It scans all system files and shows which ones are unsigned — that's your hit list. Check the driver's version and manufacturer. Some cheap USB-to-Ethernet adapters from 2018 are famously unsigned — toss them, they're not getting WHQL signed now.