WSL Service Crashes During VM Creation on Windows 11 25H2 (Build 26200.7171)

[Dev4YM]

Windows Version

Microsoft Windows [Version 10.0.26200.7171]

WSL Version

2.6.1.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

No response

Distro Version

No response

Other Software

OS: Windows 11 Home (Official Stable Release)
Version: 25H2
Build: 26200.7171
WSL Version: 2.6.1.0
System: MSI MS-7E06, Intel Core (Model 183), 64GB RAM
Previously Installed Virtualization Software: VirtualBox and VMware (completely uninstalled)

Repro Steps

Repro Steps

1. Open PowerShell as Administrator
2. Run wsl --install -d Ubuntu-24.04 (or any other distribution)
3. Wait for download to complete
4. Observe installation attempt

Alternative methods attempted (all fail identically):

• wsl --install (default Ubuntu)
• wsl --install -d Ubuntu-22.04
• wsl --install -d Debian
• Installing from Microsoft Store (Ubuntu 24.04, 22.04, 20.04, Debian)
• Manual download and AppX installation

Reproducibility: 100% - Fails every single time across all distributions and installation methods

Expected Behavior

Expected Behavior

Based on official documentation (https://learn.microsoft.com/en-us/windows/wsl/install):

1. WSL should download the selected Linux distribution
2. WSL should register the distribution
3. WSL should create a Hyper-V VM for the distribution
4. The distribution should launch and prompt for user setup
5. Command should complete successfully with the distribution installed and ready to use

Example of expected successful output:

Downloading: Ubuntu 24.04 LTS
Installing: Ubuntu 24.04 LTS
Ubuntu 24.04 LTS has been installed.
Launching Ubuntu 24.04 LTS...

Actual Behavior

Actual Behavior

The installation process fails during VM creation with the following error:

Downloading: Ubuntu 24.04 LTS
Installing: Ubuntu 24.04 LTS
An address incompatible with the requested protocol was used.
Error code: Wsl/InstallDistro/Service/RegisterDistro/CreateVm/0x8007273f

What happens behind the scenes:

• Download completes successfully
• Initial registration begins
• WSL Service (wslservice.exe) crashes during CreateVm operation
• Installation rolls back
• No distribution is installed

Event Log Evidence:

Event ID: 7034
Source: Service Control Manager
Level: Error
Message: The WSL Service service terminated unexpectedly.

Event ID: 1000
Source: Application Error
Level: Error
Message: Faulting application name: wslservice.exe, version: 2.6.1.0

Diagnostic Logs

Error Details

Error Message

An address incompatible with the requested protocol was used.
Error code: Wsl/InstallDistro/Service/RegisterDistro/CreateVm/0x8007273f

Event Log Evidence

ProviderName: Service Control Manager
TimeCreated: 11/12/2025 10:39:02 PM
Id: 7034
Level: Error
Message: The WSL Service service terminated unexpectedly.

ProviderName: Application Error
Id: 1000
Level: Error
Message: Faulting application name: wslservice.exe, version: 2.6.1.0

System Verification - All Tests Pass

Virtualization Status

# All services running correctly
Get-Service vmcompute          # Status: Running
Get-Service HvHost             # Status: Running
Get-Service LxssManager        # Status: Running

# All required features enabled
Get-WindowsOptionalFeature -Online
VirtualMachinePlatform         # State: Enabled
HypervisorPlatform            # State: Enabled

# Hypervisor configured correctly
bcdedit /enum | findstr hypervisorlaunchtype
# Output: hypervisorlaunchtype Auto

# Virtualization-based Security active
systeminfo | findstr /C:"Hyper-V"
# Output: A hypervisor has been detected. Features required for Hyper-V will not be displayed.

# VBS running correctly
Get-CimInstance -ClassName Win32_DeviceGuard
VirtualizationBasedSecurityStatus: 2 (Running)

System Integrity - No Corruption Found

# Windows image health check
Dism /Online /Cleanup-Image /CheckHealth
# Result: The component store is repairable.

Dism /Online /Cleanup-Image /ScanHealth
# Result: No component store corruption detected.

Dism /Online /Cleanup-Image /RestoreHealth
# Result: The restore operation completed successfully.

# System file verification
sfc /scannow
# Result: Windows Resource Protection did not find any integrity violations.

Extensive Troubleshooting Attempted

Network Stack Resets

netsh winsock reset
netsh int ip reset all
netsh winhttp reset proxy
# Restarted after each - No effect

WSL Reinstallation Attempts

# Tried default installation
wsl --install

# Tried specific distributions
wsl --install -d Ubuntu-24.04
wsl --install -d Ubuntu-22.04
wsl --install -d Debian

# Attempted WSL updates
wsl --update
wsl --update --web-download
wsl --update --pre-release

# Attempted version switching
wsl --set-default-version 2
wsl --set-default-version 1  # Failed: WSL_E_WSL1_NOT_SUPPORTED

Windows Feature Management

# Disabled and re-enabled all WSL/Hyper-V features
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All
Disable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
# Restarted

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All
Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
# Restarted

# Also tried via DISM
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
dism.exe /online /enable-feature /featurename:HypervisorPlatform /all /norestart
# Restarted

Attempted Installations from Multiple Sources

• Command line (wsl --install)
• Microsoft Store (Ubuntu 24.04, 22.04, 20.04, Debian)
• All methods result in identical crash

Configuration Adjustments

• Removed experimental .wslconfig settings (mirrored networking)
• Disabled Norton VPN and network adapter
• Verified no conflicting virtualization software remains

Registry Verification

Get-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss"
# NatIpAddress: 172.25.19.120
# DefaultVersion: 2
# No abnormalities detected

What Does NOT Work

❌ Any wsl --install command (all distributions)
❌ Microsoft Store installations
❌ Network stack resets
❌ Feature disable/enable cycles
❌ WSL service restarts
❌ System integrity repairs (DISM/SFC)
❌ Removing .wslconfig configuration
❌ WSL updates

Observations

1. WSL Service crashes specifically during CreateVm operation - All pre-VM steps succeed (download, initial registration)
2. Hyper-V infrastructure is fully functional - vmcompute and HvHost services run normally
3. System passes all integrity checks - No corruption detected by Microsoft's own tools
4. Error is reproducible 100% of the time across all distributions and installation methods
5. Issue appears specific to Windows 11 25H2 (Build 26200.7171) - This is the official stable release from November 11, 2025

Similar Reports

Other users have reported similar issues that only resolved after clean Windows reinstallation, suggesting a system-level bug in Windows 11 25H2 that integrity tools cannot detect or repair.

Request

This appears to be a genuine bug in Windows 11 25H2 build 26200.7171 affecting WSL VM creation despite perfect system configuration. The WSL service crash during CreateVm suggests an issue with the Hyper-V integration layer specific to this build.

Please do not suggest:

• Network resets (already attempted)
• Feature reinstallation (already attempted multiple times)
• DISM/SFC repairs (completed with no issues found)
• Virtualization software conflicts (all removed)
• Basic troubleshooting steps (exhaustively tested)

Requested:

• Acknowledgment of this as a known issue in build 26200.7171
• Timeline for potential fix or workaround
• Any advanced diagnostic steps specific to WSL service crashes during VM creation
• Alternative solutions that don't require Windows reinstallation

Additional Information Available

• Full event logs from WSL service crashes
• Detailed vmcompute service logs
• Complete system configuration details
• Registry dumps of WSL-related keys

Thank you for your attention to this issue.

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use collect-networking-logs.ps1, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[Dev4YM]

WslLogs-2025-11-14_00-07-32.zip

[github-actions]

Diagnostic information

Appx package is not installed
Detected user visible error: Wsl/InstallDistro/Service/RegisterDistro/CreateVm/0x8007273f

[OneBlue]

@YousefTurky: It's looking like the Hyper-V socket provider isn't available on your machine. I can see it being referenced under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinSock2\Parameters\Protocol_Catalog_Before_Reset\Catalog_Entries\00000000000 (which looks like a registry backup), but it's not available to WSL, which is what's causing this error.

I would expect the error to go away if you restore that registry key

[Dev4YM]

Sorry, but can u provide or guide on how to reset that registry key SAFELY.

[OneBlue]

The easiest way would be to restore the content of Protocol_Catalog_Before_Reset, but I don't know who / what create that key in the first place, that would be for you to figure out.

You can backup the entire key before making changes if you want to be able to undo changes though.

[Dev4YM]

Hey, quick update on what I tried:

I followed your advice about the Winsock registry provider and attempted to restore it safely.

1. Backed up the Winsock2 Parameters key

2. Exported and restored the Protocol_Catalog_Before_Reset key

3. Rebooted afterwards

4. Verified the active Winsock catalog using:

   netsh winsock show catalog
   

   Everything shows normal TCP/UDP/IPv4/IPv6/MSAFD entries, and Winsock itself looks intact.

Afterwards, I checked the registry, and noticed that Windows 11 (my build is 26200 Home) no longer uses the old Protocol_Catalog key.
It uses Protocol_Catalog9 instead, and both Catalog_Entries and Catalog_Entries64 exist with 13 providers each.

So the registry side seems clean.

Then I tried installing WSL again:

wsl --install

And I got the same error:

An address incompatible with the requested protocol was used.
Error code: Wsl/InstallDistro/Service/RegisterDistro/CreateVm/0x8007273f

So at this point, the Winsock catalog looks correct, and restoring the backup didn’t change the outcome. The issue still appears to be related to the WSL VM creation step rather than the catalog itself.

[Dev4YM]

Update with new findings:

Just wanted to follow up with some new observations after more testing.

I was able to successfully create and run a distro using WSL 1, and it provisions normally with no errors:

wsl -d Ubuntu
Provisioning the new WSL instance Ubuntu
...
Welcome to Ubuntu 24.04.3 LTS (GNU/Linux 4.4.0-26100-Microsoft x86_64)

This confirms that:

• WSL1 itself works
• Winsock networking is working correctly
• Registry/Winsock catalog is healthy
• The distro setup process is not failing
• VM-free execution (WSL 1) is fully functional

However, WSL 2 still fails with the same VM-creation error:

An address incompatible with the requested protocol was used.
Error code: Wsl/InstallDistro/Service/RegisterDistro/CreateVm/0x8007273f

The key point is:

✔️ WSL 1 works

❌ WSL 2 cannot create its VM

Also, to clarify:
I am not on an Insider build — my Windows version is a fully official retail release, not Dev/Canary/Beta.

Given that WSL 1 is working and only the Hyper-V–based VM creation is failing, it appears that the Hyper-V virtualization stack is either unavailable or not being detected, which is preventing WSL 2 from initializing its VM even though this Windows edition normally supports it.

Happy to provide additional logs or run any diagnostics if needed.

[OneBlue]

Unfortunately the error message most likely indicates that the hvsocket protocol provider is incorrectly configured. WinSock working with TCP/IP is unrelated to hvsockets so that doesn't say much.

One thing you could try would be to disable hyper-V & virtual machine platform, reboot, and enable it again. Maybe that will reset the hvsocket provider correctly, but if that doesn't work, you'll probably need to dig in the registry to figure out what's missing

[Dev4YM]

Thanks for the explanation.

I’ve already tried disabling and re-enabling both Hyper-V and VirtualMachinePlatform many times — including a full disable → reboot → enable → reboot cycle again today. Unfortunately it didn’t change the behavior, and the hvsocket error persists.

Regarding digging into the registry for the hvsocket provider:
I’m not familiar with the internal structure of the Hyper-V / WSL Winsock providers, since I didn’t develop WSL or the virtualization stack. I’m not sure which keys, GUIDs, or catalog entries the hvsocket provider is expected to have on this build, so I don’t have enough information to validate what’s correct vs missing. I don’t want to guess and risk corrupting my networking stack.

Ideally, the WSL health-check / diagnostic tooling should be able to detect and report when the hvsocket provider is misconfigured or missing, since this seems like the kind of issue it’s meant to surface.

If there’s a specific set of registry paths, GUIDs, or expected provider entries that I should verify, I’m happy to check them — I just need the exact locations and what values should or shouldn’t be present.