Data Recovery Case File · Solid State & Flash · Partway and No Further
A Controller That Begins and Does Not Finish Has Failed Mid-Sequence
His enquiry describes a start-up that gets underway and stalls. An external solid-state drive where "the power light comes on and the drive starts to come up, but then stops and doesn't connect." Beginning and not finishing is a more specific finding than doing nothing — the controller is running, executing its start-up, and failing at a particular point in it rather than being dead.
| Media | External solid-state drive — power indication present, start-up sequence commencing and terminating before enumeration; no host connection established |
| Reported situation | External solid-state drive no longer readable · power indicator illuminating on connection · start-up sequence observed to begin · sequence stopping before completion · no connection established with the host · content required |
| Fault class | Controller start-up terminating mid-sequence — partial execution indicating functioning control logic; memory not implicated by the point of failure |
| Equipment used | Partial start-up interpreted as mid-sequence failure rather than absent function · 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 a start-up involves, and what stopping partway indicates
What a solid-state drive does before appearing anywhere: a sequence. Its controller powers, runs its own program, reads the tables describing how content is distributed across the memory, verifies its internal state, and only then introduces itself to a host — several steps, in order, each depending on the one before.
Why beginning matters: the controller is executing. A dead controller does nothing observable at all, so a drive that visibly starts has working power regulation and functioning control logic — which is a meaningful amount of the device.
Why stopping partway is the informative part: the sequence reached something it could not complete. The commonest point is reading the tables that map content to its physical location, which are stored in the memory itself and are large and complex.
Why that particular step is a common failure point: those tables are written and rewritten constantly during normal use. They are the most frequently modified structures on the device, and an interruption or a degraded region affecting them stops the controller before it can present anything.
Why the memory is very likely intact: the failure is in reading a management structure, not in the storage of content. The regions holding files are not involved in the start-up sequence at all, and they retain what was written to them.
Why this differs from the drive being dead: the distinction matters for the approach. A device that cannot execute needs its memory read past a non-functioning controller; one that executes and stalls can often be worked with through the controller itself, in modes reached over a diagnostic interface rather than through a host connection.
Why the host connection failing is expected rather than additional: enumeration is the last step of the sequence. A controller that stops before reaching it never announces itself, so no computer sees the drive — one failure accounting for the whole symptom.
Why repeated connection attempts add nothing: the sequence is deterministic. It will stop at the same point every time, because the same structure is unreadable on each attempt.
What is done instead: the device is addressed through hardware that does not wait on a host handshake, its internal state examined, and where the mapping tables cannot be repaired, the memory is read directly with the distribution scheme reconstructed from the data itself.
What must not happen: no firmware update and no vendor repair utility. Both write to the controller's own program area, which is the component partially working and the one everything depends on.
On the bench
Partial start-up was interpreted as mid-sequence failure rather than absent function — a controller powering, executing its program, reading the tables mapping content to physical locations, verifying internal state and finally enumerating, each step dependent on the last, so visible commencement indicates working power regulation and control logic while termination indicates a step that could not complete. Mapping tables are the most frequently rewritten structures and a common failure point. Chip-level reading was performed past the controller.
The outcome
The partial start-up read as mid-sequence failure, 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: beginning and not finishing is better news than doing nothing. Your controller is executing and stalling at a step — most often reading the tables that map content to its location, which are not where your files are.
A drive that starts to come up and stops
Stop reconnecting it and don't run a firmware update — the sequence is deterministic and will stop at the same point every time, while a firmware operation writes to the controller's own program area. Read the partial start-up as informative: a dead controller does nothing observable, so a drive that visibly begins has working power regulation and control logic. What usually fails is reading the tables mapping content to its physical locations, which are the most frequently rewritten structures on the device. Your files sit in regions the start-up sequence never touches.
Stop reconnecting it — call Easy Data Recovery on 028 9002 0144; partial start-up read as mid-sequence failure, 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.