Erreur 0x80370102 WSL : installation d’Ubuntu impossible – solutions complètes (Windows 10/11)

Vous tentez d’installer Ubuntu depuis le Microsoft Store et tombez sur l’erreur 0x80370102 liée à WSL 2 ? Voici un guide complet, clair et actionnable pour rétablir la virtualisation Hyper‑V et finaliser l’installation en toute sécurité.

Sommaire

Erreur 0x80370102 lors de l’installation d’Ubuntu sous WSL

Vue d’ensemble de la question

Sur Windows 10/11, l’installation d’Ubuntu via le Microsoft Store échoue avec le message :

WslRegisterDistribution failed with error: 0x80370102
Please enable the Virtual Machine Platform Windows feature and ensure virtualization is enabled in the BIOS.

L’utilisateur a déjà :

activé Intel VT‑x/AMD‑V et VT‑d dans le BIOS / UEFI ;
coché Hyper‑V et Virtual Machine Platform dans « Activer ou désactiver des fonctionnalités Windows ».

Malgré cela, l’erreur persiste.

Pourquoi cette erreur apparaît

WSL 2 fonctionne à l’aide d’un hyperviseur de type 1 (Hyper‑V) fourni par Windows. Si l’hyperviseur ne démarre pas correctement au boot, si la fonctionnalité Virtual Machine Platform (VMP) est endommagée, si une mise à jour de BIOS a réinitialisé les options de virtualisation, ou si un autre moteur de virtualisation en conflit monopolise le matériel (cas de certains VMware/VirtualBox anciens), le noyau WSL ne peut pas créer la machine virtuelle légère nécessaire : l’enregistrement de la distribution échoue et WSL renvoie 0x80370102.

Les causes les plus fréquentes sont :

Hyperviseur désactivé au démarrage (paramètre bcdedit resté sur off après un outil de virtualisation tiers).
Fonctionnalités Windows incohérentes (VMP/Hyper‑V partiellement installées, composants corrompus).
Virtualisation firmware réinitialisée (mise à jour UEFI qui remet VT‑x/AMD‑V à Disabled).
Conflits d’hyperviseur (VMware, VirtualBox < 6.0, solutions d’endpoint security avec pilotes de virtualisation).
Pré‑requis WSL 2 non respectés (noyau WSL non à jour, build Windows trop ancienne, pilotes chipset obsolètes).

Checklist express

Si vous voulez aller droit au but, suivez cette séquence dans l’ordre :

Réinitialisez Hyper‑V/VMP via « Fonctionnalités Windows » (désactiver → redémarrer → réactiver → redémarrer).
Forcez le démarrage de l’hyperviseur : bcdedit /set hypervisorlaunchtype auto (invite CMD ou PowerShell en administrateur) puis redémarrez.
Vérifiez WSL : wsl --status, wsl --set-default-version 2, puis installez wsl --install -d Ubuntu.
Mettez à jour WSL : wsl --update, puis wsl --shutdown et relancez.
Écartez les conflits : fermez/désinstallez temporairement VMware/VirtualBox anciens.
Réparez Windows en cas d’échec persistant : DISM + SFC.

Procédure détaillée et pas‑à‑pas

Contrôles préliminaires rapides

Ouvrez Gestionnaire des tâches → Performances → Processeur : la ligne Virtualisation doit afficher Activée.
Dans Paramètres Windows → Confidentialité et sécurité → Sécurité Windows → Sécurité de l’appareil, vérifiez Isolation du noyau / Intégrité de la mémoire. Si un antivirus tiers installe des pilotes incompatibles, testez en la désactivant temporairement (puis redémarrage).
Lancez MSInfo32 (Win+R → msinfo32) et confirmez : Prise en charge de la virtualisation basée sur l’API / Virtualisation activée dans le microprogramme : Oui.

Réinitialiser proprement la pile Hyper‑V

Ouvrez Activer ou désactiver des fonctionnalités Windows (Win → tapez « fonctionnalités »).
Décochez : Hyper‑V et Plateforme machine virtuelle. Si disponible, décochez aussi Plateforme d’hyperviseur Windows et Sous-système Windows pour Linux.
Redémarrez.
Rouvrez le même panneau et recochez :
- Plateforme machine virtuelle (obligatoire WSL 2),
- Sous-système Windows pour Linux,
- Hyper‑V (optionnel sur Windows Home : l’interface peut ne pas exister, ce n’est pas bloquant).
Redémarrez de nouveau.

Forcer le lancement de l’hyperviseur au boot

Ouvrez une Invite de commandes (Admin) ou PowerShell (Admin) et exécutez :

bcdedit /set hypervisorlaunchtype auto

Vous pouvez vérifier l’état avec :

bcdedit /enum {current} | findstr /i hypervisorlaunchtype

Redémarrez la machine après modification.

Vérifier, mettre à jour et (ré)installer WSL

wsl --status
wsl --set-default-version 2
wsl --update
wsl --list --online
wsl --install -d Ubuntu

Si une distribution précédente est marquée « Installé » mais inutilisable, désenregistrez‑la avant de recommencer :

wsl --list --verbose
wsl --unregister Ubuntu

Pensez aussi à réinitialiser le runtime WSL après mise à jour :

wsl --shutdown

Contrôler les prérequis matériel/logiciel

Windows 10 build 18362 (1903) ou ultérieure / Windows 11 à jour.
BIOS / UEFI : VT‑x/AMD‑V et, si disponible, VT‑d activés.
Micrologiciel CPU / pilotes chipset : installez les dernières révisions du fabricant (surtout après une mise à niveau majeure de Windows).
Postes gérés en entreprise : Device Guard/Credential Guard ou des GPO peuvent forcer des modes Hyper‑V particuliers. Si vous n’avez pas les droits, faites valider la configuration par l’équipe IT.

Éliminer les conflits d’hyperviseur

Fermez tout hyperviseur non Microsoft : VMware Workstation/Player, VirtualBox < 6.0, solutions de sandboxing. VirtualBox 6+ sait cohabiter avec Hyper‑V, mais certains modules ou extensions anciennes peuvent perturber le démarrage de l’hyperviseur Microsoft. Au besoin, désinstallez temporairement, redémarrez, testez WSL, puis réinstallez la version la plus récente.

Réparer les fonctionnalités Windows en cas d’échec persistant

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

Puis répétez le cycle de réinstallation des fonctionnalités (désactiver → redémarrer → réactiver → redémarrer).

Tableau récapitulatif des solutions

Étape	Action	Détails
Réinitialiser la pile Hyper‑V	Désactiver puis réactiver les fonctionnalités	Ouvrir « Fonctionnalités Windows ». Décochez « Hyper‑V » et « Plateforme machine virtuelle ». Redémarrez. Rouvrez le même panneau, cochez de nouveau les deux cases, puis redémarrez.
Forcer le lancement de l’hyperviseur	`bcdedit /set hypervisorlaunchtype auto` (invite CMD admin)	Garantit que le service Hyper‑V démarre dès le boot.
Vérifier la configuration WSL	`wsl --list --online` puis `wsl --install <distro>`	Confirmez que WSL 2 est disponible : `wsl --set-default-version 2`. Si une distribution est corrompue, exécutez `wsl --unregister <distro>` avant de la réinstaller.
Contrôler les prérequis matériel/logiciel		Windows 10 v1903 (build 18362) ou version ultérieure. Mise à jour du BIOS / UEFI et des microcodes CPU. « Isolation du noyau / Core Isolation » désactivée dans Sécurité Windows si vous utilisez un antivirus qui interfère.
Éliminer les conflits d’hyperviseur		Fermez ou désinstallez provisoirement VMware, VirtualBox (< v6.0) ou tout logiciel utilisant son propre moteur de virtualisation.
Réparer les fonctionnalités Windows (si échec persistant)		`DISM /Online /Cleanup-Image /RestoreHealth` `sfc /scannow` Puis répétez la première étape.

Résultat de la démarche

L’auteur de la question initiale a confirmé que la séquence désinstallation / réinstallation des fonctionnalités + bcdedit a résolu le problème.
Un second utilisateur ayant suivi les mêmes étapes sans succès peut :

vérifier que la virtualisation est toujours activée après la mise à jour du BIOS ;
exécuter wsl --update pour mettre à jour le noyau Linux de WSL ;
lancer Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux pour confirmer l’état de la fonctionnalité ;
réinstaller manuellement WSL 2 : dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart shutdown /r /t 0

Ces opérations couvrent l’écrasante majorité des causes de l’erreur 0x80370102. Si le problème persiste, suspectez : conflit logiciel de sécurité, firmware trop ancien ou défaut matériel du processeur.

Diagnostics avancés utiles

Vérifier rapidement Hyper‑V et VMP côté Windows

PowerShell (Admin) :

Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All, VirtualMachinePlatform, Microsoft-Windows-Subsystem-Linux

État souhaité : Enabled pour VirtualMachinePlatform et Microsoft-Windows-Subsystem-Linux. Microsoft-Hyper-V-All peut être Enabled (Windows Pro/Enterprise) ou absent (Windows Home), sans empêcher WSL 2.

Contrôler le statut du noyau WSL

wsl --status
wsl --version

Si wsl --update échoue, essayez :

wsl --shutdown
wsl --update --web-download

Valider les exigences Hyper‑V

systeminfo | findstr /i "Hyper-V Requirements"

Si « Virtualization Enabled In Firmware : No », retournez dans le BIOS/UEFI (Intel VT‑x, Intel VT‑d, AMD SVM/IOMMU) et réactivez.

Cas Windows Home vs Pro

Windows Home : pas d’interface Hyper‑V complète. WSL 2 fonctionne sans l’entrée « Hyper‑V » tant que Virtual Machine Platform et Windows Subsystem for Linux sont activés.
Windows Pro/Enterprise : l’interface Hyper‑V existe. L’activer peut faciliter la cohabitation avec d’autres outils et facilite le dépannage.

Conflits connus et bonnes pratiques

VMware Workstation/Player : privilégiez les versions compatibles Hyper‑V. Évitez les pilotes « Windows Hypervisor Platform bypass » obsolètes.
VirtualBox : préférez ≥ 6.0. Les versions antérieures capturent le VT‑x et empêchent le démarrage d’Hyper‑V.
Solutions EDR/antivirus : certains pilotes s’insèrent dans la chaîne d’initialisation et bloquent Hyper‑V. Testez en désactivant l’« intégrité de la mémoire » ou en passant par un mode de compatibilité fourni par l’éditeur.

Nettoyer une installation Ubuntu partiellement enregistrée

Si l’application Store affiche Ubuntu « installée » mais que WSL refuse de démarrer :

wsl --unregister Ubuntu
Ouvrez le Microsoft Store, Réinitialisez la page d’Ubuntu (Paramètres → Réinitialiser), puis relancez l’installation.

Attention : --unregister supprime l’instance et ses données. Sauvegardez au besoin (export) :

wsl --export Ubuntu C:\Sauvegardes\ubuntu.tar

Vérifier et réinitialiser le réseau WSL

Non spécifique à 0x80370102, mais utile après réparations :

netsh winsock reset
netsh int ip reset
wsl --shutdown

Scripts de réparation prêts à l’emploi

PowerShell (Admin) – Réparation complète WSL 2

# 1) Couper WSL et l'hyperviseur
wsl --shutdown

# 2) Désactiver VMP/WSL (proprement)

Disable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -NoRestart -ErrorAction SilentlyContinue
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux -NoRestart -ErrorAction SilentlyContinue

# 3) Redémarrage demandé ici (manuel)

# 4) Réactiver VMP/WSL

Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All -NoRestart
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux -All -NoRestart

# 5) Forcer le lancement de l'hyperviseur

bcdedit /set hypervisorlaunchtype auto

# 6) Redémarrage demandé ici (manuel)

# 7) Mise à jour et configuration WSL

wsl --update
wsl --set-default-version 2

CMD (Admin) – Variante DISM

dism.exe /online /disable-feature /featurename:VirtualMachinePlatform /norestart
dism.exe /online /disable-feature /featurename:Microsoft-Windows-Subsystem-Linux /norestart
shutdown /r /t 0

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
bcdedit /set hypervisorlaunchtype auto
shutdown /r /t 0

Questions fréquentes

Faut‑il absolument activer « Hyper‑V » pour WSL 2 ?

Pas obligatoirement. WSL 2 requiert Virtual Machine Platform et Windows Subsystem for Linux. Sur Windows Home, l’UI « Hyper‑V » n’existe pas ; WSL 2 fonctionne quand même. Toutefois, sur Pro/Enterprise, activer Hyper‑V peut stabiliser l’environnement.

Après une mise à jour BIOS, tout était coché mais l’erreur 0x80370102 revient

De nombreux BIOS réinitialisent la virtualisation à Disabled. Revalidez VT‑x/AMD‑V/VT‑d. Puis rejouez bcdedit /set hypervisorlaunchtype auto, car certains outils remettent ce paramètre à off.

« Intégrité de la mémoire » (HVCI) empêche‑t‑elle WSL 2 ?

En règle générale, non. Mais elle peut entrer en conflit avec des pilotes de virtualisation tiers. En cas de doute, désactivez‑la temporairement pour isoler le problème, puis réactivez‑la une fois WSL opérationnel.

Je suis sur un PC ARM64

WSL 2 fonctionne aussi sur ARM64, mais nécessite les mêmes prérequis (VMP, noyau WSL 2). Assurez‑vous d’utiliser une distribution compatible ARM64 depuis le Store.

Comment savoir si l’hyperviseur a bien démarré ?

Outre bcdedit, vérifiez dans le Gestionnaire de périphériques : sous Cartes réseau, la présence de l’adaptateur vEthernet (WSL) indique généralement que la pile Hyper‑V est opérationnelle. MSInfo32 doit aussi signaler la virtualisation activée.

Bonnes pratiques pour éviter le retour de l’erreur

Faites une seule chose à la fois : changez un paramètre, redémarrez, testez. Cela simplifie l’identification de la cause.
Gardez Windows et WSL à jour : installez les mises à jour cumulatives et exécutez régulièrement wsl --update.
Évitez d’installer plusieurs hyperviseurs concurrents. Si nécessaire, utilisez les toutes dernières versions et consultez leurs modes de compatibilité avec Hyper‑V.
Exportez vos distributions avant toute opération risquée (réinitialisation, changement de disque) : wsl --export.

Annexe : mémo des commandes utiles

But	Commande	Commentaire
Statut WSL	`wsl --status`	Affiche versions et chemins des composants.
Version par défaut	`wsl --set-default-version 2`	Force WSL 2 pour toute nouvelle distro.
Liste des distros	`wsl --list --verbose`	État et version de chaque instance.
Mise à jour du noyau	`wsl --update`	Met à jour le kernel WSL.
Arrêt du runtime	`wsl --shutdown`	Redémarre proprement la pile WSL.
Désenregistrer une distro	`wsl --unregister <Nom>`	Supprime l’instance (données effacées).
Forcer Hyper‑V au boot	`bcdedit /set hypervisorlaunchtype auto`	Indispensable si le paramètre est passé à off.
Réparation images	`DISM /Online /Cleanup-Image /RestoreHealth`	Répare les composants Windows.
Vérification fichiers	`sfc /scannow`	Intégrité des fichiers système.
Activer WSL/VMP	`dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart` `dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart`	Activation manuelle côté Windows.

Résumé exécutable

En pratique, la très grande majorité des cas 0x80370102 se résolvent en :

Réinitialisant VMP/WSL/Hyper‑V via « Fonctionnalités Windows » + redémarrages.
Imposant hypervisorlaunchtype auto.
Mettant WSL à jour et réinstallant proprement Ubuntu (wsl --install -d Ubuntu).

Si, après cela, l’erreur persiste, orientez l’investigation vers conflit d’hyperviseur, pilotes de sécurité ou UEFI trop ancien. Dans les environnements d’entreprise, faites valider la configuration par l’IT (GPO, Device Guard).

Ce guide fournit une démarche éprouvée, reproductible et sûre pour remettre WSL 2 en état et installer Ubuntu, tout en minimisant les interruptions de service et le risque de perte de données.

Erreur 0x80370102 WSL : installation d’Ubuntu impossible – solutions complètes (Windows 10/11)