NVMe SSD Data Recovery

NVMe SSD data recovery retrieves files from Non-Volatile Memory Express solid-state drives that have stopped working. NVMe drives use PCIe lanes instead of SATA cables, which creates different failure points: controller burnout from heat, firmware corruption after power loss, and PCIe lane electrical faults.

Recovery requires specialized hardware that speaks the NVMe protocol. Consumer data recovery software cannot communicate with a failed NVMe controller.

NVMe recovery is more complex than SATA SSD recovery because NVMe controllers use the PCIe bus with up to 64,000 I/O queues, hardware-bound AES-256 encryption, and vendor-specific firmware architectures. SATA recovery tools that send ATA commands over AHCI cannot communicate with an NVMe controller at all. Recovery requires hardware that acts as a PCIe Root Complex.

The core difference: when a SATA SSD controller fails, chip-off NAND extraction sometimes works as a fallback because many SATA controllers don't encrypt data. When an NVMe controller fails, the encryption key dies with it. Board-level microsoldering to revive the original controller is the only path to decrypted data on most NVMe drives.

Yes: USB-to-NVMe enclosures use a bridge IC (Realtek RTL9210B, JMicron JMS583, or ASMedia ASM2362) to translate NVMe commands into USB protocol. When the bridge IC overheats or fails, the NVMe drive inside is often intact but the enclosure stops responding. Users frequently mistake a dead bridge IC for a dead NVMe drive.

Thunderbolt 3/4 & USB4 enclosures run hotter than USB 3.2 models because they push higher bandwidth through a compact aluminum shell. Sustained file transfers heat the bridge IC past its thermal limit, and repeated thermal cycling weakens the solder joints on the bridge chip.

Before Assuming the Drive Is Dead

1. Remove the M.2 NVMe drive from the enclosure. Most enclosures use a tool-free slide mechanism or a single Phillips screw. Handle the drive by its edges; don't touch the gold connector pins.
2. Install the drive directly into a desktop motherboard M.2 slot. This bypasses the USB bridge entirely. If the drive appears in BIOS and shows its correct model name & capacity, the enclosure bridge IC was the problem, not the NVMe drive.
3. Do not leave a failing drive powered in the enclosure. A bridge IC that drops the connection under load causes repeated connect/disconnect cycles that stress the NVMe controller. If the drive has a logical issue (deleted files, RAW partition), the controller uses idle time to execute TRIM & background garbage collection, permanently erasing recoverable data.

If the drive doesn't appear in BIOS after direct M.2 installation, the NVMe controller has a hardware or firmware failure. At that point, send the bare drive to our Austin lab for PC-3000 diagnostic imaging. USB bridge failures don't damage NAND data, so recovery prognosis is strong if you stop using the enclosure before the controller takes additional stress.

M.2 NVMe form factor determines which devices use the drive, how it fails, and what adapter connects it to PC-3000 for diagnostic imaging. M.2 2280, 2230, and 2242 share the NVMe protocol but differ in physical size, connector keying, and thermal behavior. We recover all M.2 sizes and keying configurations at our Austin lab.

See the PC-3000 tool overview for how the diagnostic hardware interfaces with NVMe controllers across all M.2 form factors.

M-Key vs B+M-Key Connector Keying

The M.2 connector uses mechanical notches ("keys") to prevent inserting an incompatible module. Keying also determines how many PCIe lanes the drive can use, which affects recovery adapter selection.

M-Key (right-side notch)

Supports PCIe x4 (four lanes). This is the standard for all high-performance NVMe drives: Samsung 980/990 Pro, WD Black SN850X, Crucial T700. Recovery adapters must provide a full x4 PCIe connection. Using an x2 adapter on an M-key drive cuts available bandwidth and can cause PC-3000 read timeouts on drives with marginal controller health.

B+M-Key (dual notch, both sides)

Physically fits both B-key and M-key M.2 slots but is electrically limited to PCIe x2 (two lanes) or SATA. Common on budget Gen3 NVMe drives and older SATA M.2 SSDs. Not all USB-to-NVMe enclosures support the NVMe protocol over B+M-key; some legacy enclosures wire B+M slots for SATA only. Forcing an M-key NVMe drive into a legacy B-key or SATA-only enclosure bends the connector pins and damages the PCIe contact pads.

Physical Damage Patterns by M.2 Size

Smaller M.2 form factors concentrate more components into less PCB area, creating different mechanical and thermal failure patterns than full-size 2280 drives.

Steam Deck and Surface Pro SSD Extraction

Handheld and ultraportable devices use M.2 2230 NVMe drives in tight enclosures with device-specific access methods. Improper extraction risks physical damage to the drive and the device.

2230 NVMe Controller Failure Modes

The 2230 drives in handheld devices share three failure patterns driven by their DRAM-less architecture and constrained thermal environment.

1. HMB FTL corruption from suspend/resume cycles. Handhelds aggressively sleep and wake the SSD. If power drops before the controller finishes flushing its HMB cache to NAND, the Flash Translation Layer mapping table corrupts. The drive enters a BSY (busy) firmware state and stops responding to standard NVMe commands. For supported controllers (Silicon Motion SM22xx family, Phison PS50xx), PC-3000 enters Technological Mode to reconstruct the FTL from surviving NAND metadata. Proprietary controllers (WD, Samsung) require alternative diagnostic approaches.
2. BGA solder micro-fractures from thermal cycling. The controller runs hot in a space with minimal airflow. Repeated expansion and contraction of the solder connections between the BGA controller and the PCB causes microscopic cracks. The drive works intermittently at first, then fails permanently. Repair requires reflowing or reballing the BGA connections using a precision rework station.
3. Controller burnout from sustained writes. Large game downloads or OS updates push sustained write loads that exceed the thermal budget of a 30mm PCB. Without a heatsink, the controller hits its thermal junction limit and shuts down. Repeated overheating degrades the controller silicon permanently. FLIR thermal imaging identifies the failed component before we apply power, preventing cascading damage.

The PC-3000 Portable III acts as a PCIe Root Complex, managing memory mapping and doorbell signaling to communicate with NVMe controllers that have entered a fault state. Each controller family requires a vendor-specific diagnostic module. The five-step workflow below covers every case from pre-power inspection through final file extraction.

PC-3000 tool overview and hardware specifications

1. 01

   Pre-Power Inspection

   FLIR thermal camera scans the drive for shorts before applying power. Voltage rails are tested individually with a bench power supply to isolate failed components. This prevents cascading damage from powering a shorted board.

2. 02

   Controller Identification

   Identify the NVMe controller die markings and NAND configuration. This determines which PC-3000 Active Utility to load: Samsung NVMe, Phison NVMe, Silicon Motion, or Universal NVMe for controllers without dedicated support (WD proprietary, Maxio).

3. 03

   Technological Mode Entry

   PC-3000 forces the controller into its vendor diagnostic mode (Technological Mode). In this mode, the controller bypasses its normal boot sequence and firmware validation, allowing direct access to NAND through the controller's hardware ECC and descrambling engines.

4. 04

   FTL Reconstruction

   If the Flash Translation Layer is corrupted, PC-3000 scans surviving FTL metadata spread across NAND pages to reconstruct the logical-to-physical block mapping. This process restores the drive's ability to present its file system to the OS.

5. 05

   Sector-by-Sector Imaging

   Once the controller responds, the entire drive is imaged sector-by-sector to a known-good destination drive. Bad sector maps are generated to track unreadable regions. Files are extracted, verified against directory structure, and returned on your choice of media.

Phison and Silicon Motion are the two NVMe controller families with mature PC-3000 Active Utility support. Each family has a different diagnostic-mode entry method, a different way to bypass the corrupted firmware running in the controller's internal RAM, and a different metadata structure that the technician must reconstruct to image the NAND. The procedures below are specific enough that the diagnostic path for one family cannot be reused on the other.

Phison PS5012-E12, PS5016-E16, and PS5018-E18: Safe Mode Entry and Virtual Translator

A Phison E-series NVMe controller in firmware panic state will not enumerate on the PCIe bus, or will enumerate with a generic ROM-mode descriptor and zero capacity. To recover, the technician must force the controller into a Safe Mode that bypasses the normal boot sequence, then use PC-3000 to load an alternative loader and rebuild the translator from surviving NAND metadata.

1. Safe Mode entry by test-pad short. Phison E-series controllers expose a Safe Mode test pad on the drive PCB. Briefly shorting the pad to ground at the moment of power-on prevents the controller from executing its on-die boot ROM normally; instead it enters a minimal diagnostic state that accepts vendor commands over PCIe. The exact pad position and short technique varies by drive model, which is why the family-level Phison PS5000-series controller reference lists confirmed pad maps per drive.
2. PC-3000 Phison NVMe Active Utility. With the controller in Safe Mode, PC-3000 loads the Phison NVMe Active Utility and pushes a known-good loader into the controller's internal RAM over the vendor command channel. The loader bypasses the corrupted FTL service code and exposes the raw NAND command interface to the host.
3. Virtual translator reconstruction in host RAM. The Phison utility scans surviving FTL journal pages and translation map fragments scattered across NAND, then builds a virtual translator inside the PC-3000 host workstation's RAM rather than writing it back to the drive. Host-RAM reconstruction is non-destructive: if the rebuild produces a wrong map, the technician restarts without ever touching the original NAND. The drive's logical block addresses are then served to the imager through this virtual translator.
4. Sector imaging through controller ECC. The imager reads through the original controller's hardware LDPC and AES-256 decryption engines, so the bytes that land in the destination image are already plaintext and error-corrected. Bad pages are tracked in a defect map for later forensic reconstruction.

Drive-specific notes: PS5012-E12 (Gen3 x4) · PS5016-E16 (first Gen4 NVMe) · PS5018-E18 (Corsair MP600 Pro, Kingston KC3000, Sabrent Rocket 4 Plus). For the broader controller architecture and pricing context, see the Phison architecture reference.

Silicon Motion SM2262EN, SM2263XT, and SM2269XT: LDR Loader Microcode Injection

Silicon Motion NVMe controllers behave differently in fault state. Instead of a test-pad-triggered Safe Mode, they expose a vendor command interface that accepts an alternative loader microcode (known in PC-3000 documentation as the LDR loader). The LDR runs in place of the corrupted on-NAND firmware service area, giving the technician direct access to NAND through the controller's own ECC and descrambling hardware.

1. Power-on with current limit. The drive is brought up on a bench supply with a current limit set below the level the host motherboard would tolerate. If a voltage regulator or PMIC is shorted, FLIR thermal imaging localizes the heat under the brief pulse, and board-level repair happens before any LDR work begins. A controller that boots stably is a prerequisite for the loader handshake.
2. LDR loader microcode injection through PC-3000 Silicon Motion Active Utility. PC-3000 sends vendor-specific NVMe admin commands that hand the controller a small loader image. The controller copies the loader into its internal SRAM and jumps to it, bypassing the standard firmware that would normally boot from the NAND service area. From the loader, the controller responds to a separate diagnostic command set rather than the standard NVMe protocol.
3. FTL bypass and raw page access. Under the LDR, the controller exposes raw NAND pages and the system area metadata that the standard firmware would have used to build the FTL. PC-3000 parses the surviving translation map fragments, reconstructs a virtual translator in host RAM, and feeds reads through the controller's hardware ECC and AES-256 decryption engines. This is the same plaintext-by-the-original-controller mechanism that makes the procedure viable on encrypted drives.
4. DRAM-less HMB handling on SM2263XT and SM2269XT. These controllers normally store the FTL in Host Memory Buffer borrowed from system RAM. Once HMB is wiped by a power loss, only NAND-resident metadata survives. The LDR-driven scan reconstructs the translator from those NAND fragments alone; HMB is not used during recovery imaging.

Drive-specific notes: SM2262EN (DRAM-equipped Gen3 x4) · SM2263XT (DRAM-less HMB Gen3 x4) · SM2269XT (DRAM-less HMB Gen4 x4). For broader controller-family context, see the Silicon Motion architecture reference.

Both workflows fall in the firmware-recovery bracket ($900–$1,200) when the controller is electrically healthy and only the firmware service area or FTL is corrupted. If the controller has board-level damage, the circuit-board-repair bracket ($600–$900) is done first to bring the controller online, then the firmware workflow runs on top of the repaired board. The full toolkit is documented at the SSD data recovery flagship.

Deleted file recovery on a functioning NVMe drive is not viable once garbage collection runs. NVMe implements the Deallocate command, the NVMe equivalent of SATA TRIM. On most NVMe implementations, garbage collection begins within seconds of file deletion; once the controller erases those NAND cells, the data is physically gone.

When you delete a file, the operating system sends a Deallocate command to the controller, which marks those NAND blocks for garbage collection.

NVMe's Deallocate is more aggressive than SATA TRIM on most controller implementations. The combination of higher throughput and deeper I/O queues means the controller processes Deallocate commands faster, shrinking the forensic window for deleted data to near-zero on a functioning drive.

NVMe board-level repair restores the original controller when its voltage regulator, PMIC, or passive components fail. Because most NVMe controllers implement hardware AES-256 encryption, the original controller must be repaired; swapping a replacement controller loses the encryption keys and makes the data permanently unrecoverable. Board-level microsoldering repairs the surrounding power delivery circuit and brings the original controller back online.

We use Hakko FM-2032 microsoldering irons for passives and fine-pitch work, Atten 862 hot air stations for VRM and small-BGA reflow, and Zhuo Mao BGA rework stations for controller reballing.

1. Failed voltage regulators, capacitors, and resistors on NVMe drive PCBs are replaced at the iron or hot air station as appropriate.
2. For BGA controller packages with cracked solder joints (common after thermal cycling), we reball the BGA connections to restore electrical contact between the controller die and the PCB traces.

This is the same board-level repair capability that sets our Mac data recovery and logic board repair apart. Other recovery labs outsource board repair or skip it entirely, declaring the drive unrecoverable. We do the repair in-house.

Board repair is one technique in our SSD recovery toolkit. Firmware reconstruction and FTL rebuilds apply when the controller powers on but the data is logically inaccessible. Chip-off NAND extraction is the fallback when the controller cannot be revived at all.

NVMe controllers use Autonomous Power State Transition (APST) to cycle into low-power sleep states during idle periods. If the controller's firmware reports inaccurate wake-up latencies to the OS, the drive enters a deep sleep state it can't exit. The drive vanishes from BIOS; NAND data remains intact but inaccessible without hardware-level intervention through PC-3000.

NVMe Power States: PS0 Through PS4

The NVMe specification allows drive manufacturers to define up to 32 power states (PS0 through PS31). Most consumer NVMe controllers implement five: PS0 through PS4. Each state trades performance for lower power draw, with an associated entry latency & exit latency the controller reports to the host OS.

PS0 (Active)

Maximum performance. The controller runs all PCIe lanes at full link speed. Typical power draw: 3-9W for Gen4 controllers like the Phison E18 or Samsung Elpis. No transition latency.

PS1-PS2 (Idle Low Power)

Reduced clock speeds and partial lane shutdown. Power drops to 1-2W. Exit latency is under 100 microseconds. The controller remains responsive to NVMe commands without re-training the PCIe link.

PS3 (Low Power with Link Down)

The PCIe PHY powers down. The link goes inactive. Exit latency climbs to 1-5 milliseconds because the controller must re-train the PCIe link from scratch. This is where APST bugs typically trigger: if the controller reports a 5ms exit latency but needs 50ms, the host times out & marks the device as absent.

PS4 (Deepest Sleep)

Sub-milliwatt power draw. The controller shuts down all internal clocks except the wake-up logic. Exit latency can exceed 100ms on some implementations. A controller stuck in PS4 won't respond to PCIe link training requests at all; the host sees an empty M.2 slot.

APST Failure Mechanism

During initialization, the host OS reads the controller's Identify Controller data structure and builds an APST transition table from the reported entry/exit latencies for each power state. The OS schedules transitions based on idle time thresholds. The failure sequence is specific: the controller enters PS3 or PS4, the PCIe PHY link powers down, and on wake-up the controller fails to complete link training within the window the host expects.

The PCIe bus drops the device. From the user's perspective, the drive disappears after a sleep cycle or cold boot.

The NAND flash is untouched during an APST failure. No data is written or erased. The controller cannot get back online to present the data to the host.

This makes APST failures one of the better-prognosis categories for recovery; the data is physically intact and only needs the controller to wake up through a non-standard path.

NVMe Drives with Known APST Bugs

Several controller families have documented APST wake-up failures. The Linux kernel maintains a NVME_QUIRK_NO_DEEPEST_PS quirk flag that disables the deepest power state for affected devices.

• Kingston A2000 (firmware S5Z42105, SM2263EN controller): fails PCIe link training after PS3 entry on Linux & some Windows configurations
• Samsung PM951 & 970 EVO: Linux kernel hardcodes NVME_QUIRK_NO_DEEPEST_PS for these models due to persistent wake-up failures. The PM951 uses Samsung's older Polaris/UBX controller; the 970 EVO uses the Phoenix controller
• ADATA SX8200 Pro (SM2262EN controller): intermittent PS4 lock-up reported across multiple firmware revisions
• SK Hynix BC501 (proprietary controller): found in Dell & Lenovo OEM laptops, disappears after suspend/resume cycles when APST is active
• Maxio MAP1602-based drives (some Kingston NV2 variants): a Maxio MAP1602 APST bug causes disappearance after idle periods on Linux systems with aggressive APST scheduling

OS-Level APST Workarounds (Functioning Drives Only)

If the drive still works but vanishes intermittently after sleep or idle, disabling APST at the OS level prevents the controller from entering the problematic deep sleep state. These workarounds only apply to drives that currently function.

Windows Registry Fix

Navigate to HKLM\SYSTEM\CurrentControlSet\Services\stornvme\Parameters\Device. Create a new DWORD value named EnableAPST and set it to 0. Reboot. The stornvme driver will skip APST configuration during initialization.

Linux Kernel Parameter

Add nvme_core.default_ps_max_latency_us=0 to the kernel boot parameters in your bootloader config (GRUB: /etc/default/grub, append to GRUB_CMDLINE_LINUX_DEFAULT). This sets the maximum tolerable latency to zero, preventing all APST transitions. Run update-grub and reboot.

PC-3000 Recovery Path for APST-Locked Drives

When the drive is permanently stuck and OS workarounds can't apply (the drive doesn't enumerate at all), PC-3000 bypasses the APST state machine by forcing the controller into Technological Mode. This mode skips the normal boot sequence, PCIe link negotiation, and power state configuration entirely. The controller wakes into a raw diagnostic state where NAND can be imaged directly through the controller's own hardware ECC & decryption engines.

1. Connect the drive to PC-3000 Portable III via NVMe diagnostic adapter
2. Send vendor-specific Technological Mode entry command (controller family dependent)
3. Bypass APST state machine & force controller into active diagnostic state
4. Read NAND through the controller's own ECC and decryption hardware
5. Image all user data sectors to a target drive, skipping bad pages
6. Extract files & verify directory structure integrity

APST failures don't damage NAND cells, so recovery prognosis is high when the controller responds to Technological Mode commands. Board-level repair ($600–$900) applies if the controller's PMIC or voltage regulator also failed during the power state transition. For a complete overview of our capabilities across all SSD form factors & controllers, see our SSD data recovery service page.

See our recovery process on camera. Louis Rossmann documents real recoveries on YouTube with 2.49M+ subscribers watching.