Is My Dead SSD a Logical or a Physical Failure?
A logical failure leaves the drive detected at the correct capacity with a RAW or corrupted file system, and software might recover it. A physical or firmware failure leaves the drive undetected, reporting 0GB, identifying as SATAFIRM S11, or freezing the system. Software is impossible in that case; the recovery is hardware.
| Symptom | Logical corruption | Physical / firmware failure |
|---|---|---|
| BIOS detection | Drive detected with the correct model name & full capacity. | Not detected, reports 0GB, a tiny diagnostic size, or a factory string like SATAFIRM S11. |
| What you see | Drive shows up as RAW, unallocated, or asks to be formatted. | Drive missing entirely, or the system freezes on connect & POST hangs. |
| Controller state | Controller is alive, booted firmware, & presents a valid namespace. | Controller is dead, stuck in ROM mode, or holding the ATA BSY bit high. |
| Can software help? | Sometimes. Tools like R-Studio can scan a drive the OS still sees. | No. There is no enumerated endpoint for software to address. |
| What it needs | File-system or partition repair on a physically healthy drive. | Board-level repair or firmware reconstruction with PC-3000 SSD. |
If your drive still shows in BIOS at the right size and the only problem is a RAW volume, you are in logical territory and may not need a lab at all. This page is about the physical case: the drive the bus can't see. For the NVMe-specific reseat walkthrough, see NVMe SSD not detected in BIOS.
Why Can't Software Read a Dead SSD?
Recovery software operates through the operating system storage stack, which sits entirely above the controller. It needs the OS to present the drive as a block device with a valid capacity before it can scan one sector. A dead SSD never enumerates, so there is no bus target to address and nothing for software to read.
Disk Drill, EaseUS, PhotoRec, & R-Studio are good tools for the right job. That job is a physically healthy drive with a logical problem: deleted files before TRIM runs, a corrupted partition table, or a formatted volume. None of them can create a communication path that the hardware itself isn't providing. Software can't talk to a drive that won't power on or won't enumerate.
No Enumerated Endpoint
When a controller suffers a severe electrical failure (a dead PMIC, a shorted voltage regulator, or a shorted decoupling capacitor cutting controller power), the drive gets no power and never enumerates on the SATA or PCIe bus. If instead it hits a firmware panic and falls into ROM mode, it reports 0 bytes or a generic factory string like SATAFIRM S11, presenting no volume for software to open.
Protocol-Layer Rejection
When the Flash Translation Layer is corrupted, the controller rejects ATA and NVMe read commands at the protocol layer. The host issues a read; the controller refuses or never answers. Host-level software sees no addressable logical blocks to scan, because the controller that would translate those requests is the part that failed.
No Path to Physical NAND
The OS and software only know how to request logical blocks. They rely on the controller to translate those requests into physical NAND page addresses.
If the controller's processor is halted in a bootloader loop, dead from a power-rail collapse, or holding the ATA BSY bit high after an unhandled exception, that translation can't happen. There is no physical bus target for software to address, which makes software recovery electrically and logically impossible.
What Causes an SSD Controller to Fail?
SSD controllers die two ways: electrically and through firmware. An electrical death is a shorted PMIC, a blown voltage regulator, shorted decoupling capacitors cutting controller power, or a blown fuse. A firmware death is a panic state where the controller boots but can't load its translation tables from NAND.
Electrical Failure: Power Rails & Shorts
Every SSD has a power management IC that steps the host supply down into the rails the controller, DRAM, & NAND need. A surge, a failing PSU, or an improper shutdown can short the PMIC or a regulator. A dead short draws over 1A on the input rail; the shorted part overheats & shows up as a hotspot under a FLIR thermal camera within 2-3 seconds of power-on. An open circuit draws under 30mA and leaves the controller completely unpowered.
We diagnose this by bench-powering the drive and measuring current draw before anything else. The measurement tells us whether we are chasing a short or an open, and the FLIR scan tells us which component to remove. A shorted decoupling capacitor that pulls down the controller core rail looks identical to a dead drive from the outside, but on the bench it is a 20-minute fix.
Firmware Panic: ROM Mode & BSY State
A firmware panic happens when the controller has power but can't load its firmware or FTL from NAND. The Phison PS3111-S11 is the textbook case: on FTL corruption or a bad-block table overflow, it drops into ROM mode and identifies as SATAFIRM S11, reporting 0 bytes or a small diagnostic capacity. The controller is alive and reachable; it just refuses normal I/O.
Silicon Motion controllers fail into a different signature, the BSY state. The controller completes the SATA handshake, then hits an unhandled exception while parsing corrupted system blocks and holds the ATA BSY bit high indefinitely.
The host waits for a ready response that never arrives, which is why a BSY-state drive freezes the whole system the moment it is connected. SATAFIRM S11 belongs to Phison only; Silicon Motion shows BSY or a raw silicon descriptor, never the SATAFIRM string.
Is My Data Gone If a Dead SSD Freezes My Computer?
No. A freeze on connection is almost always a controller stuck in a BSY state, not erased NAND. The Silicon Motion controller holds the ATA BSY bit high after an unhandled exception, and the host hangs waiting for a response. Your data sits intact on the flash; the controller just can't present it.
The fix is to stop the controller from booting the corrupted firmware that triggers the exception. In the lab, that means holding the controller in a diagnostic state through a hardware test-pad short, then reading the NAND with a clean loader instead of the drive's broken boot sequence. The freeze is a symptom of where the controller halts, not evidence that the data is gone.
Do not keep power-cycling a frozen drive. Each boot attempt re-runs the firmware path that crashed the controller, and on a degraded controller that repeated stress can turn an interruptible panic into a dead chip.
What Should You Avoid With a Drive That Disappears Intermittently?
A drive that flickers in and out of detection is the most dangerous state, because the moment the OS sees it, it starts issuing commands that can destroy the data a lab needs. Stop troubleshooting once you confirm the drive is unstable.
- ✗Do not run CHKDSK or recovery software on an intermittent drive. Repeated reads against failing NAND degrade the cells further, and a write from CHKDSK can corrupt the metadata a lab uses to rebuild the FTL.
- ✗Do not let the OS "Initialize" a drive that flickers into view. If the controller briefly comes back, resumed garbage collection can overwrite FTL metadata, and an OS-issued TRIM can permanently erase blocks once the controller unmaps them.
- ✗Do not repeatedly power-cycle the drive. Each power cycle re-stresses a degraded controller and re-runs the boot path that failed, which can push a recoverable panic into a dead controller.
- ✗Do not reflow, heat-gun, or desolder the drive yourself. Uncontrolled heat degrades the charge stored in NAND cells and can lift the controller off its pads, which removes the one part that knows how to descramble your data.
Why Can't You Just Read the NAND Chips Directly?
Removing the NAND and reading it directly does not hand you your files. The controller scrambles data with a proprietary XOR pattern and layers LDPC error correction on top, and only that controller knows how to undo both. Reading raw dies yields scrambled, undecoded bits, not a file system.
The chip-off barrier on most consumer SSDs is not encryption. Even with hardware AES disabled, the XOR scrambling and LDPC soft-decision decoding bind the bits to the original silicon, so a raw die read is the start of a reverse-engineering problem, not a recovery. Some drives add optional hardware encryption on top of that, which makes a donor-controller swap useless because the media key is wrapped by the original controller's hardware root.
That is why the practical path for a dead SSD is to revive the original controller, not to lift its chips. Reviving the controller keeps the scrambling, the LDPC parameters, and any encryption context intact, so the data comes off readable. For a dead SSD, board repair IS data recovery.
How Does a Lab Recover Data From a Dead SSD?
PC-3000 SSD talks to a live controller over SATA or NVMe and works around the drive's broken boot sequence. The workflow holds the controller in a diagnostic state, injects a clean loader, rebuilds the translation layer from surviving NAND metadata, and reads the data without writing to the flash. Board-level repair comes first whenever the controller won't power on.
- Enter ROM / Technological Mode. Identify the panic state, then momentarily short the controller's test pads to stop it booting corrupted NAND firmware. Phison controllers enter through a momentary short of the ROM_CS test pad; on a stuck controller, shorting the R/B* pin breaks the firmware panic loop so the controller halts before it crashes.
- Inject a volatile loader. Use PC-3000 SSD to write a microcode loader straight into the controller's SRAM. The loader replaces the corrupted firmware for the session and gives the tool direct access to the NAND through the live controller.
- Reconstruct the FTL. Rebuild the logical-to-physical map from the surviving metadata in the NAND spare areas, without writing a single byte back to the flash. This is the step the corrupted firmware couldn't complete on its own.
- Raw NAND read & XOR descrambling. Read the NAND through the reconstructed map, then apply the controller's XOR descrambling and LDPC decoding so the bits resolve into the original file system. The recovered data is written to a separate target drive for return.
One distinction matters here. PC-3000 SSD interfaces with a live controller over the host bus; it does not read NAND dies directly. Raw chip-off die reading is a separate tool, PC-3000 Flash, and it only becomes the path when the original PCB is too damaged to repair. We default to reviving the controller because that keeps the XOR scrambling and LDPC context intact.
When the controller won't power on at all, board repair runs first. We isolate the shorted component under a FLIR thermal camera, remove it with an Atten 862 hot air rework station, and replace it with a donor part using a Hakko FM-2032 microsoldering iron on an FM-203 base station. For BGA-packaged controllers we use a Zhuo Mao precision BGA rework station. Reviving the original controller preserves its firmware configuration and any encryption context tied to its silicon.
Which Dead SSD Controllers Can Be Recovered In-Lab?
We recover Phison and Silicon Motion controllers on both SATA and NVMe drives, which covers most of the consumer market. A Phison PS3111-S11 in SATAFIRM S11 ROM mode is recoverable through the PC-3000 SSD diagnostic path. A PS5018-E18 with a PMIC or power-rail fault needs component-level board repair first, before any firmware access is possible. Silicon Motion controllers in a BSY state respond to the same test-pad entry and loader workflow once they have power.
Not every controller is supported, and we say so before you ship. Send the drive in for a free evaluation and we will identify the controller and tell you whether it is in our supported set before any work or charge. If it isn't, you pay nothing and we tell you straight.
How Much Does Dead SSD Recovery Cost?
Dead SSD recovery runs $200–$1,500 on SATA drives and $200–$2,500 on NVMe, depending on whether the fault is electrical or firmware. The exact tier follows the failure, not the drive's value.
A dead PMIC, a shorted regulator, or shorted decoupling capacitors land in circuit board repair: $450–$600 on SATA and $600–$900 on NVMe. This is the component-level microsoldering tier that revives the original controller, which is what keeps the encryption context and scrambling intact so the data reads back.
A controller stuck in ROM mode or a BSY state lands in firmware recovery: $600–$900 on SATA and $900–$1,200 on NVMe, where PC-3000 SSD reconstructs the corrupted FTL and system tables.
When the original PCB is too damaged to repair, the NAND chips transplant to a donor PCB: $1,200–$1,500 on SATA and $1,200–$2,500 on NVMe. That tier needs a donor drive. A donor drive is a matching SSD used for its circuit board. Typical donor cost: $40–$100 for common models, $150–$300 for discontinued or rare controllers. Diagnosis is free, there are no diagnostic fees, and +$100 rush fee to move to the front of the queue.
Low complexity
Simple Copy
Your drive works, you just need the data moved off it
Functional drive; data transfer to new media
Rush available: +$100
$200
3-5 business days
Low complexity
File System Recovery
Your drive isn't showing up, but it's not physically damaged
File system corruption. Visible to recovery software but not to OS
Starting price; final depends on complexity
From $250
2-4 weeks
Medium complexity
Circuit Board Repair
Your drive won't power on or has shorted components
PCB issues: failed voltage regulators, dead PMICs, shorted capacitors
May require a donor drive (additional cost)
$450–$600
3-6 weeks
Medium complexity
Most Common
Firmware Recovery
Your drive is detected but shows the wrong name, wrong size, or no data
Firmware corruption: ROM, modules, or system files corrupted
Price depends on extent of bad areas in NAND
$600–$900
3-6 weeks
High complexity
PCB / NAND Swap
Your drive's circuit board is severely damaged and requires NAND chip transplant to a donor PCB
NAND swap onto donor PCB. Precision microsoldering and BGA rework required
50% deposit required; donor drive cost additional
50% deposit required
$1,200–$1,500
4-8 weeks
Hardware Repair vs. Software Locks
Our "no data, no fee" policy applies to hardware recovery. We do not bill for unsuccessful physical repairs. If we replace a hard drive read/write head assembly or repair a liquid-damaged logic board to a bootable state, the hardware repair is complete and standard rates apply. If data remains inaccessible due to user-configured software locks, a forgotten passcode, or a remote wipe command, the physical repair is still billable. We cannot bypass user encryption or activation locks.
No data, no fee. Free evaluation and firm quote before any paid work. Full guarantee details. NAND swap requires a 50% deposit because donor parts are consumed in the attempt.
- Rush fee
- +$100 rush fee to move to the front of the queue
- Donor drives
- A donor drive is a matching SSD used for its circuit board. Typical donor cost: $40–$100 for common models, $150–$300 for discontinued or rare controllers.
- Target drive
- The destination drive we copy recovered data onto. You can supply your own or we provide one at cost plus a small markup. All prices are plus applicable tax.
Frequently Asked Questions
Can data recovery software fix an SSD not detected in BIOS?
Why is my SSD showing 0 bytes capacity?
What does SATAFIRM S11 mean?
Is my data gone if my dead SSD freezes my computer?
How much does it cost to recover a dead SSD?
Board Repair Is Data Recovery for a Dead SSD
Most labs outsource board-level failures or call a dead controller unrecoverable. We do the microsoldering in-house. Founded in 2008, single Austin location, no franchises, no outsourcing, and 4.9 stars across 1,837+ Google reviews. The tech who diagnoses your drive is the tech who repairs it.
Diagnosis is free and there is no charge if we recover no data. Ship the drive to our Austin lab and we will tell you exactly what failed before any work begins.
Related services
Related Recovery Services
SSD dead, not detected, or showing 0GB?
Free evaluation. SATA $200–$1,500, NVMe $200–$2,500. No data, no fee. Ship your drive to our Austin lab.