Écran bleu HYPERVISOR_ERROR : les solutions

L’écran bleu HYPERVISOR_ERROR tombe presque toujours sur une machine où la couche de virtualisation de Windows démarre dans de mauvaises conditions : réglage BIOS incohérent, pilote incompatible avec Hyper-V, ou mémoire instable. Le code d’arrêt vaut 0x00020001 et signifie que l’hyperviseur a rencontré une erreur irrécupérable, d’après la référence Microsoft des vérifications de bogues.

Points clés

• Valeur du bug check : 0x00020001, avec quatre paramètres réservés, donc aucun indice exploitable dans le message lui-même.
• La virtualisation matérielle exige un processeur 64 bits avec SLAT (traduction d’adresses de deuxième niveau) et Hyper-V ne s’active que sur les éditions Professionnel ou Entreprise de Windows 10 et 11.
• Le levier de tri le plus rapide reste bcdedit /set hypervisorlaunchtype off : si l’écran bleu disparaît, la cause est bien dans la pile de virtualisation.
• Sur les postes d’entreprise, l’hyperviseur est souvent imposé par la sécurité basée sur la virtualisation et l’intégrité du code (HVCI), pas par un choix de l’utilisateur.

Ce que dit exactement le code 0x00020001

Windows ne plante pas ici dans un pilote classique. Il plante dans l’hyperviseur, la couche qui s’insère sous le système et qui gère les partitions matérielles. Microsoft décrit HYPERVISOR_ERROR comme une erreur irrécupérable de cet hyperviseur, et publie ses quatre paramètres comme réservés. Autrement dit, le message ne pointe aucun fichier fautif.

Cette absence d’indice a une conséquence pratique. Le diagnostic passe par ce qui a changé sur la machine, pas par la lecture du code. Une mise à jour de firmware, l’activation d’une fonctionnalité Windows, l’installation d’un hyperviseur tiers ou une barrette mémoire fatiguée sont les quatre familles à examiner.

Les causes réellement rencontrées

• Virtualisation partiellement activée dans le BIOS ou l’UEFI : Intel VT-x ou AMD-V actif mais VT-d, IOMMU ou SLAT désactivés, ou un firmware ancien qui gère mal l’ensemble.
• Cohabitation de deux hyperviseurs : Hyper-V actif en même temps qu’un produit de virtualisation tiers en mode natif.
• Pilote de bas niveau incompatible : antivirus, outil de chiffrement, pilote graphique ou pilote de stockage qui accède au matériel sous l’hyperviseur.
• Mémoire ou surcadençage instable : profils XMP ou EXPO agressifs, tension ajustée à la main, barrette défaillante.
• Machine virtuelle imbriquée : Windows exécuté dans une VM dont l’hôte n’expose pas correctement la virtualisation imbriquée.

1. Retirer ce qui vient d’être ajouté

Avant toute manipulation lourde, revenez sur le dernier changement. Une fonctionnalité Windows cochée la veille, un logiciel de virtualisation installé, un pilote graphique remplacé : désinstallez-le et redémarrez l’ordinateur. Si l’écran bleu arrive après une mise à jour Windows récente, désinstallez la mise à jour depuis Paramètres, Windows Update, Historique des mises à jour.

Le cas de la mise à jour est fréquent sur les parcs où le firmware n’a pas suivi. Notez la référence KB retirée : elle sera réinstallée plus tard, une fois le BIOS à jour.

2. Désactiver le lancement de l’hyperviseur

C’est le test de tri. Ouvrez une invite de commandes administrateur, puis exécutez :

bcdedit /set hypervisorlaunchtype off

Redémarrez. Microsoft documente cette option avec deux valeurs, Off et Auto, dans la référence de bcdedit /set. Si les écrans bleus s’arrêtent net, le problème est confirmé dans la pile de virtualisation et les étapes suivantes servent à la remettre en route proprement.

Pour revenir à l’état normal une fois la cause corrigée :

bcdedit /set hypervisorlaunchtype auto

Attention sur un poste géré : cette bascule désactive aussi les protections qui reposent sur l’hyperviseur, dont l’intégrité du code protégée par la virtualisation. Sur une machine d’entreprise, prévenez l’équipe informatique avant de la laisser en Off durablement.

3. Vérifier les réglages de virtualisation du firmware

Entrez dans le BIOS ou l’UEFI et remettez de la cohérence. Activez la virtualisation du processeur, l’IOMMU ou VT-d, et laissez le système gérer les fréquences mémoire au profil par défaut le temps du test. La configuration matérielle requise publiée par Microsoft est claire sur un point : SLAT n’est plus recommandé mais obligatoire pour Hyper-V.

Profitez du passage pour installer la dernière version du firmware fournie par le constructeur de la carte mère ou du portable. Les correctifs de microcode processeur passent par là, et une partie des plantages d’hyperviseur se règle à ce niveau.

4. Mettre à plat les fonctionnalités Windows

Dans Fonctionnalités Windows, regardez ce qui active réellement l’hyperviseur : Hyper-V, Plateforme d’ordinateur virtuel, Sous-système Windows pour Linux, Bac à sable Windows, Windows Defender Application Guard. Décochez ce qui ne sert pas, redémarrez, puis réactivez une entrée à la fois. La combinaison fautive se voit en deux ou trois redémarrages.

Rappel utile avant de chercher longtemps : sur Windows 10 et 11 Famille, Hyper-V n’est pas disponible. Seules les éditions Professionnel et Entreprise le proposent.

5. Isoler un pilote de bas niveau

Démarrez en mode sans échec et observez. Si la machine tient, un pilote tiers est en cause. Désinstallez proprement le pilote graphique avec l’outil du constructeur, retirez les suites de sécurité tierces le temps du diagnostic, puis réinstallez une version récente téléchargée chez le fabricant du composant.

Les pilotes de stockage NVMe fournis par l’éditeur du contrôleur méritent une attention particulière. Un pilote générique Microsoft plante rarement dans l’hyperviseur ; un pilote propriétaire ancien, beaucoup plus souvent.

6. Tester la mémoire et remettre les fréquences par défaut

Coupez XMP, EXPO et tout surcadençage, remettez la mémoire à la fréquence certifiée par la carte mère, puis lancez un test long. Un hyperviseur touche des structures de mémoire physique très tôt au démarrage : une erreur mémoire qui passerait inaperçue sous Windows le fait tomber d’un coup.

Si le test remonte des erreurs, testez barrette par barrette avant de conclure. Une seule barrette fautive suffit à produire un écran bleu qui semble aléatoire.

7. Lire le fichier de vidage

Quand rien ne ressort, il reste le vidage mémoire. Vérifiez que le système écrit bien un vidage mémoire du noyau, puis analysez le fichier avec les outils de débogage Windows. La commande !analyze -v de WinDbg ne nomme pas toujours un coupable sur ce code, mais elle donne la pile au moment du plancher et le nom des modules chargés.

Sur un parc, activez la collecte des vidages avant de remplacer du matériel. Deux vidages qui pointent le même module valent mieux qu’une barrette changée au hasard.

Quand ça ne vient pas de là

Si l’écran bleu persiste hyperviseur désactivé, firmware à jour et mémoire testée, le problème n’est plus spécifique à la virtualisation. Reprenez le diagnostic par la méthode générale des écrans bleus, en comparant les codes d’arrêt observés : un HYPERVISOR_ERROR isolé au milieu de codes mémoire ou d’initialisation matérielle raconte une autre histoire. Notre guide des écrans bleus par code d’arrêt sert de point d’entrée, et les cas voisins comme HAL_INITIALIZATION_FAILED ou CLOCK_WATCHDOG_TIMEOUT partagent une partie des causes matérielles. Pour l’environnement Hyper-V lui-même, voir aussi le dépannage des erreurs d’hyperviseur sous Windows 11.

La réinstallation de Windows arrive en dernier, et seulement après le test mémoire. Elle efface les données de la partition système : sauvegardez avant, sur un support externe débranché ensuite.

FAQ

Que signifie le code 0x00020001 ?

C’est la valeur du bug check HYPERVISOR_ERROR. Microsoft indique qu’il traduit une erreur irrécupérable de l’hyperviseur, et que ses quatre paramètres sont réservés.

Désactiver Hyper-V est-il risqué ?

Sur un poste personnel, non : les machines virtuelles ne démarrent plus, c’est tout. Sur un poste géré, la bascule désactive les protections qui s’appuient sur la virtualisation, dont l’intégrité du code. Cette décision revient à l’équipe informatique.

L’erreur peut-elle venir du processeur ?

Indirectement. Un microcode ancien, un surcadençage ou une carte mère dont l’UEFI expose mal SLAT et l’IOMMU produisent le même symptôme. La mise à jour du firmware traite ces trois cas d’un coup.

Faut-il activer la virtualisation imbriquée dans une VM ?

Si Windows tourne dans une machine virtuelle et doit lui-même exécuter un hyperviseur, oui, l’hôte doit exposer la virtualisation imbriquée. Sinon, désactivez Hyper-V dans l’invité plutôt que de forcer.

Le message peut-il apparaître au démarrage seulement ?

Oui, et c’est un indice. Un plantage systématique pendant l’initialisation désigne le firmware ou un pilote chargé au boot ; un plantage sous charge désigne plutôt la mémoire ou l’alimentation.

_{Photo d’en-tête : Bluescreen Windows 10, par Snoopy1964, CC BY-SA 4.0, via Wikimedia Commons. La photo montre un ecran bleu Windows generique, pas le code HYPERVISOR_ERROR.
Sources : Microsoft Learn, bug check 0x20001 HYPERVISOR_ERROR · Microsoft, résoudre les erreurs d’écran bleu · Microsoft Learn, BCDEdit /set · Microsoft Learn, configuration requise pour Hyper-V · Microsoft Learn, intégrité du code protégée par la virtualisation · Microsoft Learn, outils de débogage Windows}