Fix 0xc0000350: Credential Guard blocks Kerberos after Hyper-V

What's actually happening here

The error 0xc0000350 shows up when you try to authenticate with Kerberos after enabling Hyper-V. The trigger is usually enabling Hyper-V on a machine that also has Windows Defender Credential Guard enabled (often via Group Policy or the default Windows 10/11 Security Baseline).

The root cause: Credential Guard virtualizes the Local Security Authority Subsystem Service (LSASS) into a separate, isolated VM. When Hyper-V is enabled, it reconfigures the virtualization stack. The LSASS VM breaks — it can't communicate with the domain controller, and Kerberos ticket requests fail with 0xc0000350 (STATUS_VIRTUALIZATION_NOT_ALLOWED).

You'll see this error in Event Viewer under Microsoft-Windows-Kerberos/Operational with ID 7, or directly in apps that use Kerberos auth (like Remote Desktop, SQL Server, or SharePoint).

Fix 1: Quick registry disable (30 seconds)

This turns off Credential Guard without removing any features. It's not a permanent uninstall — a reboot reverts if you reenable via GPO later.

1. Open Registry Editor as admin.
2. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
3. Create a new DWORD (32-bit) called DisableCredGuard, set value to 1.
4. Reboot.

Why this works: This registry key tells the kernel to skip loading the Credential Guard driver. It's the fastest way to test if Credential Guard is the culprit. If the error disappears, you've confirmed the cause. But this is a runtime switch — if Group Policy pushes the setting back, it'll come back on next GP update.

Fix 2: Group Policy toggle (5 minutes)

Use this if you have admin control over local policy and want a cleaner disable that survives reboots without forcing a full uninstall.

1. Run gpedit.msc.
2. Navigate to Computer Configuration > Administrative Templates > System > Device Guard.
3. Double-click Turn On Virtualization Based Security.
4. Set to Disabled.
5. Run gpupdate /force in an admin cmd.
6. Reboot.

What you need to know: This policy controls VBS (Virtualization Based Security), which Credential Guard depends on. Disabling it here stops Credential Guard from starting. However, if you're on a domain, domain-level GPO might override this — check with rsop.msc.

Fix 3: Full Credential Guard removal (15+ minutes)

Only go here if you absolutely don't need Credential Guard. This removes all traces and requires you to reinstall if you want it back.

1. Open an elevated PowerShell.
2. Run: Disable-WindowsOptionalFeature -Online -FeatureName Windows-Defender-Credential-Guard -Remove
3. If that fails (it often does on Windows 10/11 because the feature is built-in, not optional), use the following instead:

   # Disable via BCDEdit
   bcdedit /set {current} hypervisorlaunchtype off
   bcdedit /set {current} disablevmcredguard on
   

4. Reboot.

The reason step 3 works: hypervisorlaunchtype off completely disables the Hyper-V hypervisor boot. Without the hypervisor, VBS can't run, and Credential Guard won't load. The disablevmcredguard flag is a safety net that tells the boot loader to skip the Credential Guard check entirely.

If you still get the error after this, check that Secure Boot was ever enabled. Credential Guard requires it. Without Secure Boot, the feature might have been partially installed and is now in a broken state. Run Get-WmiObject -Query "Select * from Win32_ComputerSystem" | Select-Object -Property Manufacturer, Model, TotalPhysicalMemory and check if Secure Boot is on in BIOS/UEFI.

Edge case: Hyper-V nested virtual call

Some Hyper-V hosts running nested virtualization (e.g., running Hyper-V VMs inside a VM) can trigger 0xc0000350 even when Credential Guard is off. The fix there is to disable nested virtualization in the VM: Set-VMProcessor -VMName "YourVM" -ExposeVirtualizationExtensions $false. This is rare, but if the first three fixes didn't work, check this.

Which fix should you pick?

If you just need to RDP into a server after enabling Hyper-V and got this error, use Fix 1 — it's fast and reverts easily. If you're setting up a dev machine and won't need Credential Guard, use Fix 3 and be done with it. If you're on a corporate domain, Fix 2 is your best bet because it works within policy controls without removing the feature entirely.

One more thing: after any of these fixes, check that Kerberos works again by running klist tickets in a cmd prompt. If you see tickets for your domain, you're good. If not, run klist purge and klist get krbtgt/YOURDOMAIN.COM to force a fresh ticket request.