STATUS_FVE_DEBUGGER_ENABLED (0XC021001D) — Boot debugging is enabled
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?