SPAPI_E_INVALID_DEVINST_NAME (0x800F0205) Fix: Invalid Device Instance Name

Cause 1 – Corrupted device instance path in the registry

What's actually happening here is that Windows stores each device's unique instance ID in the registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum. When a driver install gets interrupted—say, you yanked a USB drive mid-install, or Windows Update crashed—the registry key gets left half-baked. The PnP manager then tries to read that path while installing or updating drivers, finds garbage characters or a missing subkey, and throws 0x800F0205.

I've seen this most often after a failed NVIDIA or Realtek audio driver install. The fix is to nuke the bad entry.

Manual registry cleanup (safe way)

1. Open Device Manager (devmgmt.msc). Look for devices with a yellow exclamation mark. Right-click the problematic one, select Properties, go to the Details tab, and choose Device instance path from the dropdown. Copy that string.
2. Open Regedit as Administrator. Navigate to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\.
3. Find the subkey that matches your device instance path. For example, PCI\VEN_10DE&DEV_1C82&SUBSYS_86191043&REV_A1\4&1E8E1A41&0&0008. If the key exists but has no DeviceDesc or HardwareID values inside it, that's your culprit.
4. Back up the key (right-click → Export), then delete it.
5. Restart the machine. When Windows boots, PnP re-enumerates devices and rebuilds that path from scratch.

The reason step 4 works is that the PnP manager uses a fallback: if the registry entry is missing, it calls CM_Get_Device_ID_List directly from the device's own hardware descriptor (stored in the device firmware or ACPI tables). That's almost always valid.

Cause 2 – Stale device node from an orphaned device

Sometimes the device instance name is technically valid but points to a device that no longer physically exists. This happens when you swap out a video card or remove an internal Wi-Fi module without running the proper uninstall. The registry key remains, Windows tries to use it during a driver search or device installation, and the name resolves to a ghost. Error 0x800F0205 appears because the system can't actually communicate with that non-existent hardware.

Scan for hardware changes

1. Open Device Manager.
2. Click View → Show hidden devices. This shows you ghosts that Windows normally hides.
3. Expand the categories and look for grayed-out devices (these are the phantoms). Right-click and select Uninstall device. Check the box Delete the driver software for this device if prompted.
4. After uninstalling, go to Action → Scan for hardware changes. This forces Windows to re-enumerate only what's actually present.

I'd say 80% of the time this alone fixes the error if you've recently swapped hardware. If not, move to cause 3.

Cause 3 – Broken devcon or driver package referencing an old instance

You'll hit this if you're using devcon.exe or some enterprise deployment tool (like MDT or SCCM) that passes a specific device instance string to CM_Locate_DevNode. If that string doesn't match exactly—wrong casing, an extra backslash, a trailing space—the API call fails with 0x800F0205. This isn't a Windows bug; it's your script or tool feeding bad data.

How to fix: validate and regenerate the instance name

1. Open an elevated Command Prompt or PowerShell.
2. Run devcon find * or Get-PnpDevice | Select-Object InstanceId in PowerShell. Grab the correct instance ID for your device.
3. Compare it character-by-character with what your script or driver package is using. Pay attention to underscores vs hyphens. Example: USB\VID_046D&PID_C077\1234567890 vs USB\VID_046D&PID_C077\1234567890 — looks the same but one might have a hidden Unicode character.
4. If you're writing a script, use CM_Get_Device_ID_List_Size and CM_Get_Device_ID_List APIs to fetch the live list rather than hardcoding strings. Hardcoding instance paths is fragile across reboots because the bus driver can reassign them.

The real fix for this cause is to stop hardcoding device instance names in your scripts. Use hardware IDs or compatible IDs instead—those don't change unless the device itself changes.

Quick-reference summary table

That's it. Pick the cause that matches your situation. If you're still hitting the error after all three, check Windows Event Viewer under System for DeviceSetupManager warnings—that'll give you the exact device node Windows was trying to work with.