Data Recovery Case File · Solid State & Flash · The Caddy That Can Lie

What a caddy can prove, and where it goes blind: the M.2 keying and protocol trap decoded, "not even a USB device" read correctly — and the failed drive settled and recovered on native connections

His elimination was the methodical kind this archive banks gladly: "Laptop M.2 NVMe SSD (256GB) has failed. Removed the SSD from the laptop to a USB caddy — and the drive does not appear in Windows 10 Disk Management on another machine. The drive does not appear as a USB device in Windows either." Textbook procedure: patient extracted, tested on independent hardware, results at two levels reported precisely. And it deserves the honest annotation every caddy test needs, because caddies carry a famous blind spot: an M.2 caddy is not a transparent window onto the drive — it contains a bridge chip translating between USB and the drive, and that bridge has opinions: which protocol it speaks (NVMe, SATA, sometimes only one), which keying it accepts, and whether it announces itself at all without a drive it recognises behind it. A perfectly healthy NVMe drive in a SATA-only caddy — or vice versa — presents exactly his result: nothing, anywhere, forever. So his test proved something real, but not yet the thing it seemed to: it proved the caddy-plus-drive combination is silent — and separating the caddy's silence from the drive's is precisely what a native connection settles in one minute, and settled here.

The decode: the bridge, the blind spot, and the reading of "not even a USB device"

What lives inside a caddy: the little enclosure is a translator, not a window: a bridge chip that speaks USB to the computer and the drive's own language — NVMe over PCIe, or SATA — to the drive. Everything the computer ever sees is the bridge's report. And M.2, the most confusable connector family in consumer storage, gives the bridge every chance to go blind: the slot's keying notches admit physically-compatible drives the bridge cannot actually talk to, because NVMe and SATA M.2 are different protocols wearing the same shape — and single-protocol caddies (very common, rarely labelled loudly) render the other protocol's drives invisible while fitting them perfectly. The result is the classic false negative: a healthy drive, a working caddy, and total mutual silence — the combination broken, both components fine.

Reading his second observation properly: his sharper detail — not even a USB device — narrows things without settling them. Some bridges announce themselves to Windows regardless (an empty enclosure still enumerating), in which case total USB silence would indict the caddy's own power or cable; others enumerate only once a recognised drive answers behind them, in which case a protocol-mismatched or genuinely dead drive both yield the same nothing. Without knowing which species his caddy is, "not even a USB device" is compatible with three different worlds: wrong-protocol caddy, dead caddy, dead drive. That's not a criticism of the test — it's the honest boundary of what any caddy test can prove, and the reason the professional next step removes the translator entirely.

The native test, and what it found: a bench connection speaks to an M.2 on its own protocol, through native ports, with no bridge to impersonate silence — one minute of which outranks any amount of caddy testing. Here it settled the case cleanly: the drive was silent natively too — the caddy retrospectively acquitted, the fault confirmed as the drive's own controller wake-up failure, the same firmware-or-electronics territory this volume's invisible-M.2 cases map, sitting above the stored data with the platform road open. His elimination hadn't been wrong; it had been one translator short of conclusive — and the conclusion, once native, pointed exactly where recovery could follow.

On the bench

The caddy stayed in the drawer: the SSD went straight onto the Atola TaskForce 2's native M.2 NVMe ports, and the one-minute question was answered — silent natively, the drive's own wake-up genuinely failed, the caddy formally cleared. The recovery then ran the platform road: the controller family's service access through the PC-3000 portfolio, the drive brought up far enough to speak, and the 256GB imaged completely in that first session — the revived-SSD discipline this archive never varies. His files stood up from the image, were verified by opening, and were delivered on fresh media, alongside the written note his methodical streak had earned: which species of test had proved what, and why the native minute had been the one that counted.

The outcome

The caddy ambiguity resolved natively, the genuine controller failure confirmed and worked at platform level, and the drive's contents imaged, verified and delivered. Free assessment, one fixed written figure including VAT; where a chip has to be removed, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The blind spot, posted for every methodical owner with an enclosure and a suspicion: a caddy is a translator with opinions — NVMe and SATA M.2 share a shape and not a language, single-protocol bridges make healthy drives vanish, and "not even a USB device" can mean the bridge, the protocol, or the drive; caddy silence is real evidence but never a verdict — the native connection is the minute that settles it; and when the drive is genuinely dead, the fault is a failed wake-up above your data, with the platform road open behind it. Test in a caddy by all means. Just don't let the caddy write the obituary.

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.