Fix 0x0000027C: PNP restart enumeration on device removal

You see 0x0000027C (ERROR_PNP_RESTART_ENUMERATION) in Event Viewer or a debug log right after you unplugged a USB hub, disconnected an external GPU, or ejected a Thunderbolt dock. Maybe it pops up when Windows is booting and a device was yanked mid-initialization. The exact trigger: something told the Plug and Play manager “this device is gone,” so it started a full re-scan of the bus to see what's still there.

What’s actually happening here

The PNP manager keeps a tree of all connected devices and their drivers. When a device disappears—without being properly ejected—the system can't just mark a hole. It needs to walk the branch, figure out which child devices got orphaned, and restart enumeration from the parent node down. That restart triggers this error code. Most of the time it's benign. You get the event, the re-scan finishes in milliseconds, and every surviving device keeps working.

But if you see this error repeating in a loop—especially paired with a device that won't show up or a USB port that's dead—then something's stuck. A driver didn’t release its reference, or a ghost device entry is confusing the tree.

The fix: clear ghost devices and check drivers

Skip the registry hacks. The real fix is in Device Manager, with hidden devices visible.

Open Device Manager with hidden devices shown. Open a command prompt as Administrator and run:
```
set devmgr_show_nonpresent_devices=1
start devmgmt.msc
```
That environment variable tells Device Manager to show ghosts—devices that were once connected but are no longer present. Without this, you're flying blind.
Expand every category, especially Universal Serial Bus controllers and System devices. Look for greyed-out entries. Those are phantom devices. Right-click each one and select Uninstall. Don't worry about removing something needed—if it's grey, Windows already knows it's gone, but the driver object remains.
Delete hidden device instances from the registry only if step 2 didn't stop the loop. This is riskier, so I'd only do it if the error keeps firing every few seconds. Run regedit and go to:
```
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB
```
Look for subkeys named after your problem device (you can identify it by its VID/PID in the event details). Right-click and delete the entire key. Back up the key first—export it to a .reg file. If you delete the wrong thing, a connected device won't be recognized until you plug it in again.
Update or reinstall the driver for the parent hub or controller. Go back to Device Manager, find the USB Root Hub or PCI-to-USB controller that sits above the problematic device. Right-click → Update driver → Browse my computer → Let me pick from a list. Choose the same driver version (usually “Standard USB Hub Controller” or “Intel USB 3.0 eXtensible Host Controller”). This forces the driver to re-initialize without a reboot.
If nothing else works, run a full PNP re-scan from an elevated prompt:
```
pnputil /scan-devices
```
This forces a fresh enumeration of every bus. Then restart the Plug and Play service (services.msc → find “Plug and Play” → right-click → Restart). That service restart can break a stuck re-enumeration loop.

What to check if it still fails

If the error keeps coming back after all that, look for a deeper hardware issue. Bad USB ports can send spurious removal signals. A failing power supply to a USB hub can cause dropouts that trigger the re-enumeration. Try the device on a different port, ideally a direct motherboard port (not front-panel or a hub). Also check for a BIOS update—some motherboards had buggy USB controller firmware that caused phantom removals.

One last thing: if you're using an external GPU enclosure (eGPU) over Thunderbolt, make sure you're safely ejecting it through the systray icon before unplugging. Thunderbolt controllers are finicky about surprise removals, and this error is their way of saying “you messed up the order of operations.”