Call us — 0113 322 3083
Mon–Fri · 9am–5:30pm · No fix, no fee
Start a free diagnostic →

Data Recovery Case File · Solid State & Flash · It Failed While He Watched

SSD Not Detected in BIOS: It Failed While He Watched

His account is unusual because it records a failure happening in stages over a single session, and that sequence is worth more than any single symptom. "I was using my laptop and it blue screened. It restarted and seemed to load Windows to my password screen. I left my laptop, and when I returned later it wouldn't boot — it said no bootable drive. I opened the BIOS and found my drive wasn't recognised. I took it out; the laptop works fine without it. On my PC, the drive still isn't recognised or detectable." Most drive failures are discovered after the fact. This one was observed in progress — and read in order, the three stages describe a controller degrading over minutes rather than dying instantly, which explains the blue screen, the brief recovery, and the silence that followed.

MediaToshiba solid-state drive from a laptop — system crash followed by partial recovery and then complete loss of detection; absent from BIOS on the original machine and on a second computer
Reported situationBlue screen during use · restart reached the password prompt · subsequent failure to boot with no bootable device reported · drive absent from BIOS; host confirmed working without it; second machine also fails to detect
Fault classProgressive controller or firmware failure observed across a single session — no enumeration; controller-level access the realistic route
Equipment usedVendor technological and safe-mode access attempts (PC-3000 SSD support) · controller state and firmware area assessment · imaging on restored access · honest limits stated where controller-level access proves unavailable

The decode: three stages, and what each one means

Stage one — the blue screen. Not an unrelated event, and this is the part people usually miss. Windows produces a stop error when it hits something it cannot recover from, and a substantial proportion of those are storage errors: the operating system asked the drive for data, the drive failed to supply it or returned an error the system could not handle, and the machine stopped rather than continuing with corrupted state. So the crash was not a coincidence that preceded a drive failure — it was, very probably, the first visible symptom of it.

Stage two — reaching the password screen. Genuinely informative. After the restart the machine loaded far enough to present the login prompt, which means the drive was still delivering data at that point: the boot sequence read the firmware, the boot loader and a substantial part of the operating system successfully. So the drive was not dead — it was failing, and still partly working.

Stage three — no bootable drive, and BIOS invisibility. By the time he returned, the drive had stopped answering the most basic question a machine asks: identify yourself. Absence from the BIOS is the lowest-level verdict a computer offers, because that check precedes any operating system, driver or utility — which also means no software-level fix applies, and that advice about drive letters, initialising or repair tools is simply irrelevant here.

Why the staged timeline matters: it tells us this was a controller failure progressing over minutes, rather than a component failing instantly. That is the characteristic way SSDs end: the controller's own management data becomes inconsistent, it copes for a while, degrades, and then can no longer complete the start-up that lets it identify itself. His elimination confirms it travelled with the drive — the laptop works without it, and a second machine sees nothing either. Nothing external remains to test.

What can honestly be done: the realistic route on an SSD runs through the controller rather than around it, using vendor technological and safe modes that can sometimes bring up a drive whose normal start-up fails, allowing the firmware area to be repaired and the drive imaged. That succeeds often enough to be well worth attempting. Where it does not, the fallback is narrower than for cards or sticks — the address mapping and often the encryption keys live inside the controller, so reading the memory chips directly does not reliably produce readable data. That limit is stated in advance rather than discovered at the end.

On the bench

Nothing further was attempted on ordinary interfaces, since his testing across two machines had exhausted what those establish. Access was attempted through the PC-3000 portfolio's SSD support: the controller addressed in its vendor technological modes, its state examined, and the firmware area assessed for the inconsistency that typically prevents a drive completing start-up — the specific fault his staged timeline pointed at. Where that access succeeded, the drive was brought to a readable state and imaged immediately and completely, and the volume was verified from the image before delivery. The honest alternative had been set out in writing beforehand so the answer arrived as an expectation rather than a surprise.

The outcome

Controller-level access attempted on the only route this class of device offers, with the position and its limits stated in writing in advance. 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 failed in front of them: a blue screen is frequently the first symptom of a storage failure rather than an unrelated crash, so treat one followed by any drive trouble as a single event; reaching a login screen afterwards proves the drive was still delivering data at that point and was failing rather than dead; and BIOS invisibility is the lowest-level verdict there is, so no software-level advice applies. Testing in a second machine completes the elimination — after that, stop, because further power cycles can worsen a bad controller state.

Blue screen, then the drive disappeared

Treat those as one event rather than two. A stop error is often the first visible symptom of a storage failure — the system asked the drive for something, didn't get it, and halted rather than continuing with corrupt state — so a crash followed by drive trouble is usually the same fault, not bad luck twice. If the machine reached a login screen afterwards, that's useful evidence too: the drive was still delivering data then, so it was failing rather than dead. Once the BIOS can't see it, stop: that check runs before any operating system, so nothing at the Windows level can help, and advice about drive letters, initialising or repair tools doesn't apply. Testing it in a second machine finishes the elimination — after that, don't keep power-cycling it, because a controller in a bad firmware state can be made worse. Keep the drive; nothing degrades on a shelf.

Drive gone from the BIOS after a crash?
Your testing is complete — call Leeds Data Recovery on 0113 322 3083; controller addressed in vendor technological modes, firmware area assessed, honest limits stated in writing 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.

0113 322 3083