Data Recovery Case File · Desktop Externals & Aging Drives · Two Lists, One Device
Appearing in a Device List and Not in a File Browser Places the Fault Above the Hardware
His enquiry contains a contrast that does the diagnostic work by itself. A drive holding photographs, "not being recognised by the file browser on PC or laptop — however it appears in the list of devices" shown by a recovery utility. Two programs on the same machine disagree, and the disagreement is not a contradiction: they are asking different questions, and only one of them requires a readable volume.
| Media | 1TB external hard drive holding photographic content — absent from host file browsers on two machines while enumerating in a recovery utility's device listing |
| Reported situation | External drive not appearing in the file browser on a desktop machine · same result on a laptop · drive appearing in the device list presented by a recovery utility · photographic content held · recovery sought |
| Fault class | Device enumerating with volume not interpretable — filesystem structures damaged or partition record unreadable; hardware demonstrated functional by device-level visibility |
| Equipment used | Device-level visibility accepted as demonstrating hardware function · no scanning permitted from the host before capture · imaged write-blocked at the block level under strict per-sector timeouts · filesystem structures interpreted with their duplicate copies · content carved independently where structures did not reconcile |
The decode: why the two lists differ, and what that establishes
What a file browser lists: volumes. It shows places you can put files, which requires a filesystem the system has read, understood and mounted — several steps beyond the device simply existing.
What a recovery utility lists instead: devices. It enumerates physical storage the system has detected, whether or not any volume on it can be interpreted, because unreadable volumes are precisely what it exists to work on.
Why that makes the disagreement informative rather than confusing: each program is answering its own question correctly. The device is present and the volume is not readable — and each tool reports the half it cares about.
What appearing at device level establishes: the hardware works. Power reached the drive, it spun up, identified itself, reported its capacity and was accepted by the system — an exchange no failing drive completes.
Why that eliminates the expensive outcomes: board faults, firmware-stage failures and mechanical problems all prevent enumeration. A drive listed as a device has passed the point at which any of those would have stopped it.
What is left, and it is the cheaper class: the structures describing the volume. A damaged partition record or filesystem header makes a drive invisible to a browser while leaving it fully readable at device level.
Why testing on two machines was worth doing: both behaved identically. That removes the host, the port and the operating system, and confirms the fault travels with the drive rather than with either computer.
Why he should not now scan it with that utility: the tool that sees the device will offer to search it. A scan reads the entire surface repeatedly and is the most demanding operation available, on a drive whose condition is not yet established.
Why capture comes before any search: an image secures whatever reads while the drive is co-operating. Every subsequent attempt runs against the copy, so a scan that goes badly costs nothing.
Why the structures can usually be rebuilt: filesystems keep duplicate copies of their key records elsewhere on the volume. Where the duplicate survives, folders and names return with the content.
On the bench
Device-level visibility was accepted as demonstrating hardware function — a file browser listing volumes, which requires a filesystem read, understood and mounted, whereas a recovery utility enumerates detected physical devices irrespective of volume readability. Appearance at device level establishes power, rotation, identification and capacity reporting, excluding board, firmware-stage and mechanical causes. No scanning was permitted from the host before capture; imaging ran write-blocked under strict per-sector timeouts.
The outcome
Device-level visibility accepted as demonstrating hardware function, no host scanning permitted before capture, and structures interpreted with their duplicate copies. 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: the two programs are not contradicting each other. One lists volumes and the other lists devices — so your drive exists and its volume cannot be read, which is the cheaper of the two problems.
When a recovery tool sees a drive your file browser cannot
Don't let that tool scan it yet — capture first, because a scan reads the whole surface repeatedly and is the most demanding thing you can ask of a drive whose condition isn't established. Read the disagreement as informative: a file browser lists volumes, which requires a filesystem read and mounted, while a recovery utility lists detected devices whether or not any volume is interpretable. So your drive is present and its volume isn't readable — which rules out board, firmware and mechanical faults, since none of those would let it enumerate at all.
Capture before scanning — call Manchester Data Recovery on 0161 871 0788; device-level visibility accepted as demonstrating hardware function, imaged under capped timeouts, structures interpreted with their duplicate copies.
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.