You just swapped a drive, added a second SATA controller, or restored a system image onto new hardware. Windows boots, throws a blue screen, and the stop code reads STATUS_PLUGPLAY_NO_DEVICE with 0XC000025E underneath. Annoying? Yes. Confusing? Absolutely, because the message talks about a device that "had been disabled" — and you never disabled anything.
This error shows up most often on older machines with IDE-mode drives, legacy RAID controllers (think Intel RST set to RAID instead of AHCI), or a motherboard where someone previously disabled a device in Device Manager to stop a driver conflict. It also pops up after cloning a Windows install from one PC to another when the old machine's storage driver was disabled or removed but the new one still references it.
What's actually happening
Windows treats every piece of hardware as a Plug and Play (PnP) device with a unique instance ID. When a device is disabled — either manually, by a group policy, or by Windows itself after a conflict — the PnP manager marks that instance as disabled in the registry. It stays that way until something re-enables it.
A legacy driver doesn't play by PnP rules. It expects to find a live device instance when its DriverEntry routine runs during boot. If the device it's tied to is disabled, the driver's load attempt fails and the kernel flags it with STATUS_PLUGPLAY_NO_DEVICE. In plain English: the driver showed up to work, but the device it was hired for wasn't there.
The error isn't telling you the hardware is broken. It's telling you Windows deliberately turned that device off and the driver didn't get the memo.
The fix
Work through these in order. The first one solves it maybe 70% of the time.
Boot into Safe Mode. Tap F8 during startup, or hold Shift while clicking Restart from the login screen, then pick Troubleshoot → Advanced Options → Startup Settings. Safe Mode skips most legacy drivers, so you can actually get in and fix things.
Open Device Manager and show hidden devices. Run
devmgmt.msc. Then in the menu bar go to View → Show hidden devices. You're looking for anything with a down-arrow icon (that's how Windows draws a disabled device) or a grayed-out entry under Storage controllers, IDE ATA/ATAPI controllers, or System devices.Re-enable the disabled device. Right-click it and choose Enable device. If the option is missing, you'll need the registry route (step 5). Watch the names closely — a disabled "Intel(R) 82801 SATA AHCI Controller" is exactly the kind of entry that throws this stop code.
Check the storage driver mode in BIOS. Reboot into BIOS/UEFI and look under SATA configuration. If it's set to RAID or IDE but Windows was installed in AHCI mode (or vice versa), you'll get this error right after the Windows logo. Switch it to match what Windows expects. If you don't know which, try AHCI first.
Force it via the registry. If Device Manager won't let you enable the device, boot into Safe Mode again and open
regedit. Navigate to:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\EnumEach subkey under that is a device enumerator (PCI, IDE, USB, ROOT, etc.). Expand them until you find the device matching the one giving you trouble. Inside, look at the
ConfigFlagsvalue —0x1means the device is disabled. Change it to0x0and reboot.Roll back a bad driver. If this started right after a driver update, Device Manager → right-click the device → Properties → Driver tab → Roll Back Driver. Uninstalling also works if you've got the correct driver to reinstall from the manufacturer's site — not from Windows Update, which often serves up stale versions.
If it still fails
Boot loops that won't let you reach Safe Mode mean you're editing the registry from WinRE. Boot from a Windows install USB, choose Repair your computer → Troubleshoot → Advanced Options → Command Prompt, then load the offline hive:
reg load HKLM\TEMP C:\Windows\System32\config\SYSTEM
Edit the ConfigFlags values under HKLM\TEMP\ControlSet001\Enum, then unload with reg unload HKLM\TEMP before rebooting. Yes, it's tedious. No, there's no shortcut.
Two other things worth checking: Windows Update may have reinstalled a driver you disabled (KB rollups do this quietly), and if this is a VM, the virtual disk controller type in the .vmx or .vbox file has to match what the guest OS was installed with. An IDE-to-SATA switch on a VM that was built with IDE is a classic trigger.
That covers the common cases. If you're still stuck, grab the minidump from C:\Windows\Minidump and check which driver is named in the stack — that's your real culprit, and it's usually not the one the error message points at.