Data Recovery Case File · Cameras, Drones & Cards · Two Consoles, Two Answers

Listed in One Place, Absent From Another

His enquiry contains a contradiction worth taking apart. An old camera card: "it's showing in my file explorer and device manager but crashes if you try to click on it. It didn't appear on disk management nor on a disk check. It's assigned a drive letter on my computer." Present in two views, absent from a third, and fatal to the shell when opened. Those are not three symptoms — they are three different questions being answered differently, and together they place this precisely.

The decode: what each console is actually reporting

The device inventory: lists hardware that completed its introduction on the bus. The card reader and the card behind it announced themselves, so they appear. That is a statement about the device, not about anything readable on it.

The disk management console: lists storage the system can address as a disk — enumerating capacity, partition layout and volumes. It shows disks with damaged filesystems, disks with no partitions, and disks it cannot read, marking them accordingly. Absence from that view is the significant finding, because it means the system could not establish a usable disk at all.

The file manager showing a drive letter anyway: this is the part that looks contradictory and is not. A drive letter is an assignment the system makes and retains. Where a device was previously mounted, the letter and the entry can persist after the underlying storage stopped presenting itself — so the file manager displays something the disk console knows is not there. The letter is a leftover, not evidence.

Why clicking it crashes the shell: opening that entry sends the file manager to read a volume the system cannot address. Well-written code handles that; the shell also indexes, generates thumbnails and reads metadata automatically on access, and any of those meeting a device that does not answer — or answers with something malformed — can take the process down.

So the combined reading: the card is electrically present and its storage cannot be presented as a usable volume. The crash is a symptom of the shell trying, not an additional fault.

Why the disk check could not run: that tool needs a volume the system can address, and there is not one. Its failure is consistent rather than informative.

What works instead, and it is the same principle that recurs here: reading the card at block level, sector by sector, with the host's filesystem handling bypassed entirely. Nothing parses the structures, so nothing crashes — and the structures are then examined and repaired against the image where a failure costs nothing.

What must not be attempted: no format, no repair, and no further disk checks. The system will offer all three for a device in this state.

On the bench

No format, repair or disk check was attempted, all three being offered for a device in this state and each requiring or writing to a volume the system cannot address. The card was imaged write-blocked at block level with host filesystem handling bypassed behind the DeepSpar USB Stabilizer 10Gb — nothing parsing the structures and therefore nothing crashing, which is why capture succeeds where the file manager fails. Structures were reconstructed on the image, with signature carving alongside, and media validated by rendering.

The outcome

The card imaged at block level with host parsing bypassed, structures rebuilt on the copy and images validated by rendering. 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 decode: three consoles answering three questions. The device inventory lists hardware that introduced itself. The disk console lists storage the system can address — and absence there is the real finding. The drive letter in your file manager is a retained assignment left over from when it last mounted, not evidence that anything is there.

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.