Data Recovery Case File · Solid State & Flash · The Song Projects
Corrupt copies from an intact drive: the failing NVMe's episodes decoded — why her rescued files broke in transit, and the music folder brought across whole under managed power and patience
Her triage log was better than she gave it credit for. A 1TB NVMe SSD, believed failing: "if I have my SSD plugged into my motherboard, it causes my PC to slow down and more often than not crash." The workaround, sensibly acquired: an SSD-to-USB dongle — "a lot more stable… but it often disconnects after only a bit of time." The rescue attempt through a free recovery application, and its heartbreaking result: "I actually copied a few files over to my main boot drive, but they seem to be corrupted — the .mp3s won't work and my music project files won't load." Her priorities were clear: "my main priority is recovering a music folder, which has a lot of song projects — but ideally I'd like the entire contents cloned to a new SSD." Both delivered below. The decode's central gift is the one her corrupt copies were hiding: files that arrive broken from an unstable drive are very often perfect on the drive itself. The reads were lying. The music, in all likelihood, was not.
| Media | 1TB NVMe SSD — a music folder of song projects the priority; full-contents clone to new media requested |
| Reported symptoms | On the motherboard: system-wide slowdown and frequent crashes · via USB dongle: longer sessions, recurring disconnections · free recovery application's copied files corrupt — audio unplayable, project files refusing to load |
| Fault class | Controller instability under load — reads stalling and completing unreliably; stored data substantially intact behind the episodes |
| Equipment used | Managed-power native NVMe access with tuned timeouts and retry policy · episode-tolerant sector imaging · priority extraction of the music folder with per-project verification · full clone delivered to new media |
The decode: why it crashed the PC, why the dongle half-worked, and why the copies broke
The crashes, explained: an NVMe drive sits on the system's fastest, most trusting connection — so when its controller begins stalling, the whole machine feels it. Requests hang, the system waits on a bus that brooks no waiting, and the computer slows and falls over around the drive's episodes. Her PC wasn't failing; it was being held hostage by a passenger having seizures. The dongle's partial success fits the same picture: USB is the tolerant chaperone — slower, more forgiving of hesitation, willing to reset and carry on — so sessions lasted longer before an episode finally exceeded even its patience and the drive dropped. Two hosts, one diagnosis: a controller that serves in stretches and stalls without warning.
The corrupt copies, acquitted of permanence: here is the decode that changes the outlook. When files are copied through a drive mid-episode, reads can stall, retry, and — worst of all — complete wrongly: the copy proceeds, but some of what arrives is garbage delivered with a straight face. Audio files full of such passages won't play; project files — structured containers with no tolerance for a single corrupted block — won't load at all. Her rescued files' condition described the journey, not the origin. The proper response isn't to repair the broken copies but to re-take them — under conditions where every read is checked, retried on the drive's good stretches, and never trusted just because it returned.
Her instincts, graded: the dongle purchase showed real problem-solving; stopping after a few corrupt files rather than grinding the tool onward preserved the drive's remaining stability for the work that mattered; and naming one priority folder — the song projects, the unrecreatable heart of it — gave triage its marching order before the drive arrived.
The recovery: outwaiting the episodes, the music first
The drive was taken onto managed native NVMe access at the bench — power sequenced, timeouts tuned, a retry policy that treats every stall as weather rather than defeat. Imaging proceeded episode-tolerant: harvesting hard during the drive's good stretches, pausing through its seizures, verifying as it went so no lying read survived into the image. The music folder's regions were prioritised and banked first; the rest of the terabyte followed. From the completed image, the deliverables came in her order: the song projects extracted and verified by loading them — each one opened, not merely counted — the audio playing clean where her copies had crackled and died; and the entire contents cloned to a new SSD, exactly as she'd hoped.
The outcome
The music folder home and loading, the full clone delivered beside it, and the corrupt rescue copies retired with an explanation instead of a mystery. Free assessment, one fixed written figure including VAT, no recovery, no fee. The failing drive was stood down from service mid-episode — its last complete performance being the one that mattered: the image.
Unstable SSD — and the files you've saved off it arrive corrupt
Don't judge the originals by the copies: reads from a stalling drive can complete wrongly, delivering intact files as garbage. Stop re-running recovery tools — each session spends the drive's good stretches on unverified copying — and stop trusting any host connection that crashes or drops around it; those are the drive's episodes, not your computer's fault. Name your priority folder when you send it in, and expect the professional difference to be verification: every read checked, every project opened, before anything is called recovered.
The originals are usually intact — call Edinburgh Data Recovery on 0131 202 0491; imaged under managed power, verified per file, one written figure, no recovery, no fee.
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.