You fire up VMware Workstation. You hit play. And it slaps you with this: “VMware Workstation and Device/Credential Guard are not compatible. VMware Workstation can be run after disabling Device/Credential Guard.” Or it limps along in “degraded” mode and everything crawls. I’ve stared at that dialog way too many times. The cause is boring, honestly. Hyper-V (or the Virtualization-Based Security riding on top of it) grabbed your CPU’s virtualization extensions, and your older VMware build won’t share the toys. Two clean ways out in 2026. And the one I’d nudge most people toward? It keeps Hyper-V switched on.
Contents
Why the conflict happens
This is the part that trips people up. Hyper-V is a Type-1 hypervisor. It boots before Windows really gets going and lays claim to your CPU virtualization extensions, Intel VT-x or AMD-V. The Windows features stacked on top of it do the same thing, mainly Virtualization-Based Security (VBS), the umbrella over Core Isolation / Memory Integrity and Credential Guard. Older VMware Workstation (and VirtualBox before v6) wants those extensions for itself. Directly. No roommates. So it checks, sees someone already holding them, and either flat-out refuses or drops to dog-slow software emulation. That’s not a bug. It’s two hypervisors elbowing each other over the same hardware. You fix it one of two ways: teach them to share, or kick one off the box.
Option A: keep Hyper-V, upgrade VMware (recommended)
This is where VMware finally grew up. Starting with 15.5.5, and properly from Workstation 16 on, it quit demanding the raw extensions and learned to ride on the Windows Hypervisor Platform (WHP) instead. Translation: VMware and Hyper-V live together now. You give up nothing that leans on the Hyper-V stack.
- Upgrade to VMware Workstation 16 or 17, Player or Pro, doesn’t matter. For most people that one move is the whole fix.
- Double-check the platform feature is actually there (it usually is the moment Hyper-V or WSL2 gets installed):
Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform -All # WSL2/Docker also rely on this one: Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All
Reboot. Fire up a VMware VM. Watch it run happily next to Hyper-V and WSL2, Docker too, with zero nagging. There’s a small tax: VMware on WHP runs a touch slower than VMware on bare metal. For a Linux dev box or some throwaway Windows VM, though? You’ll never feel it. At least I never have.
Option B: disable Hyper-V and VBS (legacy)
Only come here if you’re chained to VMware Workstation 15 or older, and you genuinely never touch WSL2, Docker Desktop, Windows Sandbox or VBS. Now the gotcha that bites everyone. You have to clear both the hypervisor and Virtualization-Based Security. Kill just one? VMware still spots the extensions as taken, and you’re right back where you started.
- Turn off Memory Integrity: Windows Security → Device security → Core isolation details → Memory Integrity = Off.
- Stop the hypervisor at boot:
bcdedit /set hypervisorlaunchtype off
- Turn off the Windows features in “Turn Windows features on or off” (or via DISM). All of them: 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
- Reboot. If Credential Guard got pushed by group policy or a registry key, it’ll quietly come back at boot, so you’ll need to clear that too. On a work laptop? Go bug your admin before you start fighting it.
Once it’s back up, VMware 15 runs flat-out at full speed. The catch? WSL2 and Docker Desktop, plus Windows Sandbox, will now whine that the platform’s unavailable. Which, yeah, makes sense. You just pulled the rug they were standing on.
How to turn Hyper-V back on
Took the Option B route, and now you miss Hyper-V or WSL2 (or Docker)? No drama. Just walk it back:
bcdedit /set hypervisorlaunchtype auto Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All
Reboot. Flip Memory Integrity back on in Windows Security if that’s your thing. Then confirm the hypervisor actually came up with Get-CimInstance Win32_ComputerSystem | Select HypervisorPresent. Still got a VM that refuses to boot? Head over to the hypervisor is not running fix guide and work it from there.
Which option should you pick?
| Your situation | Choose |
|---|---|
| You use WSL2, Docker Desktop or Windows Sandbox | Option A (upgrade VMware) |
| You want Memory Integrity / Credential Guard on | Option A |
| You run Hyper-V VMs as well as VMware | Option A |
| You are locked to VMware Workstation 15, need nothing on the Hyper-V stack | Option B |
| You need maximum VMware performance on bare metal and use only VMware | Option B |
For nearly everyone in 2026, go Option A. That’s my read, anyway. Pay the upgrade once, then stop choosing between hypervisors every single boot. Option B is an escape hatch for the cornered. It’s not a place to live.
FAQ
What exactly is Device/Credential Guard in this error?
It’s Virtualization-Based Security. Behind that name sit Windows features like Credential Guard and Core Isolation / Memory Integrity. They run inside a little Hyper-V-backed vault that guards your credentials and your kernel memory. To pull that off, they grab the CPU virtualization extensions. The exact thing older VMware wants for itself. So the error calls them out by name and tells you to switch them off.
Will VMware run slower on the Windows Hypervisor Platform?
A bit, yeah. VMware now talks through the WHP API instead of poking the hardware itself. But for everyday desktop VMs, a Linux dev box, a quick test Windows install, I honestly can’t tell the difference. Pile on heavy nested virtualization or something genuinely CPU-bound, and maybe you lose a few percent. That’s the toll for letting both hypervisors live on one machine.
I disabled Hyper-V but VMware still complains. Why?
Classic trap. VBS keeps its grip on the extensions even after the Hyper-V role is gone. So turn off Core Isolation Memory Integrity, run bcdedit /set hypervisorlaunchtype off, disable the Virtual Machine Platform plus the Windows Hypervisor Platform features, then reboot. Still coming back? Odds are a Credential Guard group policy is quietly re-enabling it every time you boot.
Does this also affect VirtualBox?
It does. Same fight, different app. Good news, though: VirtualBox 6 and up can fall back to the Hyper-V backend on their own, and you’ll spot a little turtle icon when they do, which just means “running, but slower.” Bumping VirtualBox up is basically Option A wearing a different hat. Ripping out Hyper-V is Option B.
Can I script switching between the two modes?
You can, and honestly it’s a slick trick. Make two boot entries with bcdedit /copy {current} /d "No Hyper-V", then set hypervisorlaunchtype off on the new one. After that you just pick your hypervisor at the boot menu, no more toggling features and rebooting twice. One snag worth knowing. Memory Integrity still has to be off for the no-Hyper-V side, and that setting isn’t tied to a boot entry. It’s machine-wide.
Is it safe to leave Memory Integrity off?
It does drop your guard against a whole class of driver-based kernel attacks. On a dedicated lab box or a throwaway dev machine, I’m fine with that trade. It’s not holding my life. But the laptop you live in every day, with real data on it? Different story. I’d take Option A there and keep Memory Integrity switched on. Maybe I’m overcautious. I’d rather be.
Hit another Hyper-V error?
Type in any Hyper-V code or message. Pull up the cause and the exact steps to fix it, all in one place you can actually search.
