I’ve hit what feels like an encryption perfect storm and exhausted my own abilities. Hoping for some guidance here.
Setup: Dell XPS 9570, 2TB internal SSD encrypted with BitLocker (auto-unlock + recovery key + password, TPM-backed). 2TB external eSATA backup drive also BitLocker-encrypted (password required). A handful of files additionally protected with Windows EFS.
What happened:
My machine started green-screening frequently, so I replaced the motherboard. This immediately caused issues — all credentials were wiped, and my EFS-encrypted files became completely inaccessible. System Restore failed every time regardless of restore point chosen.
Before reinstalling Windows, I decrypted the C: drive and made a full backup to the external drive, including the AppData directory and a prior backup snapshot where the EFS files had been accessible. I did not export any EFS certificates or keys before reinstalling — a mistake I now recognize.
The Windows reinstall itself failed, leading me to repartition and reformat the drive from scratch using the default Windows 11 layout. After a clean install, I attempted to restore from the external backup — but the BitLocker recovery key was now rejected with “this code does not match the disk,” despite being certain it’s correct.
I swapped back to the original motherboard (with its TPM chip) to eliminate that variable. The machine is more stable now, and I plan to move to a new machine once I can decrypt the drive.
What I’ve tried:
Using UFS Explorer, I confirmed the encrypted partition appears intact with no lost data. However, it showed that two of the three BitLocker metadata copies were corrupted. Following guidance I received, I cloned that section of the drive using DiskGenius first, then copied the healthy metadata copy over the two corrupted ones (done via command line booted from a Fedora USB). The recovery key was still rejected afterward.
I’ve ruled out repair-bde — I don’t have 2TB of free space or the ~60 hours it estimated.
My assumption is that the encrypted content itself is intact and uncorrupted, but the metadata that controls access is damaged in a way that’s causing the key to be rejected.
Any suggestions would be greatly appreciated.
