Update — clarifying the prior occurrence, and new diagnostic findings
Important context I should have included from the start: this exact symptom happened once before, on the 26H2 Insider Release Preview channel (see linked thread). I resolved it at the time with a clean reinstall back to 25H2. It has now recurred on this same 25H2 install after normal Windows Update servicing.
Since the prior fix was a genuinely clean reinstall — not a rollback or in-place reset — nothing should have carried over from the earlier occurrence (no leftover drivers, third-party software, or profile state). That means this reproduced from a stock 25H2 image, purely through subsequent Windows Update activity. That points toward one of two things: either something Windows Update itself reintroduces across builds/channels, or a hardware/firmware/driver interaction specific to this machine that gets reinstalled automatically post-setup and conflicts with Explorer's modern extension activation. I can't distinguish between those two from software diagnostics alone.
Diagnostic findings since the original post:
-
explorer.exe's loaded modules were inspected directly. It loadsMicrosoft.UI.Xaml.dllandWindows.Internal.UI.Shell.WindowTabManager.dll, but never loadsFileExplorerManaged.dll,FileExplorerExtensions.dll, or anyMicrosoft.WindowsAppRuntimemodule — despite all being installed,Status: Ok, and correctly declared in FileExp's manifest. Explorer simply never attempts to activate its own manifested extensions at startup; nothing is missing or corrupted. - Feature ID
54792954(WholeExplorerProcessRunOnWASDKCBS16) tested directly via ViVeTool: no override present; explicitly enabling it and rebooting produced no change. Ruled out. -
sfc /scannowandDISM /RestoreHealth: both clean, no corruption found. - The specific KB timing (KB5124010) can no longer be confidently tied to onset — event-log retention doesn't reach far enough back to confirm exactly when the regression started relative to that update.
- Separately, but possibly relevant: KB5124010 cannot be removed from this machine at all. Both
DISM /Online /Remove-Packageand Settings → Update History → Uninstall fail identically withHRESULT = 0x800f0905 (CBS_E_NO_ACTIVE_EDITION). CBS.log shows removal is blocked because it would force several edition/version-identity wrapper packages to an Absent state, which CBS refuses to finalize.
Given that a clean reinstall didn't prevent recurrence, I'd especially welcome input on: whether anyone else has hit this reproducing from a stock 25H2 install after normal servicing, and whether there's a known driver or hardware-specific factor tied to explorer.exe failing to activate its own WinAppSDK extensions.