Data Recovery Case File · Formatted & Logical Faults · Encryption Is the Red Herring
The Password Works and the Drive Does Not
Her enquiry describes an encryption problem that is not one. A 1TB drive encrypted at the request of a new work machine: "I have done this up to 100% and know my password. When I plug this in and enter my password it completely jams my computer. I have tried to open it on my Mac using a variety of software and I cannot get onto it. Is this something you would be able to do by removing the encryption so I can access the files?" The machine jams after the password — which means the unlock succeeded, and what fails next is reading the drive.
| Media | 1TB hard drive with full-volume encryption applied and completed — credential accepted; host becoming unresponsive during volume access; owner holding the password |
| Reported situation | Drive encrypted at the request of a replacement work machine · encryption reported as completing fully · password known and retained · host becoming unresponsive after the password is entered · access attempted on a second platform with third-party software · contents required |
| Fault class | Severe read failure on an encrypted volume — credential valid and unlock succeeding; host unresponsiveness consequent on unanswered reads |
| Equipment used | Unlock confirmed as successful before any conclusion about the credential · no decryption pass attempted on the failing medium · Atola Insight Forensic error-rate assessment · imaged write-blocked under strict per-sector timeouts · decryption performed against the image using the owner's key |
The decode: what the jam happens after, and what encrypting actually did
Why the timing settles it: entering the password decrypts a protected header and releases the volume's actual key. If the password were wrong, or the header unreadable, the machine would reject it. Instead it accepts and then hangs — so the unlock worked, and the next operation is what fails. That next operation is reading the filesystem in order to mount it.
Why that produces a frozen machine: a drive with severe read failures does not refuse a request, it retries — repositioning and escalating through an internal recovery sequence taking seconds per sector. Requests issued and never answered hold slots in the operating system's queue, and enough of them leave the system short of resources. The computer is not broken; it is waiting. Unplugging the drive returns it to normal within moments.
Why her question is framed the wrong way round: "removing the encryption" would mean reading every sector, decrypting it, and writing it all back — a complete pass over a drive that cannot complete reads. It is the single worst operation to attempt here. The encryption does not need removing; it needs unlocking with the key she already has, applied to a copy rather than to the failing drive.
Now the part worth knowing, because it explains the timing. Encrypting a volume writes to every sector on it. That is a full-surface operation, sustained for hours, and it is the heaviest continuous load a drive is ever asked to carry. It is a stress test that nobody realises they are running. A drive with marginal regions frequently fails during encryption or shortly afterwards — not because encryption harms drives, but because it is the first thing to demand that much work from every part of the surface.
So the likely sequence: a drive already carrying weak areas was asked to write across all of them without pause, and the process either found the failures or finished off a mechanism that was close. The encryption is not the fault and it is plausibly the trigger.
Why the second platform did not help: that operating system does not read this encryption format natively, so software was required — a separate obstacle stacked on top of the actual fault, and one that would remain even on a healthy drive.
What matters most now: keep the password and any recovery key somewhere safe and separate. Without them the data is unrecoverable regardless of what happens to the drive, and that is the one thing that cannot be worked around.
On the bench
Unlock was confirmed as successful before any conclusion about the credential — a machine accepting the password and then hanging having released the volume key, with the subsequent filesystem read being what fails. No decryption pass was attempted on the failing medium, a full decrypt requiring every sector to be read and rewritten. The Atola Insight Forensic assessed error rates, imaging ran write-blocked under strict per-sector timeouts, and decryption was performed against the image using the owner's key.
The outcome
The unlock confirmed, no decryption attempted on the drive itself, and the volume decrypted against a write-blocked image using the owner's own key. 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: your machine jams after accepting the password, which means the unlock worked and reading the drive is what fails. And encrypting a volume writes to every sector — a full-surface stress test nobody knows they are running.
Encrypted drive that freezes the computer after the password
Keep your password and recovery key somewhere safe and separate — that's the one thing nothing can work around. Then read the timing: if the machine accepts the password and then hangs, the unlock succeeded and what's failing is reading the drive. A drive with severe read failures doesn't refuse requests, it retries, and unanswered requests hold slots in the system's queue until the machine runs short and freezes. Unplug it and the computer recovers in moments. Don't ask anyone to remove the encryption either — that means reading and rewriting every sector, which is the worst possible operation on a drive that can't complete reads. And note that encrypting wrote to every sector in the first place.
Keep the key safe — call Guildford Data Recovery on 01483 901310; unlock confirmed before any conclusion, no decryption attempted on the drive, imaged under strict timeouts and decrypted against the copy.
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.