A laptop encrypted end to end with VeraCrypt, part-way through being decrypted when it stopped. That leaves a drive in two states at once — and then chkdsk was run across the whole thing, which is where it went from awkward to serious.
This is a scenario, not a case study. It describes a failure pattern we handle regularly and how it is approached, written from the technical work rather than from one client's job. Our documented case files are here.
A user decides to remove full-disk encryption — VeraCrypt, BitLocker or similar — and starts an in-place decryption. Partway through, the machine loses power, crashes, or the drive develops a fault. The volume will now neither mount decrypted nor unlock as encrypted.
Removing encryption in place is not a metadata change. Every sector on the volume has to be read, decrypted and written back as plaintext, progressing from one end of the disk to the other. On a large drive that takes hours.
While it runs, the volume exists in two states simultaneously: the region already processed is plaintext, the region not yet reached is still ciphertext, and a header field records the boundary.
If the process stops and that boundary marker is lost or inconsistent, neither interpretation works. Treating the whole volume as encrypted produces garbage from the decrypted region; treating it as plaintext produces garbage from the encrypted one.
Encrypted data and plaintext data look completely different at the byte level. Ciphertext is statistically indistinguishable from random; a file system's plaintext is highly structured, full of recognisable headers, repeated patterns and long runs of zeros.
Scanning the image for the point where that statistical character changes locates the transition precisely, usually to within a single sector. The volume is then assembled in two parts: the plaintext region taken as-is, the ciphertext region decrypted with the key.
The key is still required for the encrypted portion. What this technique solves is the boundary problem, not the encryption itself.
Do not resume the decryption. Restarting the process on a volume whose progress marker is unreliable can decrypt already-plaintext regions, which encrypts them — and the result is not recoverable by reversing the same step.
Not by attacking the cipher - that is not something anyone does. What we can attack is the password, using professional GPU-accelerated password recovery guided by whatever you remember. That works on short, reused or partly-recalled passwords and does not work against a long random passphrase.
Two states at once. Everything before the point it reached is plaintext; everything after is still ciphertext. That is recoverable with the password, but no file system understands it, which is why Windows reports the volume as damaged.
Because it does exactly what it is designed to do. Faced with file records pointing into regions that look like nonsense — because they are still encrypted — it discards those records to make the file system consistent. It deletes the map on entirely reasonable grounds.
Not on a drive that is also failing. Resuming means hours of sustained reading and writing across the whole volume, which is the last thing a disk with bad sectors should be asked to do. Image it first.
Yes — the knock in transit had caused reallocated sectors, and that was probably why the decryption stalled in the first place. Encryption failures after a physical event are usually the physical event showing itself.
£800 plus VAT flat, quoted after a free 48-hour diagnostic, and we need the password or recovery key. Where those genuinely no longer exist we say so at the diagnostic and there is nothing to pay.
In-place conversion touches every sector on the volume. It is among the higher-risk routine operations, and a current backup makes it a non-event.
A laptop on battery, an unattended machine that sleeps, or a scheduled restart will all interrupt it. Plug it in and let it finish.