Background

Following a recent Windows 11 update, the Xbox App stopped working entirely, throwing error 0x80070426 immediately upon launch. Checking the System Services manager (services.msc) revealed two instances of Gaming Services with identical names: one had all control buttons greyed out, while attempting to start the other threw Error 1060: The specified service does not exist as an installed service.

I exhausted standard troubleshooting methods with no success:

• Standard cleanup via PowerShell (Remove-AppxPackage) followed by a Microsoft Store reinstall yielded no results.
• Running Microsoft’s official dedicated repair tool (GamingRepairTool.exe) did absolutely nothing.
• Elevating privileges to SYSTEM via PsExec to execute sc delete in an attempt to force-delete the service resulted in an unexpected Error 5: Access is denied.
• Booting into WinRE to physically wipe the files under WindowsApps, and even performing an In-place Upgrade (reinstalling Windows while keeping apps and settings) failed. Upon reboot, the broken service resurrected itself exactly as it was.

This was highly anomalous: even SYSTEM privileges lacked the permission to delete it, and an in-place upgrade could not purge it. This implied the root cause was neither file permissions nor the AppX deployment engine, but rather the Windows kernel driver state. The investigation process is detailed below.

Troubleshooting Strategy

Given that even SYSTEM encountered Error 5, and an in-place upgrade failed (indicating that the corrupted state repository was inherited as a valid configuration), I needed to bypass the UWP mechanism entirely and force-inject the service via hardcoding.

I used sc.exe create to force-write the physical path and attempted to start it. The outcome was distinct: the system threw [SC] StartService FAILED 1056: An instance of the service is already running. Checking the specific service status revealed STATE : 2 START_PENDING.

This explained the prior Error 5: the process was trapped in an infinite “Starting” state in the background. The Windows kernel protection mechanism strictly prohibits modifying or deleting a service while it is in a PENDING state, effectively granting it system-level immunity.

Root Cause Analysis

Why was it perpetually hanging? Gaming Services is not a typical background application; it relies heavily on low-level system Minifilter Drivers (File System Minifilter Drivers) to mount Xbox Virtual Disks (XVD).

Tracing down the underlying driver dependencies revealed that while the base block device driver xvdd.sys was functioning normally, the dedicated gaming filter driver gameflt.sys threw a 1060 error indicating it was not installed. It appeared that a Windows Update had inadvertently dropped or corrupted the registry entries for the gameflt driver. Consequently, when the service initialized and made a kernel-level call to this filter driver, it received no response, trapping it in an infinite blocking loop.

Solution

Since the deadlock was caused by a missing driver hanging the process, the fix required addressing the driver dependency directly:

1. Break the deadlock and release the handles: Forcefully terminate the frozen processes.
   taskkill /F /IM GamingServices.exe /T taskkill /F /IM GamingServicesNet.exe /T
2. Recover the native driver from the Driver Store: Navigate to C:\Windows\System32\DriverStore\FileRepository and search for gameflt.inf. Use the built-in package manager to force-reinject it into the kernel:
   pnputil /add-driver "ABSOLUTE_PATH_TO_YOUR_GAMEFLT.INF" /install
3. Initialize the kernel driver and restart the services:
   sc start gameflt sc start GamingServicesNet sc start GamingServices

Upon launching the Xbox App, it initialized instantly and loaded normally.

Conclusion

When executing service operations under SYSTEM privileges yields an Error 5, the service is highly likely trapped in a START_PENDING state. When dealing with UWP applications that are deeply integrated into the OS architecture (such as Xbox components featuring virtual disk logic) and stuck in a deadlock, instead of troubleshooting permissions or reinstalling at the application layer, it is far more effective to audit downstream .sys kernel driver dependencies.