It started, as these things often do, with something trivial. The Xbox app on my Windows 10 desktop wouldn’t open. Splash screen, a hopeful “Launching Xbox,” and then a dialog with the kind of error code that tells you nothing and everything at once: 0x80070426.
I did not expect that error to end with me staring at a stopped Windows service that had nothing to do with gaming, and realising it had silently broken every driver install on the machine — including, as I’d discover, my GPU. This is the story of how a single stopped service, DeviceInstall, masqueraded as an Xbox bug, then an NVIDIA bug, then very nearly a “reinstall Windows” bug, before revealing itself as the actual culprit. If you’ve ever had drivers mysteriously refuse to install with no good explanation, this is the post I wish I’d found on day one.
The decoy
0x80070426 decodes to ERROR_SERVICE_NOT_ACTIVE. A required service isn’t running. Fair enough — the Xbox app leans on Gaming Services, a pair of packaged services (GamingServices and GamingServicesNet) that ship as a Microsoft Store app. So I checked, and sure enough GamingServices was stopped. Try to start it and it would flip to START_PENDING for a moment and then drop straight back to Stopped, with no error in the Service Control Manager and nothing useful in the event log. A service that exits cleanly while refusing to actually run is a special kind of infuriating.
Here’s the detail that turned out to matter enormously, though I didn’t appreciate it yet: Gaming Services installs two kernel drivers every single time it starts. There’s xvdd.sys (the Xbox Virtual Disk Driver, which backs the way games are stored) and gameflt.sys (a filesystem minifilter). On each launch, GamingServices.exe calls DiInstallDriver to make sure those two driver packages are present in the driver store. If that import fails, the service gives up and exits — which presents to you, three layers up, as “the Xbox app won’t open.”
So the real question was never “why won’t the Xbox app launch.” It was “why can’t these two drivers install.”
Into the driver store
The authoritative record for anything driver-installation-related lives in a log most people never open: C:\Windows\INF\setupapi.dev.log. It’s verbose, it’s chronological, and it does not lie. I went looking for the moment Gaming Services tried to import xvdd.inf, and found this:
sto: {Copy Driver Package: ...\drivers\xvdd.inf}
flq: {FILE_QUEUE_COMMIT}
flq: Copying 'xvdd.cat' ...
flq: Copying 'xvdd.inf' ...
flq: Copying 'xvdd.sys' ...
flq: {FILE_QUEUE_COMMIT - exit(0x00000000)}
sto: {Copy Driver Package: exit(0x00000000)}
!!! dvs: Failed call to import driver package. Error = 0xE0000223 (0x32)
Look at the shape of that failure. The driver package gets copied into the staging area successfully — every file lands, the file queue commits with 0x00000000. Then, the instant SetupAPI tries to actually import (commit the staged package into the driver store), it dies with 0xE0000223. No signature check logged, no catalog validation, nothing in between. Copy succeeds, commit is rejected immediately.
That “copy fine, commit instantly rejected” signature is the whole story in miniature, but I didn’t read it correctly at first. I did what I think most people do: I assumed the problem was the package.
The rabbit holes (a public service announcement)
I spent an embarrassing amount of time chasing the idea that something about these specific drivers was being rejected. In the interest of saving you the same days, here is everything I ruled out, and why none of it was the answer:
- Code signing / WHQL. The
.sysand.catfiles both validate withGet-AuthenticodeSignature—Signature verified. The only “bad” signature is the.infitself showingTRUST_E_SUBJECT_FORM_UNKNOWN, which alarms people but is completely normal: INF files aren’t Authenticode-signed directly, they’re covered by the catalog. - Virtualization-Based Security / HVCI / Memory Integrity. I disabled VBS, turned off the hypervisor launch type, even toggled SVM in the BIOS. Code Integrity enforcement dropped to zero. Same failure.
- The OEM path and stale driver-store state. I corrected the registry
OemPath, then went further and deleted the leftover driver-store registry entries and file-repository folders entirely (which required escalating toSeTakeOwnership/SeRestoreprivileges and, at one point, running a shell asSYSTEMvia PsExec). Clean slate. Same failure. - Source location. Maybe the protected
WindowsAppsfolder was the problem? I copied all the driver files out to a plainC:\Tempdirectory, verified the SHA-256 hashes matched bit-for-bit, and ranpnputil /add-driverfrom there. Same failure, identical code. - Reinstalling the app, running Microsoft’s official GamingRepairTool. The repair tool failed with its own opaque
0x8000FFFF.
Every single one of these was a dead end, and each one cost time. The lesson I’ll carry forward: 0xE0000223 is not a property of the package. I had all the evidence I needed to know that and didn’t act on it.
The clue I’d been ignoring
Twice, pnputil had told me exactly what was wrong, and twice I’d glossed over it. When I ran pnputil /add-driver, it didn’t just fail — it printed:
Failed to add driver package: The Plug and Play service is not available on the remote machine.
The Plug and Play service is not available. I’d dismissed it as a generic, slightly garbled error string (“remote machine”? it’s local). But that string is pnputil’s rendering of the real problem, and the real problem has a name.
The reveal: it wasn’t an Xbox problem at all
The thing that finally broke the case open was noticing that NVIDIA drivers had also stopped installing. Same machine, same week. I pulled up setupapi.dev.log again and found the GPU driver install — nv_dispi.inf, provider NVIDIA, a completely unrelated vendor with a completely unrelated 60-file driver package — failing at the exact same step with the exact same code:
sto: Failed to call to import driver package. Error = 0xE0000223 (0x32)
That changed everything. When two unrelated vendors’ drivers fail identically, the packages are not the problem. The shared infrastructure underneath them is.
I went back through the entire setupapi.dev.log history and tallied driver imports by day:
through 2026/05/05 every import succeeds, zero failures
2026/05/06 first failures appear
2026/05/10 last day anything imports successfully
2026/05/11 onward 100% failure, permanent
A clean machine that worked perfectly, then degraded over a few days, then went completely dark. That is not a signing or policy problem — those fail instantly and consistently. That is infrastructure that went away.
What 0xE0000223 actually means
Here is the decode I should have done on day one. 0xE0000223 is a SetupAPI error. You’ll also see it written as 0x800F0223 — same error, different shell (SetupAPI errors have both an “application” form starting 0xE000 and an HRESULT form starting 0x800F; the meaningful part is the low 0x0223). Its symbolic name is:
SPAPI_E_NO_CONFIGMGR_SERVICES— “The Plug and Play (Configuration Manager) services are not available.”
That secondary (0x32) in the log is ERROR_NOT_SUPPORTED — the operation can’t be performed, because the service that would perform it isn’t there to perform it.
So SetupAPI was doing exactly what it always does: stage the files (works fine, it’s just a copy), then hand off to the Plug and Play / Configuration Manager subsystem to commit the package into the live driver store and finish device setup. And the handoff had nothing to hand off to. The service that does that work was stopped, and couldn’t be started.
That service is DeviceInstall — the “Device Install Service,” implemented in umpnpmgr.dll and hosted inside svchost.exe. And it was sitting there, Stopped.
The architecture, briefly
It’s worth understanding the chain, because it explains why this one stopped service has such an outsized blast radius.
Windows splits Plug and Play across a couple of pieces. PlugPlay is the always-running service that represents the kernel-mode PnP manager to user mode — enumeration, device-node tracking, the live picture of your hardware. DeviceInstall is a separate, trigger-started service. By default it’s set to Manual (Trigger Start): it isn’t running most of the time, and the system starts it on demand the moment something needs a driver installed — a new device arrives, an app calls DiInstallDriver, pnputil runs, Windows Update offers a driver. DeviceInstall is what does the heavy lifting of an install: invoking class installers and co-installers, registering the package, finishing device setup.
Crucially, almost every driver install path routes through DeviceInstall. It doesn’t matter whether the request comes from the Xbox app, the NVIDIA installer, a printer, a USB gadget, a VPN’s virtual adapter, or Windows Update. They all eventually call into the Configuration Manager, and if DeviceInstall can’t come up when called, SetupAPI returns SPAPI_E_NO_CONFIGMGR_SERVICES and the install dies at the commit step — files copied, nothing installed. Which is precisely the signature I’d been staring at for days.
The symptom catalogue: how to recognise this
If DeviceInstall is stopped and can’t start on demand, here’s the spread of symptoms you might see. Any combination of these, especially appearing together, should send you straight to the service:
- New hardware won’t install. Plug in a device and it sits there with no driver, or “Device driver software was not successfully installed.” Devices in Device Manager show Code 28 (no driver) or sometimes Code 56.
- Vendor driver installers fail or roll back — NVIDIA, AMD, printers, audio interfaces — often with vague generic errors, because the installer’s underlying
pnputil/SetupAPI call is the thing failing. pnputil /add-driverreportsThe Plug and Play service is not available on the remote machine(on a local machine — ignore the “remote” wording).- Apps that quietly install drivers on launch break. Gaming Services / the Xbox app (
xvdd,gameflt), virtualization products (VirtualBox, VMware, Hyper-V networking), VPN clients with TAP adapters, anti-cheat drivers. The app-level error will be misleading — in my case,0x80070426. - Windows Update driver updates fail while everything else updates fine.
- The definitive tell, in
C:\Windows\INF\setupapi.dev.log: imports that copy successfully then fail at commit withError = 0xE0000223, and — if you’re lucky — explicit lines likeDeviceInstall service is not startedorFailed to control DeviceInstall service. Error = 0x425(0x425isERROR_SERVICE_NOT_ACTIVE).
The unifying thread: multiple unrelated drivers failing the same way. One vendor’s driver failing is a package problem. Everyone’s drivers failing identically is an infrastructure problem, and DeviceInstall is near the top of that list.
The fix
Once you know what you’re looking at, the fix is almost anticlimactic. Confirm it first, in about thirty seconds, from an elevated PowerShell:
Get-Service DeviceInstall, PlugPlay | Format-Table Name, Status, StartType -AutoSize
Start-Service DeviceInstall
Get-Service DeviceInstallIf DeviceInstall was stopped and now starts, immediately retry whatever driver install was failing. If it now succeeds, you’re done — that was the whole problem.
To make it stick, you want the service in its correct default configuration rather than just nudged up once:
# DeviceInstall default is Manual (trigger start) - NOT Disabled, NOT Automatic
Set-Service DeviceInstall -StartupType Manual
# Confirm the raw start value: 2 = Automatic, 3 = Manual, 4 = Disabled. You want 3.
reg query "HKLM\SYSTEM\CurrentControlSet\Services\DeviceInstall" /v Start
# PlugPlay should be Running and its start value should be 2 (Automatic / boot)
Get-Service PlugPlayA couple of things to check if it still won’t behave:
The start-on-demand trigger. Because DeviceInstall is trigger-started, it relies on a registered trigger to come up when a device install is requested. If that registration has been stripped, the service will refuse to auto-start exactly when it’s needed and you’ll be back here. Inspect it with:
sc.exe qtriggerinfo DeviceInstallIf there are no triggers listed, that’s a problem; the device-install trigger needs to be present for on-demand starts to work. (Re-registering a service trigger via sc.exe triggerinfo is possible but fiddly — verify the exact trigger syntax for your build before applying it, and a repair install will also restore it.)
A device-installation restriction policy. A different but related failure comes from Group Policy blocking installs. Check:
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions" 2>&1If that key exists with values like DenyUnspecified=1 or a populated DenyDeviceIDs, a policy is forbidding device installs — that produces “Device installation is forbidden by system policy,” not 0xE0000223, but it’s worth ruling out while you’re in the neighbourhood. Removing the offending values (or the key) lifts the block.
And if services and policy all look correct but installs still fail with 0xE0000223, you’re into deeper PnP/RPC infrastructure corruption, and the clean endgame is an in-place repair install — booting a Windows 10 22H2 ISO and choosing “Keep apps and files.” That reinstalls Windows’ own binaries and service registrations without touching your installed programs or data. It is emphatically not a wipe, and it’s the right tool when the plumbing itself is damaged rather than just switched off.
Why was it stopped in the first place?
This is the part I’m still chasing, and I’ll be honest that I don’t have a fully nailed-down answer yet. The strong suspicion is a past round of “services tweaking” — one of those performance/debloat passes where you disable a stack of services you don’t think you need. DeviceInstall is an easy casualty: it’s stopped almost all the time by design, so disabling it looks harmless right up until the next time something needs a driver, which might be weeks later. By then the cause and the symptom are so far apart in time that nobody connects them. The gradual May 6 → May 11 degradation in my logs fits that perfectly: the service got knocked out, and then each subsequent thing that tried to install a driver failed, one after another, until the machine couldn’t install anything at all.
The other usual suspects are a broken dependency (if RpcSs, DcomLaunch, or PlugPlay are unhealthy, DeviceInstall can’t function), feature-installation or servicing corruption, and aggressive “optimizer” utilities. If you find yours was Disabled, retrace your own steps — it almost certainly wasn’t Windows that did it.
The takeaways
If you remember three things from this:
First, 0xE0000223 / SPAPI_E_NO_CONFIGMGR_SERVICES in setupapi.dev.log means “the PnP install service wasn’t available,” not “your driver is bad.” Decode your error codes before you start surgery. I’d have saved days.
Second, when multiple unrelated drivers fail identically, suspect the shared infrastructure, not the packages. The moment NVIDIA and Xbox failed the same way was the moment the real diagnosis became obvious in hindsight.
Third, DeviceInstall is a small, usually-idle, trigger-started service with an enormous blast radius. It should be Manual (trigger start), never Disabled. If it’s down, nothing installs a driver — and the failure will surface three layers up wearing a completely unrelated costume, like an Xbox app that won’t open.
The Xbox app, by the way, launched on the first try the moment DeviceInstall was running again.