Driver install fails with 0X800F0230 on Windows 10/11

What causes 0X800F0230 — and the fastest fix

This error pops up when you try to install a driver that Windows flags as non-native — meaning the driver's signing or compatibility doesn't match the current system's configuration. Most often, it's because the driver is already in the install queue from a previous failed attempt, and Windows refuses to push through a second copy. Had a client last month whose whole fleet of printers died because of this — they'd tried to install a new scanner driver on a Windows 11 machine running 22H2, and every subsequent driver install threw 0X800F0230.

The quickest fix is to clear out the driver store queue. Here's how:

1. Open an elevated Command Prompt (right-click Start > Windows Terminal (Admin) or Command Prompt (Admin)).
2. Type pnputil /enum-devices to list all devices. Look for the one showing the error — often a yellow exclamation in Device Manager.
3. Once you find the device instance ID (looks like PCI\VEN_8086&DEV_…), run: pnputil /remove-device ""
4. Then purge the entire driver store queue: pnputil /delete-driver * /force
5. Reboot and try the driver install again.

This clears out any stale driver packages that were hanging in the queue. After the reboot, Windows will rebuild the queue fresh. If you're still hitting the error, move to the next cause.

Cause #2: Secure Boot or UEFI signing conflict

Another real-world trigger: Windows 10 and 11 with Secure Boot enabled reject drivers that aren't signed correctly for the current UEFI mode. I've seen this on Dell Latitude 5430 and Lenovo ThinkPad X1 Carbon Gen 9 after a BIOS update — the new firmware tightens driver signing requirements. The error shows up as 0X800F0230 when you try to install a driver that was signed for an older Secure Boot policy.

Fix: Temporarily disable Secure Boot in BIOS, install the driver, then re-enable it. Or, update the driver from the manufacturer's site that specifically supports the new signing policy. Don't leave Secure Boot off permanently — that's asking for trouble.

1. Restart the machine and tap F2 (or Del, Esc, depending on your BIOS) to enter Setup.
2. Go to Boot > Secure Boot and set it to Disabled.
3. Save changes, boot to Windows, and install the driver.
4. After successful install, go back to BIOS and re-enable Secure Boot.

If the driver works with Secure Boot off, but fails with it on, you need a driver signed with SHA-256 (not SHA-1) and that includes the proper UEFI CA certificate. Check the manufacturer's download page for a version explicitly labeled "Secure Boot compatible."

Cause #3: Corrupted or mismatched INF files in the driver package

Sometimes the driver itself is fine, but the INF file references a class GUID or architecture that doesn't match your system. This is especially common when someone downloads a driver meant for Windows 8.1 and tries to install it on Windows 10 22H2. The INF's [Manufacturer] section might specify %NTx86% when you're running x64, or it might target a different device class entirely.

Had a client who tried to install a Realtek audio driver from a dodgy zip they found on a forum. The driver .inf was for an Intel chipset, not audio — Windows saw the mismatch and threw 0X800F0230.

Fix: Manually inspect the INF file. Right-click the driver installer (.exe or .inf), select Properties, and check the Digital Signatures tab to ensure it's signed by the correct publisher. Then, extract the driver files (if it's an .exe, run it with /extract or use 7-Zip). Open the .inf in Notepad and look for:

[Version]
Signature="$Windows NT$"
Class=System
ClassGuid={4d36e97d-e325-11ce-bfc1-08002be10318}

Make sure the Class and ClassGuid match what you expect. For a network driver, it should be Class=Net; for a display driver, Class=Display. If they're wrong, you need the correct driver package.

If the INF looks correct, use pnputil /add-driver to install it directly without the installer wrapper. That bypasses the queue and often resolves the non-native error.

Quick-reference summary

One last thing: if none of these work, check if the driver is actually needed. I've seen cases where Windows Update already had a better driver queued up, and the manual install conflicted. Run pnputil /enum-drivers to see what's already in the store. Sometimes the best fix is to let Windows handle it — uninstall the problematic device, reboot, and let Windows Update grab the right driver automatically.