Diagnose a BitLocker key that is accepted but returns to recovery or Automatic Repair

This writeup is an explicit exception to the standing unlocked-volume assumption. The correct 48-digit password is accepted, but startup then returns to BitLocker recovery, enters Automatic Repair, or displays another Windows boot error. Acceptance proves the key can unlock the selected volume for that attempt. It does not prove the underlying Windows boot chain, file system, storage path, registry, update state, or hardware is healthy.

Searchable Windows error codes and exact messages

Use when the displayed Key ID matches the saved recovery password, entry is accepted, and the next screen is a repeated recovery or repair path. The volume must remain readable when unlocked from external recovery media.

Do not use when the key is rejected, the Key ID differs, no recovery password exists, the volume is physically failing, or manage-bde cannot unlock it. Do not use repair-bde on a readable volume; that tool is a last-resort data-recovery operation requiring a separate output volume.

The original trigger may remain unknown. The Key ID, correct recovery password, unlocked volume, physical-disk mapping, exact next screen, and storage health may not remain unknown.

• Matching recovery password kept private
• Current Windows 10/11 recovery or installation media
• Backup destination for logs and readable data
• Administrative Command Prompt
• Record of firmware/update/controller changes if available

Boot from external recovery media so its WinRE is independent of the broken internal recovery path. Choose Repair your computer > Troubleshoot > Advanced options > Command Prompt. Disconnect unrelated storage but keep the backup destination when needed.

1. Record the recovery Key ID and every screen after key acceptance. The next screen determines the repair branch.

2. Inspect volumes without assuming letters:

   diskpart
   list disk
   list volume
   exit
   

3. Check BitLocker state on candidate volumes:

   manage-bde -status
   

4. Assign an unused temporary letter to the encrypted Windows volume if needed, then unlock it:

   manage-bde -unlock W: -RecoveryPassword <48-digit-password-with-dashes>
   manage-bde -status W:
   

5. Verify the correct installation:

   dir W:\Windows\System32\Config\SYSTEM
   dir W:\Windows\System32\winload.efi
   

6. Confirm storage readability before boot repair:

   chkdsk W:
   

   Stop for RAW, I/O errors, or repeated disappearance.

7. Preserve evidence:

   type W:\Windows\System32\Logfiles\Srt\SrtTrail.txt
   dir W:\Windows\Logs\CBS
   

8. Inspect protectors without deleting them:

   manage-bde -protectors -get W:
   

9. If BCD is readable, copy/export it before any modification. Map the system partition from DiskPart rather than assuming it shares W:.

1. Keep the volume unlocked for the recovery session. Do not decrypt it merely to troubleshoot startup.

2. Route the failure shown after unlock:

   • 0xc000000f: missing/corrupt BCD procedure;
   • 0xc0000225 or 0xc000000e: required-device procedure;
   • 0xc0000098: invalid BCD/named-file procedure;
   • 0xc000014c naming SYSTEM: registry-hive procedure;
   • 0x7B: storage path/driver/controller procedure;
   • SrtTrail.txt: cause-isolation procedure;
   • update rollback/undoing changes: servicing procedure.

3. Apply only that targeted repair while the Windows volume is unlocked. Preserve BCD and named files first.

4. Reboot and enter the recovery password once more if requested.

5. When Windows finally starts and platform state is stable, save recovery information again and inspect protection:

   manage-bde -status C:
   manage-bde -protectors -get C:
   

6. If recovery continues on every boot after the separate boot problem is fixed, perform the bounded suspend/resume procedure in FIX-052. Do not reseal while firmware/security state is still changing.

• Unlock succeeds and a specific Windows code remains: BitLocker is not the current root cause; repair the named branch.
• Unlock succeeds but volume checks show I/O errors: protect data and diagnose storage.
• Windows boots after the targeted repair but asks for the key once: allow that measured recovery, then verify whether it recurs.
• External WinRE unlocks a different volume than the preboot screen: recheck Key ID and physical-disk mapping.

Do not clear TPM, delete protectors, disable Secure Boot, turn encryption off, run repair-bde on the only copy, or rebuild BCD before recording the exact post-unlock error. Never put the recovery password in a public log or filename.

Rollback the targeted boot repair using its saved BCD, file, driver, or image. BitLocker unlock is session-scoped and requires no destructive rollback. If protection was later suspended, re-enable it only after the prior stable configuration is restored.

Verify the correct volume is protected, the recovery password remains backed up, Windows completes two restarts and one cold start, Automatic Repair no longer appears, and the underlying repaired component remains healthy.

Confidence is about 80% when the correct key unlocks the volume externally, the next Windows error is reproducible, a targeted repair resolves that error, and repeated boots succeed. Stop when the key does not match, the volume cannot be read, storage is unstable, or enterprise policy owns the protectors.