Faire tourner VMware Workstation et Hyper-V sur la meme machine sans cette erreur Device/Credential Guard not compatible, et tu n'as vraiment que deux routes propres en 2026. Hyper-V, ou la Virtualization-Based Security qui repose dessus, a pris tes extensions de virtualisation CPU, et ta vieille version de VMware refuse de partager. Route une : tu gardes Hyper-V active, tu fais monter VMware en Workstation 16 ou plus recent pour qu'il roule sur la Windows Hypervisor Platform, et les deux cohabitent. Route deux : tu arraches Hyper-V et VBS, mais seulement si tu es enchaine a VMware 15 et que tu ne touches jamais a WSL2, Docker ou Windows Sandbox. Reglages exacts, etapes de restauration et tableau de decision plus bas.
The short answer
Cette erreur VMware Workstation and Device/Credential Guard are not compatible signifie
qu'Hyper-V ou VBS possede deja tes extensions de virtualisation CPU. Corrige-la de deux
facons. Option A (recommandee) : passe a VMware Workstation 16 ou 17 pour qu'il roule sur
la Windows Hypervisor Platform, et les deux hypervisors cohabitent avec WSL2 et Docker
intacts. Option B : arrache Hyper-V et VBS pour le VMware 15 legacy, en sachant que WSL2,
Docker et Windows Sandbox tombent avec.
Tu lances VMware Workstation. Tu cliques sur play. Et la, ca te balance ca : « VMware Workstation and Device/Credential Guard are not compatible. VMware Workstation can be run after disabling Device/Credential Guard. » Ou alors ca démarre quand même en mode « dégradé » et tout rame à mort. J'ai fixé ce dialogue bien trop souvent. La cause, franchement, elle est banale. Hyper-V (ou la Virtualization-Based Security qui repose dessus) a mis la main sur les extensions de virtualisation de ton CPU, et ta vieille version de VMware refuse de partager le jouet. Deux solutions propres en 2026. Et celle vers laquelle je pousserais la plupart des gens ? Elle laisse Hyper-V activé.
Pourquoi le conflit se produit
C'est la partie qui perd tout le monde. Hyper-V est un hypervisor de Type-1. Il démarre avant même que Windows ne se lance vraiment et s'approprie les extensions de virtualisation de ton CPU, Intel VT-x ou AMD-V. Les fonctionnalités Windows empilées par-dessus font pareil, surtout la Virtualization-Based Security (VBS), le parapluie qui couvre Core Isolation / Memory Integrity et Credential Guard. Les vieilles versions de VMware Workstation (et VirtualBox avant la v6) veulent ces extensions pour elles toutes seules. Directement. Pas de colocataire. Donc elles vérifient, voient que quelqu'un les tient déjà, et soit elles refusent net, soit elles tombent dans une émulation logicielle lente comme un escargot. Ce n'est pas un bug. C'est deux hypervisors qui se donnent des coups de coude pour le même matériel. Tu corriges ça de deux façons : tu leur apprends à partager, ou tu en vires un de la machine.
Option A : garder Hyper-V, mettre VMware à jour (recommandé)
C'est là que VMware a enfin grandi. À partir de la 15.5.5, et vraiment depuis Workstation 16, il a arrêté d'exiger les extensions brutes et a appris à rouler sur la Windows Hypervisor Platform (WHP) à la place. Traduction : VMware et Hyper-V cohabitent maintenant. Tu ne renonces à rien qui s'appuie sur la stack Hyper-V.
- Mets-toi à jour vers VMware Workstation 16 ou 17, Player ou Pro, peu importe. Pour la plupart des gens, ce seul geste règle tout.
- Vérifie que la fonctionnalité de plateforme est bien présente (elle l'est en général dès qu'Hyper-V ou WSL2 est installé) :
Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform -All
# WSL2/Docker also rely on this one:
Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -AllRedémarre. Lance une VM VMware. Regarde-la tourner tranquillement à côté d'Hyper-V et de WSL2, Docker aussi, sans la moindre râlerie. Il y a un petit impôt à payer : VMware sur WHP tourne un poil moins vite que VMware sur le bare metal. Mais pour une machine de dev Linux ou une VM Windows jetable ? Tu ne le sentiras jamais. Moi en tout cas, jamais.
Coincé sur VMware 15 à cause de la licence ? Alors l'option B est ta seule route. J'ai essayé les astuces. Aucune ne fait coexister VMware 15 avec un Hyper-V actif.
Option B : désactiver Hyper-V et VBS (legacy)
Ne viens ici que si tu es enchaîné à VMware Workstation 15 ou plus ancien, et que tu ne touches sincèrement jamais à WSL2, Docker Desktop, Windows Sandbox ou VBS. Et voilà le piège qui attrape tout le monde. Tu dois nettoyer à la fois l'hypervisor et la Virtualization-Based Security. Tu n'en désactives qu'un seul ? VMware repère encore les extensions comme prises, et tu te retrouves au point de départ.
- Désactive Memory Integrity : Sécurité Windows > Sécurité de l'appareil > Détails de l'isolation du noyau > Intégrité de la mémoire = Off.
- Arrête l'hypervisor au démarrage :
bcdedit /set hypervisorlaunchtype off- Désactive les fonctionnalités Windows dans « Activer ou désactiver des fonctionnalités Windows » (ou via DISM). Toutes : Hyper-V, Virtual Machine Platform, Windows Hypervisor Platform, Windows Sandbox.
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All -NoRestart
Disable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -NoRestart
Disable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform -NoRestart- Redémarre. Si Credential Guard a été poussé par une stratégie de groupe ou une clé de registre, il reviendra discrètement au démarrage, donc il faudra aussi nettoyer ça. Sur un PC portable du boulot ? Va embêter ton admin avant de te lancer dans la bagarre.
Une fois remonté, VMware 15 tourne à fond, pleine vitesse. Le hic ? WSL2 et Docker Desktop, plus Windows Sandbox, vont maintenant pleurer que la plateforme est indisponible. Ce qui, oui, est logique. Tu viens de leur tirer le tapis sous les pieds.
Comment réactiver Hyper-V
Tu as pris la route de l'option B, et maintenant Hyper-V ou WSL2 (ou Docker) te manque ? Pas de drame. Il suffit de faire marche arrière :
bcdedit /set hypervisorlaunchtype auto
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All
Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -AllRedémarre. Réactive Memory Integrity dans Sécurité Windows si c'est ton truc. Puis confirme que l'hypervisor a bien démarré avec Get-CimInstance Win32_ComputerSystem | Select HypervisorPresent. Toujours une VM qui refuse de booter ? File voir le guide de dépannage hypervisor is not running et avance à partir de là.
Quelle option choisir ?
| Ta situation | À choisir |
|---|---|
| Tu utilises WSL2, Docker Desktop ou Windows Sandbox | Option A (mettre VMware à jour) |
| Tu veux garder Memory Integrity / Credential Guard activés | Option A |
| Tu fais tourner des VM Hyper-V en plus de VMware | Option A |
| Tu es bloqué sur VMware Workstation 15 et tu n'as besoin de rien sur la stack Hyper-V | Option B |
| Tu veux le max de perf VMware sur le bare metal et tu n'utilises que VMware | Option B |
Pour quasiment tout le monde en 2026, pars sur l'option A. C'est mon avis, en tout cas. Tu paies la mise à jour une fois, puis tu arrêtes de devoir choisir entre les hypervisors à chaque démarrage. L'option B, c'est une issue de secours pour ceux qui sont acculés. Pas un endroit où vivre.
Questions fréquentes
C'est quoi exactement Device/Credential Guard dans cette erreur ?
C'est la Virtualization-Based Security. Derriere ce nom se cachent des fonctionnalites Windows comme Credential Guard et Core Isolation / Memory Integrity. Elles tournent dans un petit coffre adosse a Hyper-V qui protege tes identifiants et la memoire de ton noyau. Pour y arriver, elles s'emparent des extensions de virtualisation du CPU. Exactement ce que les vieux VMware veulent pour eux. Du coup l'erreur les cite par leur nom et te dit de les desactiver.
VMware tournera-t-il plus lentement sur la Windows Hypervisor Platform ?
Un peu, oui. VMware passe desormais par l'API WHP au lieu de taper directement dans le materiel. Mais pour des VM de bureau du quotidien, une machine de dev Linux, une install Windows de test vite fait, honnetement je ne vois pas la difference. Empile de la nested virtualization lourde ou un truc vraiment CPU-bound, et la tu perds peut-etre quelques pour cent. C'est le peage pour laisser les deux hypervisors vivre sur une seule machine.
J'ai desactive Hyper-V mais VMware rale encore. Pourquoi ?
Le piege classique. VBS garde la main sur les extensions meme une fois le role Hyper-V parti. Donc desactive Core Isolation Memory Integrity, lance bcdedit /set hypervisorlaunchtype off, desactive Virtual Machine Platform plus les fonctionnalites Windows Hypervisor Platform, puis redemarre. Ca revient toujours ? Il y a de fortes chances qu'une strategie de groupe Credential Guard le reactive discretement a chaque demarrage.
Est-ce que ca touche aussi VirtualBox ?
Oui. Meme bagarre, autre appli. Bonne nouvelle quand meme : VirtualBox 6 et plus savent basculer tout seuls sur le backend Hyper-V, et tu verras une petite icone de tortue quand ils le font, ce qui veut juste dire que ca tourne mais plus lentement. Faire monter VirtualBox de version, c'est en gros l'option A avec un autre chapeau. Arracher Hyper-V, c'est l'option B.
C'est sur de laisser Memory Integrity desactive ?
Ca baisse bel et bien ta garde face a toute une classe d'attaques noyau via les drivers. Sur une machine de labo dediee ou un poste de dev jetable, ce compromis me va. Ce n'est pas ma vie qui est en jeu. Mais le portable dans lequel tu vis tous les jours, avec de vraies donnees dessus ? Autre histoire. La je prendrais l'option A et je garderais Memory Integrity active. Je suis peut-etre trop prudent. Je prefere l'etre.