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.
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.