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.

Background

I recently installed PowerToys (v0.96) on a fresh Windows 10 22H2 (Build 2009, 19045.6456). However, PowerRename was completely missing from both the standard context menu and the Shift+Right-click menu.

I attempted all the standard troubleshooting steps:

1. Checked registry settings, restarted the system/Explorer—no luck.
2. Reinstalled the software, and even rolled back to v0.88 and v0.7x (older architecture versions)—still no luck.
3. Checked with ShellExView: PowerRenameContextMenu Class status showed as Enabled (Green).

This was extremely weird: the registry said it was enabled, the files were present, but the menu just wouldn’t show up.

The problem wasn’t the software itself, but Windows’ “fault isolation” mechanism. Here is the investigation process.

Investigation

Since ShellExView showed the extension as enabled, the standard registry entries were likely fine. I suspected that Windows Explorer was somehow “refusing” to load it.

I used Process Explorer to search for handles or DLLs related to PowerRename.

Caption: Searching for “PowerRename” in Process Explorer. The result shows that only PowerToys.exe loaded PowerToys.PowerRenameExt.dll.

The phenomenon is clear: Explorer was not loading this DLL at all.

Root Cause Analysis

Windows Explorer has a protection mechanism: if a Shell Extension causes Explorer to crash, hang, or time out during loading (which might happen during a conflict at the moment of installation), Windows will silently add the extension’s CLSID to a system-level “Blocklist”.

Once on this list, Explorer will permanently ignore the extension, regardless of how many times you reinstall the software (since uninstallers usually don’t dare touch the system-level Blocked registry key).

Solution

Check the Shell Extension Blocklist in the registry.

Navigate to:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Shell Extensions\Blocked

The CLSID for PowerRename is exactly {0440049F-D1DC-4E46-B27B-98393D79486B}.

Simply delete this key value and restart Explorer.

If File Locksmith is missing, check for {E5235BAE-8628-4E57-9694-D1F3780D21B7} in the same location.

Summary

If reinstalling doesn’t work and ShellExView shows the extension as Enabled, it is likely trapped in Windows Shell Extensions\Blocked. Instead of wasting time on software configurations, check the registry blocklist directly.