0XC021001D

STATUS_FVE_DEBUGGER_ENABLED (0XC021001D) — Boot debugging is enabled

Programming & Dev Tools Intermediate 👁 8 views 📅 May 26, 2026

You'll see this error when BitLocker detects a kernel debugger attached at boot. The fix is turning off boot debugging or clearing the BCD debug flag.

You're staring at a black screen with STATUS_FVE_DEBUGGER_ENABLED (0XC021001D). This usually happens when you've enabled kernel debugging in Windows — maybe you connected WinDbg, enabled boot logging for driver troubleshooting, or someone turned on bcdedit /debug on for kernel testing. BitLocker sees that debugger running at boot and refuses to unlock the drive. It's a security feature, not a bug. The culprit here is almost always a leftover BCD debug flag from a past debugging session.

Root Cause

BitLocker checks for a kernel debugger during early boot. If it finds one — either through bootmgr or a physical debug port — it blocks boot to prevent an attacker from using the debugger to read the encryption keys from memory. The error code 0XC021001D is BitLocker's way of saying I see a debugger, I'm not unlocking. This typically happens on Windows 10 and 11 with Secure Boot enabled and TPM-based BitLocker.

Fix: Turn Off Boot Debugging

Don't bother with BIOS resets or Secure Boot toggles — they rarely help. The fix is in the Boot Configuration Data (BCD). You need to clear the debug flag. Here's how:

Step 1: Boot to WinRE (Windows Recovery Environment)

You can't do this from a normal boot because BitLocker is blocking you. Use one of these:

  • Interrupt boot three times (force power off at Windows logo) to trigger automatic repair
  • Boot from a Windows installation USB, then select Repair your computer
  • Hold Shift while clicking Restart if you can still get to the login screen

Step 2: Open Command Prompt in WinRE

Once in WinRE, go to Troubleshoot > Advanced options > Command Prompt.

Step 3: Identify the Boot Entry

Run this command to list your boot entries:

bcdedit /enum

Look for an entry where debug is set to Yes. Usually it's the Windows Boot Loader entry for your main OS. Note the identifier (like {current} or a long GUID).

Step 4: Disable the Debug Flag

Assuming the identifier is {current}, run:

bcdedit /set {current} debug off

If that doesn't work or you see a different identifier, use that identifier instead.

Step 5: Also Check for Serial Debug

Sometimes the debug flag is set via a debug port. Run this to remove any serial or USB debug settings:

bcdedit /debug off

Step 6: Reboot

exit

Then select Continue or reboot from the USB. The error should be gone.

What to Check If It Still Fails

If the error persists after disabling debug:

  • Check for multiple boot entries — Some systems have a separate debug entry. Delete it with bcdedit /delete {guid} (be careful).
  • Verify no physical debugger attached — Unplug any JTAG, USB debug cables, or PCIe debug cards.
  • Check Group Policy — Go to Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption. Look for policy that disables BitLocker if debugger is present. If enabled, it might be misconfigured.
  • Run a BIOS update — I've seen a few Dell and HP systems where a BIOS bug left a debug flag in the chipset. A firmware update cleared it.
  • As a last resort — Temporarily disable Secure Boot or clear TPM. That's a nuclear option because you'll lose BitLocker keys. Only do this if you have the recovery key written down.

Most people hit this once after a kernel debugging session and forget to turn debug off. Run that BCDEDIT command and you're back in business.

Was this solution helpful?