WSL2 VM launch fails with Wsl/Service/E_UNEXPECTED across 4 independently-verified fixes + reboots (RTX 5070, MSIX package)

Nobody has claimed this yet.

## Windows Version

Microsoft Windows [Version 10.0.26200.8875] (Windows 11 Home Single Language)

## WSL Version

```
WSL version: 2.7.11.0
Kernel version: 6.18.33.2-2
WSLg version: 1.0.73.2
MSRDC version: 1.2.7214
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26200.8875
```

WSL installed via MSIX Store package (`Microsoft.WSL`).

## Distro Version

`Ubuntu` and `docker-desktop` registered (`wsl -l -v` shows both), both WSL2.

## Other Software

- Hardware: NVIDIA RTX 5070 GPU
- No third-party AV/EDR (Windows Defender only)
- No Group Policy Hyper-V restrictions
- No conflicting virtualization software (VMware/VirtualBox/Parallels) installed

## Repro Steps

1. `wsl -d Ubuntu` (or any command that launches an actual WSL2 VM instance — `wsl --status` alone does not always trigger it, but any real distro boot does)

## Expected Behavior

Distro boots and the command executes inside it.

## Actual Behavior

Every command that launches a WSL2 VM instance fails identically:

```
Catastrophic failure
Error code: Wsl/Service/E_UNEXPECTED
```

`wsl.exe`/`wsl --version` itself works fine (prints version info as above) — only the actual lightweight-VM launch step fails.

## Diagnostic Logs

Not yet attached — will attach a `wsl --status`/Feedback Hub diagnostic collection if requested, since the standard collector wasn't run before this report (happy to run it and follow up).

## 4 independently-verified fixes attempted — each followed by a full reboot, each verified via `Get-*`/registry checks pre- and post-change, **none changed the symptom at all**:

1. **Service-level**: cycled `vmcompute`/`hns`/`HvHost` services (elevated). Result: error briefly changed to a network-endpoint-allocation conflict on one retry, then reverted to the same `E_UNEXPECTED` after reboot.
2. **Missing Windows feature**: discovered `HypervisorPlatform` optional feature was **Disabled** while `VirtualMachinePlatform` and `Microsoft-Windows-Subsystem-Linux` were both Enabled. Enabled it via `Enable-WindowsOptionalFeature` (confirmed `RestartNeeded: True`, confirmed `State: Enabled` post-run). Rebooted. **No change** — identical error.
3. **Core Isolation / Memory Integrity**: found `HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity` = 1 (Enabled) — a known conflict source with WSL2 GPU (WSLg) passthrough on some NVIDIA setups. Disabled it (registry `Enabled` -> 0, confirmed). Rebooted. **No change** — identical error.
4. **Full MSIX package purge + clean reinstall**: `wsl --uninstall`, then discovered `winget` still saw the package registered (inconsistent state) — force-removed via `Remove-AppxPackage -AllUsers` + attempted `Remove-AppxProvisionedPackage` (provisioning already gone), confirmed `Get-AppxPackage` returned nothing, then fresh `winget install --id Microsoft.WSL` succeeded cleanly ("Successfully installed"). Rebooted (per the installer's own on-screen note that a restart is required). **No change** — identical error, and the pre-existing distro registrations (`Ubuntu`, `docker-desktop`) survived the uninstall/reinstall intact (visible in `wsl -l -v`), so this wasn't a fresh-distro state either.

## Ruled out

- Third-party antivirus/EDR: only Windows Defender registered in Security Center.
- Group Policy Hyper-V restriction: `HKLM:\SOFTWARE\Policies\Microsoft\Windows\HyperV` — no policy keys present.
- Conflicting third-party virtualization software: none installed, no matching processes running.
- BIOS/firmware virtualization disabled: `systeminfo` reports "A hypervisor has been detected" (VT-x/AMD-V enabled and functional at the firmware level).

## Open, unexplained anomaly

`Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard` returns **empty/null** — no VBS status object at all, which is atypical even when VBS is off (it normally still returns a status of 0). This may indicate the Device Guard / VBS WMI provider itself is in a broken state, possibly entangled with why WSL2's VM launch (which depends on the same virtualization-security stack) fails identically regardless of the OS-level toggles above.

Given 4 substantively different, individually-verified fixes (service state / missing feature / security setting / full package reinstall) all produced the exact same, byte-identical error across separate reboots, this looks like either (a) a corrupted low-level virtualization/security component that no user-space fix can reach, or (b) a genuine WSL/Windows interaction bug on this specific hardware/driver combination (RTX 5070 + WSLg GPU passthrough).

Would appreciate guidance on:
- Whether the empty `Win32_DeviceGuard` WMI result is a known symptom of something specific.
- Any deeper diagnostic (event trace, `wpr`/ETW capture) that would surface where in the launch sequence it actually fails, since `wsl --status`/service logs give no more detail than the top-level error code.

Start by reproducing the failure with `wsl -d Ubuntu` and compare it with `wsl --status`, then inspect the reported `Win32_DeviceGuard` result. The issue suggests collecting WSL/Feedback Hub diagnostics or a `wpr`/ETW trace; done would mean identifying where the WSL2 VM launch fails and documenting evidence for a fix or escalation.

Written by the indexing model from the issue text.