SPAPI_E_INF_IN_USE_BY_DEVICES (0X800F023D): 3 Fixes That Work

I know this error is infuriating. You're trying to clean up a driver package — maybe rolling back a bad GPU driver, prepping a machine for imaging, or just trying to delete an old OEM INF — and Windows slams the door: SPAPI_E_INF_IN_USE_BY_DEVICES (0X800F023D). Translation: one or more devices are still bound to that INF, so Windows won't let you remove it. The fix is to unbind the device first. Which device? That's the tricky part. Let's work through it, simplest thing first.

Fix 1: Uninstall the device in Device Manager (30 seconds)

Nine times out of ten this is all you need. The INF is locked because a device instance is actively using it — usually something like a Realtek audio driver, an old Intel Wi-Fi package, or a USB controller driver from a vendor you replaced months ago.

1. Right-click Start → Device Manager. Or hit Win + X and press M.
2. Find the device using that INF. If you don't know which one, click View → Devices by driver or View → Resources by type and hunt for the matching driver.
3. Right-click it → Uninstall device.
4. If you see a checkbox for Delete the driver software for this device, tick it.
5. Reboot before retrying your original uninstall command. Don't skip this — Windows keeps a handle on the INF until the device object is fully torn down, and that doesn't complete until restart.

If the device is hidden (common with printers, Bluetooth radios, and old network adapters), turn on View → Show hidden devices. You'll often find a ghost entry holding the INF hostage.

Real-world trigger: I've seen this most often after swapping a laptop's Wi-Fi card. The old Intel AX200 INF stays registered against a phantom device node, and every attempt to remove the driver just throws 0X800F023D until you unhide and delete the ghost.

Fix 2: Force it out with PnPUtil (5 minutes)

If Device Manager won't cooperate — or the device keeps re-installing itself on the next boot — drop to an elevated command prompt and use pnputil directly. This is the tool Microsoft actually recommended after they deprecated dpinst.

First, list every third-party driver package so you can find the right oemXX.inf name:

pnputil /enum-drivers

You'll get a wall of output. Look for the provider, class, and version that matches the INF you're trying to remove. Note the published name (for example, oem42.inf).

Now try to delete it:

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

The /uninstall flag removes the device nodes bound to the driver, and /force overrides the in-use check. If it still fails with 0X800F023D after a reboot, the driver is genuinely stuck in the DriverStore.

Check for stubborn services first

Some drivers install a kernel service that holds a reference even when no device is obvious. Run:

sc query type= driver state= all | findstr /i "driver_name"

If you spot the offender still running, stop it:

sc stop driver_name

Then retry the pnputil /delete-driver command. A quick reboot after stopping is fine and often necessary.

Fix 3: Boot into Safe Mode and clear the DriverStore (15+ minutes)

This is the nuclear option, and honestly it's the one that finally works when nothing else does. In Safe Mode, most third-party drivers never load, so the INF isn't held by a live device.

1. Hold Shift while clicking Restart from the Start menu.
2. Navigate: Troubleshoot → Advanced options → Startup Settings → Restart.
3. Press 4 for Safe Mode (or 5 for Safe Mode with Networking).
4. Once you're at a desktop, open an elevated Command Prompt.
5. Re-run the pnputil /enum-drivers command above to confirm the offender is still there.
6. Delete it with pnputil /delete-driver oemXX.inf /uninstall /force.

If even Safe Mode refuses — rare, but it happens with boot-critical drivers like storage controllers — you'll need to manually edit the DriverStore. Don't try to delete folders under C:\Windows\System32\DriverStore\FileRepository by hand; you'll corrupt permissions and end up with a machine that won't boot. Instead, take ownership carefully, or use the documented pnputil workflow.

When the INF is part of a Windows Update package

Sometimes 0X800F023D shows up during a Windows Update rollback or a cumulative update install. That's a different beast — the INF is being held by the servicing stack, not by you. In that case:

dism /online /cleanup-image /restorehealth
sfc /scannow

Reboot, then retry the update. If it fails again on the same KB, hide it with the wushowhide.diagcab tool and wait for the next patch cycle. Pushing the same broken package repeatedly just wastes your afternoon.

Quick reference

Stop at whichever step solves it. Most people never need Fix 3. But if you've been fighting this for a while, boot into Safe Mode and stop wasting time — it's the cleanest path when a driver refuses to let go.