Call us — 0161 871 0788
Mon–Fri · 9am–5:30pm · No fix, no fee
Start a free diagnostic →

Data Recovery Case File · Solid State & Flash · Which Answer Was Right

A Built-In Diagnostic Reporting Critical Failure Is Testing the Device Itself

His enquiry reports two diagnoses and a machine that agrees with one of them. A desktop where, "following several updates, the computer shut down and failed to restart, and the diagnostics issued a critical disc failure" — while support said first that it was software and then that it was hardware. The machine's own test is the more reliable of the three opinions, because it is the only one that examined the drive.

MediaSolid-state drive from a desktop machine — built-in diagnostic reporting critical device failure following a shutdown after system updates; machine not restarting
Reported situationDesktop machine receiving several system updates · machine shutting down and failing to restart · built-in diagnostic reporting a critical disc failure · manufacturer support attributing the fault first to software and then to hardware · drive dispatched for recovery · content required
Fault classDevice-level failure confirmed by built-in diagnostics — update sequence coincident rather than necessarily causal; memory not implicated by controller state
Equipment usedBuilt-in diagnostic result treated as a device-level finding rather than an opinion · device addressed through hardware with imposed timeouts rather than the host stack · controller state assessed in vendor technological modes · chip-level read past the controller with translation layer reconstructed in software

The decode: what the diagnostic did, and how to weigh three answers

What a built-in diagnostic actually does: talks to the drive directly, below the operating system. It requests the device's own health reporting and runs defined tests against it, and it reaches a conclusion from responses rather than from symptoms.

Why that outranks both support answers: the diagnostic examined the drive; the support line examined a description. A remote diagnosis is an inference from what the caller reports, and it changes when the description does — which is exactly what he observed.

Why support was not being evasive: the first answer was reasonable. A machine failing to restart after updates genuinely does suggest software, and that is the commoner cause by a wide margin.

Why the second answer superseded it: the diagnostic result changes the picture. Once a device-level test reports critical failure, software explanations stop accounting for the evidence, and revising is the correct response rather than an inconsistency.

What the updates most likely contributed: the power cycles rather than the software. Applying updates involves repeated restarts, and start-up is when a solid-state controller must read its management tables in full — which is where these devices disproportionately fail.

Why that matters for how he thinks about it: the updates did not corrupt anything. They provided the occasions on which a failing controller was asked to start, and one of those occasions was the last.

Why a failure that follows an update looks causal without being so: the sequence is memorable and the coincidence is common. Any activity involving restarts will precede this class of failure, simply because restarts are when it surfaces.

What critical failure means about prospects: less than it sounds. It describes the device failing its tests, not the memory being erased — and on a solid-state drive the component that fails is almost always the controller rather than the storage.

Why the memory is likely intact: the controller manages and speaks for the storage. A controller unable to complete its start-up does not alter what the memory holds, which is the basis for reaching it another way.

What must not happen: no firmware update and no vendor repair utility. Both write to the component that has failed, and both are commonly suggested for a drive reporting critical status.

On the bench

The built-in diagnostic result was treated as a device-level finding rather than an opinion — such tests communicating with the drive below the operating system and concluding from its own responses, whereas remote support infers from a caller's description and revises when that description changes. Update sequences involve repeated restarts, and start-up is when a controller reads its management tables in full, which is where solid-state failures concentrate. Chip-level reading was performed past the controller.

The outcome

The diagnostic treated as a device-level finding, the device addressed through hardware, and the memory read past the controller. 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: the machine's own test is the opinion that examined the drive. Support was not being evasive — a restart failure after updates does suggest software, until a device-level test says otherwise.

Weighing a diagnostic against what support tells you

Give the built-in diagnostic more weight than either remote answer, since it communicates with the drive below the operating system and concludes from the device's own responses, while a support line infers from your description and reasonably revises when that description changes. Read the update sequence carefully too: updates involve repeated restarts, and start-up is when a solid-state controller must read its management tables in full, which is where these drives disproportionately fail. So the updates supplied the occasion rather than the cause. Don't run a firmware update or vendor repair utility.

Diagnostic reporting critical drive failure?
Don't run a firmware update — call Manchester Data Recovery on 0161 871 0788; diagnostic treated as a device-level finding, addressed through hardware with imposed timeouts, memory read past the controller.
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.