WSL error 0x80370102 displays “The virtual machine could not be started because a required feature is not installed.” It means the WSL 2 virtual machine cannot launch because a virtualization prerequisite is missing or disabled. The error can occur while installing, registering, converting, or starting a distribution on Windows 11 or an eligible Windows 10 build. First determine whether Windows is running on a physical PC or inside a virtual machine; on a physical PC, the safest first action is to enable Virtual Machine Platform if necessary and complete the required restart.

What WSL error 0x80370102 means

The same failure may appear as WslRegisterDistribution failed with error: 0x80370102, Wsl/Service/CreateInstance/CreateVm/0x80370102, or a message asking you to enable Virtual Machine Platform and virtualization in BIOS. These are equivalent WSL 2 virtualization-startup fingerprints, not separate errors.

WSL itself or the Linux distribution may already be installed. The failure occurs because the WSL 2 virtual machine cannot start. It does not, by itself, establish that the distribution is corrupt.

Windows context First prerequisite to examine
Physical PC Virtual Machine Platform, followed by firmware virtualization
Older physical hardware CPU support for Second Level Address Translation (SLAT)
Windows inside a Hyper-V VM Nested virtualization exposed by the parent host
Applicable prerequisites already confirmed Windows hypervisor launch configuration

Microsoft documents this error and its prerequisite branches in Microsoft’s WSL troubleshooting guidance. The current WSL installation context requires Windows 10 version 2004 or later or Windows 11. Microsoft’s manual setup documentation also lists limited older Windows 10 build thresholds, including version 1903 x64 build 18362.1049 or later. Technical build eligibility does not establish that a Windows 10 release remains within its current support lifecycle.

Fix 0x80370102 on a physical Windows PC

Enable Virtual Machine Platform and restart

When this applies: Use this path on a physical PC when Virtual Machine Platform is not already known to be enabled. The supplied official procedure does not include a separate feature-verification command; if the component has already been enabled and Windows was restarted afterward, continue to the firmware virtualization check.

Prerequisites: You need administrator access and a Windows version that supports WSL 2. Microsoft’s documented build limits and command are available in Microsoft’s manual WSL installation requirements.

  1. Open PowerShell as Administrator.
  2. Run dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart.
  3. Restart the computer. The restart is required before the component becomes active.
  4. Retry the WSL installation, distribution registration, WSL 2 conversion, or distribution launch that produced 0x80370102.

Expected result: Windows activates the Virtual Machine Platform component so WSL 2 can use it. Another unavailable prerequisite can still prevent the virtual machine from starting.

Risk and rollback: This is a low-risk Windows feature change and does not delete distribution data. Administrator access is required. If necessary, disable the Virtual Machine Platform feature to return to the previous feature state; no unverified disable command is provided here.

Enable firmware virtualization in BIOS or UEFI

When this applies: Use this path on a physical PC if Virtual Machine Platform is enabled, the required Windows restart was completed, and error 0x80370102 continues.

Prerequisites: Obtain the BIOS or UEFI instructions for the exact PC or motherboard. Firmware menu names and access methods vary by manufacturer, so universal key sequences or menu labels are not reliable.

  1. Open the PC’s firmware settings by following the manufacturer’s instructions.
  2. Enable CPU virtualization support in BIOS or UEFI.
  3. Save the firmware change and exit setup.
  4. Restart Windows.
  5. Retry the WSL 2 operation.

Expected result: Windows can use the processor’s virtualization capability, provided that the CPU also supports SLAT and no other applicable prerequisite is missing.

Risk and rollback: This is a medium-risk firmware change. Record the original setting because virtualization changes may affect other hypervisors or security configurations. To roll back, re-enter the firmware interface and restore the previous virtualization setting.

Confirm that the CPU supports SLAT

When this applies: Check this requirement when the device may be too old for WSL 2 or when enabling the documented Windows and firmware settings does not resolve the startup failure.

Prerequisite: You need access to Windows system information or authoritative specifications for the installed processor.

  1. Identify the processor and check whether it supports Second Level Address Translation, or SLAT.
  2. Confirm the capability through Windows system information or authoritative hardware specifications rather than assuming that every 64-bit CPU supports it.
  3. If the processor is older than Intel Nehalem or AMD Opteron and lacks the required capability, stop attempting to force WSL 2 and consider the WSL 1 fallback.

Expected result: This check distinguishes a configurable virtualization problem from unsupported hardware. Firmware changes cannot add SLAT to a processor that lacks it.

Risk and rollback: This is a read-only, low-risk diagnostic and makes no system change.

Fix 0x80370102 when Windows is running in a Hyper-V VM

When Windows is itself a Hyper-V guest, enabling virtualization settings inside that guest is not sufficient. The parent Hyper-V host must expose virtualization extensions to the guest. This branch requires host access and does not apply automatically to third-party or cloud hypervisors.

When this applies: Use this path only when WSL 2 is running inside a Windows Hyper-V virtual machine.

Prerequisites: You need administrator access on the parent Hyper-V host and the actual name of the Windows guest VM.

  1. On the parent Hyper-V host, open PowerShell as Administrator.
  2. Run Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true.
  3. Replace <VMName> with the actual guest name; do not enter the placeholder literally.
  4. Start or restart the Windows guest.
  5. Retry WSL 2 inside the guest.

Expected result: The parent host exposes the virtualization extensions WSL 2 needs inside the guest. Microsoft explains this host requirement in Microsoft’s Hyper-V nested virtualization documentation.

Risk and rollback: This is a medium-risk VM processor configuration change. To remove the exposed extensions, run the same command on the parent host with $false instead of $true. Do not apply this Hyper-V command to another virtualization platform. For a third-party hypervisor, consult its current, version-specific compatibility documentation.

Check hypervisor launch configuration if prerequisites are enabled

When this applies: Use this advanced branch only after confirming the applicable Windows feature, required restart, firmware virtualization, SLAT support, and nested-virtualization requirement. It applies when WSL 2 still cannot create its virtual machine because Windows is configured not to launch the hypervisor.

Prerequisite: Administrator access is required. Changing this setting can affect software that depends on a different Windows hypervisor state.

  1. Open PowerShell as Administrator.
  2. Run bcdedit /enum | findstr -i hypervisorlaunchtype.
  3. If the result shows Off, run bcdedit /set hypervisorlaunchtype Auto.
  4. Restart Windows.
  5. Retry the WSL 2 operation that failed.

Expected result: When the value was previously Off, Windows can launch the hypervisor during startup. This does not overcome unsupported SLAT or unavailable nested virtualization.

Risk and rollback: This is a medium-risk boot configuration change. If the prior state must be restored, set hypervisorlaunchtype back to Off and restart Windows.

Use WSL 1 when WSL 2 is unavailable

When this applies: Use WSL 1 as a fallback only when the hardware cannot support WSL 2 or when the virtual-machine provider cannot make nested virtualization available. It is not the primary fix for a disabled prerequisite that can be enabled safely.

Prerequisites: WSL must be installed, and the distribution must already be present or installable. If an existing distribution contains data that matters, export or back it up before conversion. The exact backup and conversion commands are intentionally omitted because they were not supplied in the confirmed procedure.

  1. Export or otherwise back up the existing distribution when preservation matters.
  2. Set the distribution to WSL 1 instead of WSL 2 by following the current Microsoft WSL documentation.
  3. Continue using the distribution with WSL 1 limitations in mind.

Expected result: The distribution uses WSL 1 rather than the WSL 2 virtual-machine architecture. WSL 1 is not functionally identical to WSL 2, so review the current Microsoft WSL documentation for feature and compatibility differences before selecting this fallback.

Risk and rollback: The fallback is low risk when distribution data has been preserved. If WSL 2 prerequisites become available later, the distribution can be converted back to WSL 2 after another backup.

What to collect if error 0x80370102 continues

If every applicable prerequisite is already confirmed and the error remains, collect evidence before escalating. This helps distinguish a Microsoft Windows problem from a firmware, processor, or virtualization-host limitation.

  • The exact error code and complete message, including any WslRegisterDistribution or CreateInstance/CreateVm text.
  • The Windows edition, version, and build.
  • Whether Windows runs on physical hardware or inside a virtual machine.
  • Whether Virtual Machine Platform was enabled and whether the required restart was completed.
  • Whether firmware virtualization is enabled on a physical PC.
  • The processor model and the authoritative source used to confirm SLAT support.
  • For a virtual machine, the parent hypervisor and whether virtualization extensions were exposed.
  • The reported hypervisorlaunchtype value and whether it was changed.
  • The failed action: WSL installation, distribution registration, launch, or conversion from WSL 1 to WSL 2.

Escalate to Microsoft for a Windows or WSL failure after all requirements are confirmed, to the device manufacturer for firmware or processor questions, or to the virtualization provider when nested virtualization is unavailable. Do not reset, unregister, or reinstall the distribution solely for this error: the supplied official evidence does not confirm those potentially disruptive actions as remedies.

Avoid unsupported fixes

  • Do not use undocumented registry edits.
  • Do not assume enabling Hyper-V alone replaces Virtual Machine Platform, firmware virtualization, SLAT, or nested virtualization.
  • Do not make blanket Hyper-V feature or service changes unrelated to the diagnosed prerequisite.
  • Do not skip the restart after enabling Virtual Machine Platform or changing firmware virtualization.
  • Do not continue forcing WSL 2 on a processor without SLAT.

Different Windows errors

If the code is not 0x80370102, use an error-specific guide instead. See Windows Update access-denied troubleshooting for update error 0x80070005 or AppX/MSIX deployment resource-lock troubleshooting for Add-AppxPackage error 0x80073D02. Neither procedure applies to this WSL 2 virtualization error.