Data Recovery Case File · Formatted & Logical Faults · Neither On Nor Off
An Encryption Setup That Stopped Midway
His enquiry described a state that should not exist and regularly does. A laptop that "suffered some kind of glitch when I was trying to set up BitLocker. The drive didn't encrypt, and as far as I can tell it isn't corrupted either, so I think the data should be recoverable. The drive asks for an unlock password on startup, which I type in and it seems to work, but the recovery key doesn't seem to" work. That combination — a password that unlocks and a recovery key that does not — is diagnostic, and it points at exactly where the process was interrupted. The urgent part is that the machine still unlocks, and that is a window rather than a stable condition.
| Media | Laptop internal drive with full-disk encryption partially enabled — protection active with the password protector functioning and the recovery key not accepted; conversion incomplete |
| Reported situation | Encryption setup interrupted during configuration · volume reported as not fully encrypted · unlock password accepted at start-up · recovery key not working · data believed intact |
| Fault class | Incomplete encryption enrolment — volume protected with an incompletely established set of key protectors; access dependent on the surviving one |
| Equipment used | Volume imaged at block level while access remained · key protectors enumerated from the running system with the owner's authority · decryption performed against the image · contents verified by opening |
The decode: what half-enabled means, and the thing to do today
How enabling encryption actually works: not as a single action. The system first writes the encryption metadata and creates the key protectors — the different ways the volume can be unlocked, such as a password, a recovery key, or the machine's own security chip. Only then does it begin converting the volume, encrypting it progressively in the background over minutes or hours while the machine stays usable. Interrupt any part of that and you get a volume which is protected — the metadata exists and the protectors are enforced — while the conversion is incomplete and the set of protectors may be partial.
Why the password works and the recovery key does not: those are two separate protectors, established at different moments. The password is created early and immediately. The recovery key is generated and then saved — to an account, a file or a printout — and if the process was interrupted around that step, the key he has may never have been the one enrolled, or the enrolment may not have completed. So his experience is consistent: one protector works because it was finished, the other does not because it was not.
Why this is urgent rather than stable: the machine currently unlocks with a password he knows. That is the only working route in, and it depends on the volume metadata staying intact. Anything that disturbs it — a failed update, a repair operation, a reset, a reinstall, or the encryption process resuming and failing again — removes the one protector that works, and with no valid recovery key there would be nothing left. He should copy his data off today.
What to do, in order: boot the machine, unlock it with the password, and copy everything important to an external drive immediately. Then, while it is running, establish the key position properly — the system can report which protectors exist and produce a current recovery key, which should be saved somewhere outside the machine. Only after both of those is it sensible to think about finishing or removing the encryption.
What not to do: not reinstall, not reset, not run repair tools, and not attempt to resume or disable encryption before the data is off. And not rely on the password indefinitely — a protector without a working recovery key is a single point of failure.
The reassuring part: he is right that the data is probably fine. An incomplete conversion does not damage anything; it leaves part of the volume encrypted and part not, all of it readable through a working protector. The risk is not corruption but losing access.
On the bench
The volume was imaged at block level while access remained, since the working password protector was the only route in and its continued existence could not be assumed — an imager copies sectors regardless of encryption, so the capture did not depend on decrypting anything first. The key protectors were then enumerated from the running system with the owner's authority, establishing which had been enrolled and producing a current recovery key to be stored outside the machine. Decryption was performed against the image rather than the live drive, and the contents verified by opening.
The outcome
The volume imaged while access remained, the key position established and a valid recovery key produced and stored externally. Free assessment, one fixed written figure including VAT; where a drive has to be opened, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The decode, for anyone whose encryption setup was interrupted: enabling it writes metadata and creates key protectors first, then converts the volume progressively — so an interruption leaves a volume that is protected with an incomplete conversion and possibly an incomplete set of protectors; a password that works and a recovery key that does not means one was finished and one was not. Copy your data off today, because that password is currently the only route in.
Encryption that was interrupted while switching on
Copy your data off today, while the password still works — that's the whole of the urgent advice. Turning on full-disk encryption isn't one action: the system writes the encryption metadata and creates the ways of unlocking it first, then encrypts the volume gradually in the background. An interruption leaves you protected but only partly converted, and possibly with only some of those unlock methods properly established. That's why a password can work while the recovery key doesn't — they're separate things created at different moments. Your data almost certainly isn't damaged; the risk is losing the one route in. So boot it, unlock it, copy everything to an external drive, and only then generate and save a fresh recovery key somewhere outside the machine. Don't reinstall, reset or repair anything first.
Copy everything off today — then call Newcastle Data Recovery on 0191 406 1051; volume imaged at block level while access remains, key protectors enumerated, decryption performed against the image.
Request a quote online →
Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.