0X800F0207

SPAPI_E_DEVINST_ALREADY_EXISTS (0x800F0207): Fix Duplicate Device Instances

Windows can't add a device because a matching instance already exists. Clear the ghosted entry, rescan, and the install completes.

When you actually see this error

You're reinstalling a driver, popping in a replacement USB device, or pushing a driver package through MDT or Intune, and the install dies with SPAPI_E_DEVINST_ALREADY_EXISTS (0x800F0207). SetupAPI refuses to create a new device instance because one with the same instance ID is still registered on the system. You can see this in Device Manager as a device that shows up but won't fully install, or in a deployment log where the same hardware gets a failure on the second pass.

The classic trigger: a USB-to-serial adapter gets unplugged mid-transfer, the driver uninstalls but the instance stays behind, and plugging the same adapter back in throws 0x800F0207 instead of just working. Same thing happens after a VM snapshot restore where the virtual NIC's instance ID persists but the driver package changed.

What's really going on

Every device Windows sees gets an instance ID — a string like USB\VID_067B&PID_2303\6&2A6D7B8C&0&1. That ID gets written to the registry under the device's enum key, and SetupAPI checks it before creating anything new. If the ID already exists in the registry but the driver isn't bound correctly (or the enum entry is stale), SetupAPI bails with 0x800F0207 rather than trying to reconcile the two.

Most of the time you've got a ghosted or partially-removed device. The hardware isn't physically there, the driver's gone, but the enum key is still sitting in the registry telling Windows the instance exists. Plug the same hardware back in, and Windows tries to create the instance, sees the leftover, and quits.

The real fix is removing the leftover instance cleanly, not editing the registry by hand. Let's do it in order.

Fix it step by step

1. Show hidden and ghosted devices

Device Manager hides non-present devices by default. You need to see them first.

  1. Press Win + R, type cmd, and hit Ctrl + Shift + Enter to open an elevated prompt. Accept the UAC prompt.
  2. Run:
set DEVMGR_SHOW_NONPRESENT_DEVICES=1
start devmgmt.msc

After Device Manager opens, click View in the menu bar and check Show hidden devices. You'll see grayed-out entries for hardware that isn't currently connected. Those are your suspects.

2. Uninstall the duplicate instance

Find the device matching the one that's failing. It usually sits under the same category as the physical device (Ports, Network adapters, USB controllers) and is grayed out.

  1. Right-click the grayed-out entry and pick Uninstall device.
  2. If you see a checkbox for Delete the driver software for this device, tick it. If you don't, don't worry — the next step handles the driver store.
  3. Click Uninstall and wait for it to finish. This can take 20–40 seconds on a slow disk.

Do this for every grayed-out copy of the same device. If you see three phantom COM ports from old adapters, remove all three.

3. Rescan from the command line

Device Manager's Scan for hardware changes menu item is fine, but the command-line version gives you a clean log if the error comes back.

pnputil /scan-devices

Expected result: a short line returning to the prompt with no error. Plug the physical device back in. It should now enumerate as a new instance. If the device installs cleanly, you're done — skip to the end.

4. If the instance still sticks, remove it by ID

Sometimes Device Manager won't fully release the instance, especially for network adapters or devices bound to filter drivers. Get the instance ID and remove it directly.

  1. In Device Manager, right-click the offending entry, choose Properties, go to the Details tab, and set the dropdown to Device instance path.
  2. Copy that string.
  3. In your elevated prompt, run:
pnputil /remove-device "USB\VID_067B&PID_2303\6&2A6D7B8C&0&1"

Swap in your actual instance path. You should see Successfully removed device. Then rescan:

pnputil /scan-devices

5. Clear the oem driver package if it's still bound

If the same driver package keeps rebinding to the stale instance, nuke it from the driver store.

pnputil /enum-drivers

Find the oem##.inf that matches your device's provider and class. Then:

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

Replace oem42.inf with your actual published name. The /force flag is what makes this work when the driver is still referenced — without it, pnputil refuses. Reinstall the driver fresh afterward.

If the install still fails

Check these in order:

  • Another device with the same instance ID. Open Registry Editor and search HKLM\SYSTEM\CurrentControlSet\Enum for the instance path. If it appears in two branches, the registry is genuinely corrupt at that node. Delete the stale subkey, but back up the Enum hive first — Windows will rebuild it on next boot.
  • Group Policy blocking installation. If this is a managed machine, run gpresult /h gpo.html and check for device installation restrictions. A deny rule on the device class will surface as 0x800F0207 during SetupAPI's pre-check even when the instance is fine.
  • Pending reboot. Check HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending. If that key exists, reboot before doing anything else. SetupAPI caches device state and the cache doesn't clear until boot.
  • Antivirus filter driver. Some endpoint tools (older versions of certain network access controllers) hook the device stack and hold instance references. Temporarily stop the service and retry the install to confirm.
  • Enrollment or provisioning lock. On Intune-managed or Autopilot devices, a pending device configuration profile can block driver installs. Check dsregcmd /status for an active MDM session and look at the Intune Management Extension log under C:\ProgramData\Microsoft\IntuneManagementExtension\Logs.

If you've cleared ghosts, removed the driver store entry, and rebooted, and you're still getting 0x800F0207, grab a SetupAPI log. Enable it with:

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup" /v LogLevel /t REG_DWORD /d 0x2000FFFF /f

Reproduce the failure, then read C:\Windows\INF\setupapi.dev.log and search for the failing instance ID. The log shows exactly which check returns the duplicate — that's your answer.

Related Errors in Windows Errors
0X8011044D COMADMIN_E_CANT_SUBSCRIBE_TO_COMPONENT 0X8011044D Fix 0X000005A3 Fix 0X000005A3: Invalid GW_* Command Error in Windows 0XC00D1BE8 NS_E_INVALID_VIDEO_WIDTH_FOR_INTERLACED_ENCODING (0xC00D1BE8) Fix 0XC01E0588 Fix STATUS_GRAPHICS_MCA_INTERNAL_ERROR (0xC01E0588) Fast

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.