SPAPI_E_DRIVER_STORE_DELETE_FAILED (0x800F024C) — Real Fixes

You open Device Manager, pick a driver you want gone, hit uninstall, and Windows throws 0x800F024C in your face. Or pnputil /delete-driver oem42.inf /uninstall returns SPAPI_E_DRIVER_STORE_DELETE_FAILED. Either way, the driver's still there.

What's actually happening here is that the driver store (the FileRepository folder under C:\Windows\System32\DriverStore) is refusing to release one or more files. That's almost always because something has the driver mapped, loaded, or marked as a boot-critical dependency. The error isn't really about deletion — it's about a lock or a permission gate.

Work through these in order. The first one fixes about 70% of cases.

Cause 1: Something is still using the driver (device mapped, service running, or boot dependency)

The driver store won't delete an INF while any installed device still binds to it. This bites people who try to remove an old GPU driver, a printer driver, or a network adapter driver while the device is still present in Device Manager. It also catches you when the driver is referenced by a boot-start service that Windows needs to get to the login screen.

Real trigger: a user replaces a Realtek NIC with an Intel one, yanks the Realtek card, and tries to remove the leftover Realtek driver. The .inf is still bound to a phantom device entry, so the delete fails.

Fix

1. Open Device Manager, View → Show hidden devices.
2. Expand the category (Network adapters, Display adapters, etc.) and look for greyed-out entries. Those are phantom devices.
3. Right-click each phantom and choose Uninstall device. If it's a GPU, tick Attempt to remove the driver for this device.
4. Reboot, then run pnputil again.

pnputil /enum-drivers
pnputil /delete-driver oem42.inf /uninstall /force

The /force flag tells Windows to delete even if the driver is currently in use. It's not a magic eraser — it still can't remove a boot-critical driver without a reboot — but it skips the "device is using it" check that produces most 0x800F024C errors.

If the driver belongs to a running service, stop it first:

sc query type= driver | findstr /i "SERVICE_NAME"
net stop YourDriverService

Note the space after type=. sc is picky about that.

Cause 2: ACLs on the DriverStore folder block the delete

The FileRepository subfolders are owned by TrustedInstaller, not Administrators. Even an elevated prompt can't delete files inside a driver package folder if the ACL only grants Read & Execute to Administrators. Pnputil normally handles this through the servicing stack, but when the ACLs get mangled — usually by a "debloat" script, a bad third-party cleanup tool, or a partially completed Windows Update — the service account used by pnputil can't touch the folder.

Real trigger: someone runs a PowerShell one-liner they found on Reddit that resets ownership on C:\Windows to Administrators. Every driver store operation after that returns 0x800F024C.

Fix

First, identify the exact folder. The oem number maps to a folder name like rt640x64.inf_amd64_abc123....

pnputil /enum-drivers

Find the Published Name (oem42.inf) and note the Original Name. Then list the matching folder:

dir /ad C:\Windows\System32\DriverStore\FileRepository | findstr /i "rt640x64"

Take ownership and reset the ACL, then retry the delete:

takeown /f "C:\Windows\System32\DriverStore\FileRepository\rt640x64.inf_amd64_abc123" /r /d y
icacls "C:\Windows\System32\DriverStore\FileRepository\rt640x64.inf_amd64_abc123" /reset /T /C
pnputil /delete-driver oem42.inf /uninstall /force

Don't take ownership of the whole FileRepository tree, only the specific package folder. Blanket ownership changes break future servicing operations and you'll be doing a repair install of Windows next week.

Cause 3: The driver store itself is corrupted or a pending servicing operation is stuck

If the same delete fails across multiple unrelated drivers, and the ACLs and phantom devices are clean, the driver store database is probably inconsistent. This shows up after a power loss during a Windows Update that was staging a driver, or after a failed in-place upgrade from Windows 10 21H2 to 22H2.

Symptom: Windows Update hangs at "Installing drivers", pnputil /enum-drivers lists entries whose folders don't exist, or the same package shows up twice with different oem numbers.

Fix

Kill any pending servicing queue first:

net stop wuauserv
net stop bits
net stop cryptsvc
net stop trustedinstaller
net stop msiserver

Rename the SoftwareDistribution and Catroot2 folders, then restart those services:

ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old
net start trustedinstaller
net start cryptsvc
net start bits
net start wuauserv

Then run DISM against the online image to repair the component store, which is what the driver store's metadata hangs off of:

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

Finally, retry the delete. If it still fails and you're on Windows 11 23H2 or later, use the Driver Store cleanup option under Settings → System → Storage → Temporary files? No — that's not it. The reliable path on modern builds is the older pnputil with /force after the DISM repair. On 24H2 I've seen pnputil report 0x800F024C once even after a clean DISM, and rerunning the same command immediately after succeeded. The store caches its enumeration; sometimes the second call is the one that lands.

What not to do

Don't manually delete folders out of FileRepository with Explorer or del. The folder name is a hash, but the store also keeps a registry entry under HKLM\SYSTEM\CurrentControlSet\Control\DriverDatabase. Wipe the folder and leave the registry, and the next boot can hang trying to resolve a driver that no longer exists. If you're desperate, export that registry key first.

Also: don't "fix" this by rolling back to a system restore point automatically. The restore point might predate a working driver you need. Rename the specific INF in the store folder (add .bak) and reboot. If the machine still boots, you've confirmed that INF is safe to remove and you can delete it properly afterward.

Quick reference

If none of these clear it and the machine still boots, the nuclear option is DISM /Online /Cleanup-Image /StartComponentCleanup /ResetBase. That nukes old component versions and can take an hour. Do it last.