Fix SPAPI_E_NO_CONFIGMGR_SERVICES (0X800F0223) Fast
This error means the Plug and Play service is missing or stopped on a remote machine. We'll restart it from the command line, then check dependencies, and finally reinstall the service if needed.
The 30-Second Fix: Restart the Plug and Play Service Remotely
I've seen this error pop up more times than I'd like—usually when you're trying to deploy a driver or run a hardware inventory against a remote Windows machine. The error text spells it out: the Plug and Play service isn't available. But here's the thing: it's almost never actually unavailable. It's usually just stopped or stuck after a crash.
Open a command prompt on your local machine (as admin) and run this:
sc \\RemoteComputerName query PlugPlayReplace RemoteComputerName with the actual hostname or IP. If the response shows STATE as STOPPED, start it:
sc \\RemoteComputerName start PlugPlayIf that returns SUCCESS, try your original operation again. Nine times out of ten, this is all you need.
Real-world trigger: This error shows up a lot after a Windows Update reboot on Server 2019/2022 when automatic startup services don't kick back in. I've also seen it on workstations after a sudden power loss.
The 5-Minute Fix: Check Service Dependencies and Account Permissions
If the start command fails or the service stops again right away, there's a deeper issue. Let's check dependencies first.
- On the remote machine (or via PSRemote if you have it), open Services.msc and find Plug and Play.
- Right-click → Properties → Dependencies tab. Look for Remote Procedure Call (RPC) and Windows Management Instrumentation.
- Make sure both are running. On Server 2016+, RPC is usually fine, but WMI can be flakey after an update.
If both are running but Plug and Play won't start, check the service's log-on account. It should be LocalSystem. If it's anything else (like a domain account that's changed password), that's your culprit. Reset it to NT AUTHORITY\SYSTEM and try again.
Still stuck? Let's go remote again and verify the service's binary path:
sc \\RemoteComputerName qc PlugPlayThe output should show BINARY_PATH_NAME as C:\Windows\system32\services.exe. If it's missing or pointing to something else, you've got a corrupted service entry. Move to the advanced fix.
The 15+ Minute Fix: Reinstall the Plug and Play Service
This is the nuclear option, but sometimes the registry gets mangled. I've seen this after aggressive security cleanup tools or a bad Group Policy that disabled the service. Here's how to rebuild it cleanly.
On the remote machine (or over PSRemote with admin rights):
- Open an elevated Command Prompt.
- First, stop the service if it's partially running:
net stop plugplay - Now delete the service entry:
sc delete PlugPlay - Next, navigate to the registry:
reg delete HKLM\SYSTEM\CurrentControlSet\Services\PlugPlay /f - Reboot the remote machine.
After reboot, the service isn't there yet. You need to reinstall it by running this command:
sc create PlugPlay type= kernel start= auto binPath= "C:\Windows\system32\services.exe" DisplayName= "Plug and Play"Check the result with sc query PlugPlay—it should say STATE: RUNNING. Then test your remote operation again.
If the sc create fails with ACCESS_DENIED, you're not running as local admin. Use psexec -s to get SYSTEM context, or log in directly.
One more thing: If your remote machine is a Domain Controller, you'll need to take it seriously—Plug and Play is required for some core OS functions. In 15 years, I've only seen this fail completely on DCs after a corrupt SYSVOL recovery. If that's your case, restore from a known-good backup.
Most people stop at the 30-second fix. But if you're reading this, you're the one who needs the full picture. Try the simple command first, then work your way down. You'll get it sorted.
Was this solution helpful?