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.
- Press
Win + R, typecmd, and hitCtrl + Shift + Enterto open an elevated prompt. Accept the UAC prompt. - 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.
- Right-click the grayed-out entry and pick Uninstall device.
- 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.
- 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.
- In Device Manager, right-click the offending entry, choose Properties, go to the Details tab, and set the dropdown to Device instance path.
- Copy that string.
- 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\Enumfor 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.htmland 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 /statusfor an active MDM session and look at the Intune Management Extension log underC:\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.