Data Recovery Case File · Solid State & Flash · Two Handshakes, One Failing
Always in the BIOS, Never in the Operating System
His enquiry was the most thoroughly tested in this tranche and identified the crucial asymmetry himself. A 500GB Samsung SSD: "failing to boot my operating system, or be discoverable via disk management, or list-disk or getdisk console commands. Not showing up in Linux either. It would loop between the loading screen, 'diagnosing your PC' and black screen for BIOS options. The SSD always shows up in BIOS, however. Around 50GB of data I want from it. Suspected NAND or controller issues." He has eliminated Windows, its console tools and an entirely separate operating system, and found the one place the drive does appear. That gap — seen by firmware, invisible to every operating system — is not ambiguity. It describes a specific failure with a specific route.
| Media | 500GB Samsung solid-state drive — consistently enumerated by system firmware; not addressable by Windows disk tools, console utilities or a separate Linux environment; approximately 50GB required |
| Reported situation | Boot loop between loading and recovery screens · absent from disk management and console disk utilities · absent under Linux · consistently present in firmware setup · fault suspected at controller or memory level by the owner |
| Fault class | Identification succeeding while media addressing fails — firmware or translation-layer corruption rather than absence of the device |
| Equipment used | Vendor technological and safe-mode access (PC-3000 portfolio, SSD support) · firmware area and translation-layer assessment · imaging on restored addressing; contents verified by opening |
The decode: two different handshakes, and what fails between them
What the firmware sees: when a machine starts, its firmware performs a basic enumeration — it powers the drive, asks it to identify itself, and records what it says. That exchange is shallow. A drive appears in firmware setup if its controller is alive enough to answer a handful of identification questions. It does not mean the drive can be read.
What an operating system needs: considerably more. It asks the drive to report a usable capacity, then begins addressing actual storage — reading partition structures, then filesystems, then data. That requires the drive's translation layer: the internal map converting logical addresses into physical flash locations, held and maintained by the controller. If that map is corrupt or cannot be loaded, the drive can still answer identification questions while being unable to service a single real read. To an operating system, a drive that reports itself and then fails every read is unusable, so it is not presented at all.
Why his cross-platform testing settles it: Windows, its console tools and Linux are three independent implementations, and all three failing while firmware succeeds rules out drivers, operating-system bugs and configuration entirely. The behaviour is the drive's, consistently, everywhere. That is as complete an elimination as home testing allows, and it means no further testing is worth doing.
Refining his own suspicion: he suspects NAND or controller issues, which is the right neighbourhood with an important distinction inside it. If the memory had failed wholesale, the drive would generally not identify itself at all — it would be invisible everywhere including firmware. That it consistently identifies points instead at the controller's firmware and translation state: the drive is alive and its map is broken. That is the more tractable of the two, because firmware areas can be assessed and repaired through the manufacturer's own technological modes, after which the drive addresses its media normally and can be imaged.
Why the boot loop fits: the machine finds the drive during firmware enumeration, attempts to boot from it, fails at the first real read, falls into recovery, and repeats. The loop is the same failure seen from the top.
What to stop: the boot attempts. Each cycle powers a drive in a bad firmware state and asks it to do the thing it cannot, and drives in that condition occasionally degrade further with repetition.
On the bench
No further host testing was attempted, since three independent environments had already established the position. Access ran through the PC-3000 portfolio's SSD support: the controller addressed in its vendor technological modes, and the firmware area and translation layer assessed specifically — because a drive that identifies consistently and cannot service reads is describing a broken map rather than absent memory. The damaged modules were repaired until the drive would report a usable capacity and address its own media, after which imaging ran immediately and completely, prioritised to take his 50GB first. The contents were verified by opening.
The outcome
The firmware state repaired, media addressing restored and the required data imaged and verified. 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, for anyone whose drive appears in firmware and nowhere else: those are two different handshakes — firmware asks a drive to identify itself, which is shallow, while an operating system asks it to report a usable capacity and service real reads, which requires the internal map converting logical addresses to physical flash; a drive that identifies and cannot read has a broken map rather than dead memory, which is the more tractable fault and is repaired through vendor technological modes; and testing under a second operating system rules out drivers and configuration entirely. Stop the boot attempts.
Drive your firmware sees but no operating system will
Stop trying to boot from it — each attempt asks a drive in a bad state to do the one thing it currently can't, and repetition occasionally makes these worse. Read the gap correctly, because it's informative rather than confusing. Firmware setup performs a shallow enumeration: it powers the drive and asks it to identify itself, and a drive appears there if its controller can answer a few questions. An operating system needs far more — a usable reported capacity and the ability to service real reads, which depends on the internal map translating logical addresses to physical storage. A drive that identifies consistently and can't be addressed has a corrupted map rather than failed memory, which is the better of the two. Testing under a second operating system, as well as your usual one, is worth doing once — it rules out drivers and configuration completely.
That gap is the diagnosis — call Glasgow Data Recovery on 0141 404 0294; controller addressed in vendor modes, firmware and translation layer repaired, imaged with your priority taken first.
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.