Why an SSD Reports 0 Bytes

When an SSD reports 0 bytes in the operating system's disk management tool, it means the controller is not presenting any storage capacity to the host. The drive may appear in the BIOS or device manager with its correct model number, but it shows 0 bytes or no usable partitions. This symptom has three distinct causes at the hardware/firmware level, each requiring a different diagnostic and SSD data recovery approach.

Three Causes of the 0-Byte Symptom

Controller Failure

The SSD controller is a system-on-chip that runs the drive's firmware, manages the NAND interface, handles encryption, and communicates with the host over SATA or NVMe. If the controller sustains damage (from power surges, thermal failure, or silicon defects), it cannot execute the firmware needed to present the drive's capacity to the host.

Controller failures manifest differently depending on the failure mode. A complete failure means the drive does not respond to the host at all. A partial failure may allow the drive to appear in the BIOS with a generic or garbled model name (because the controller's ROM is accessible but the firmware cannot fully initialize). Some controllers enter a "safe mode" that identifies the drive but blocks data access until the firmware issue is resolved.

Recovery from a controller failure depends on the encryption status. If the controller uses always-on encryption (Samsung, Silicon Motion, Marvell controllers), the media encryption key (MEK) is stored in the controller silicon. Replacing the controller loses the key unless it can be transferred. PC-3000 SSD supports key extraction from certain controller families before replacement.

FTL Corruption

FTL corruption is the most common cause of the 0-byte symptom, particularly after power loss. The Flash Translation Layer maintains the mapping table between logical block addresses and physical NAND locations. This table is cached in DRAM and periodically flushed to NAND. If power is lost during a flush, the mapping table in NAND may be incomplete or inconsistent.

When the controller boots and finds a corrupted FTL, it cannot reconstruct the logical view of the drive's storage. The controller reports 0 capacity because it has no valid mapping to present. The data is still in the NAND cells in the physical pages where it was last written; only the index to find it is damaged.

Some controllers attempt automatic FTL repair on boot. If this succeeds, the drive initializes normally (possibly with some data loss from the incomplete flush). If auto-repair fails, the controller enters a diagnostic mode. PC-3000 SSD can access this mode and manually rebuild the FTL by scanning NAND pages for embedded metadata (LBA stamps and sequence numbers).

NAND Degradation

NAND cells wear out after a finite number of program/erase cycles. As cells degrade, the bit error rate increases. When the errors exceed the ECC engine's correction capability, blocks become unreadable. If enough metadata blocks (those storing the FTL mapping table, bad block tables, or controller configuration) become unreadable, the drive cannot initialize.

NAND degradation differs from FTL corruption in that the data itself may be damaged, not just the map to find it. Worn cells may have lost charge, flipping bits in the stored data. Recovery from NAND degradation involves reading raw NAND pages and applying maximum-strength ECC decoding, sometimes with adjusted read reference voltages (voltage threshold shifting) to optimize bit accuracy on worn cells.

How Lab-Level Diagnosis Distinguishes the Causes

1. Physical inspection. Check for burned components, damaged solder joints, or swollen capacitors on the PCB. Visible damage points to controller or power delivery failure.
2. BIOS/UEFI detection. If the drive appears with its correct model name and serial number, the controller is functional and the issue is likely FTL corruption. If it appears with a generic name or does not appear at all, the controller is suspect.
3. Vendor-specific diagnostic mode. PC-3000 SSD sends manufacturer-specific commands to query the controller's internal state: firmware version, FTL status, SMART data, NAND health counters. This reveals whether the FTL loaded, how many bad blocks exist, and whether the NAND is within endurance limits.
4. Raw NAND sampling. Reading a small sample of NAND pages and checking the bit error rate indicates NAND health. A BER within ECC correction limits suggests FTL corruption (data intact, map damaged). A BER exceeding ECC limits suggests NAND degradation (data itself compromised).

Controller-Specific Behavior at the 0-Byte Symptom

Each controller family responds to firmware corruption in its own way. The string the host reads in the BIOS, whether the controller exposes a safe or loader mode, and whether AES-256 is bound to the controller die together determine which recovery path is realistic. The table below summarizes published controller behavior and PC-3000 SSD utility support for the families we see most often on the bench.

Two specific guardrails apply when reading vendor literature on these families. First, Samsung Elpis, Pascal, and Piccolo NVMe controllers do not currently have a public PC-3000 SSD technological-mode loader, so any product page claiming a software-only bypass of an Elpis firmware panic is inaccurate. Second, SandForce SF-2281 was marketed as AES-256 but Intel confirmed in 2012 that the silicon implementation operates at AES-128; technical reference material should reflect that hardware fact rather than the original specification sheet.

Firmware Lock vs Hardware Failure

Inside the "controller failure" row of the table above, two very different states look identical from outside the case. A firmware-locked controller is electrically alive, accepts ATA or NVMe identify queries, and returns a generic descriptor because the firmware in NAND is unreadable. A hardware-failed controller has lost power delivery, shorted, or suffered die damage and either does nothing or pulls the power rails down. Diagnosis is non-destructive and runs in this order.

1. FLIR thermal sweep with brief power. The bare PCB is placed under a FLIR thermal camera, power is applied for a few seconds, and the controller, PMIC, and regulators are observed. A localized thermal spike at the controller or PMIC indicates a dead short; power is removed immediately and the failure is treated as hardware.
2. Voltage rail probing. If the thermal image is clean, a multimeter confirms the core and NAND rails are at their target voltages. A rail that is missing or sagging points to a damaged regulator that must be rebuilt before any further work, and the rework is performed under a microscope with a Hakko FM-2032 microsoldering iron.
3. Host identification on a diagnostic port. With clean rails verified the drive is connected to a host adapter to observe identify behavior. If the device returns a generic silicon string (such as "SATAFIRM S11" or "SM2258AB") or a placeholder capacity, the controller is alive and the failure is firmware-side. If the device remains undetected with healthy rails, the controller die is the likely cause.
4. ROM pin or test-point safe mode. A controller that answers identify queries is then forced into safe mode using the documented ROM-short or test-point bridge for its family. If the controller drops into mask ROM and accepts vendor commands, the silicon is functional and the corruption is isolated to the FTL or service area in NAND.
5. Loader injection and NAND health probe. The PC-3000 SSD utility uploads the loader matched to that controller and NAND combination, reads a sample of physical pages, and inspects the raw bit error rate. A BER inside ECC headroom confirms a firmware-only failure that an FTL rebuild can address. A BER above ECC headroom points back to NAND degradation, even when the controller is otherwise healthy.
6. Escalation to component rework. When the controller is electrically dead and the architecture has no hardware encryption that binds the data to the original die, NAND packages are lifted with an Atten 862 hot air rework station or a Zhuo Mao precision BGA rework station and transplanted to a matching donor PCB. On any architecture with on-die AES, the same packages are kept in place and the engineer rebuilds the original PCB so that the original controller can resume decryption.

PC-3000 SSD Loader and Safe Mode

The names PC-3000 SSD uses for these states differ from the public datasheets, and the difference matters when reading vendor documentation.

Safe mode

A hardware-initiated state entered by shorting the controller's diagnostic test pads or ROM pin during power-on. The bridge instructs the controller to skip the firmware overlays in NAND and run only from internal mask ROM. The drive is reachable over the host bus but exposes nothing more than a minimal bootstrap.

Technological mode

A software-initiated state established after safe-mode contact. The PC-3000 SSD utility issues vendor-specific commands that upload a volatile microcode loader into the controller's SRAM. The loader is tailored to the exact controller silicon and NAND part and replaces the dead firmware for the length of the recovery session.

Loader

The volatile microcode binary itself, matched to the controller revision and NAND identifier. A mismatched loader either refuses to attach or returns nonsense, which is why family-by-family loader libraries exist inside PC-3000 SSD rather than a single universal tool.

Once technological mode is established, the loader exposes a different command vocabulary than ordinary SATA or NVMe. It disables background garbage collection, suspends wear leveling, suppresses deterministic-read-zero-after-trim, and lets the engineer address physical NAND pages directly instead of logical block addresses. From there the workstation can read page spare areas, recover sequence numbers, dump the service area, and rebuild the flash translation layer in host RAM. Background details on the equipment side live on the PC-3000 reference page.

Loader mode is also why chip-off recovery is not a substitute on encrypted SSDs. Modern controllers run every read and write through a hardware AES pipeline, with the media encryption key fused into one-time-programmable cells on the controller die. If NAND packages are desoldered and read in a standalone programmer, the output is ciphertext and there is no key to decode it. Rebuilding the FTL on these drives requires the original controller alive in loader mode, decrypting raw pages on the fly so the workstation receives plaintext to map. The controller encryption reference walks through that pipeline in more detail.

Frequently Asked Questions