Western Digital & SanDisk SSD Data Recovery

WD & SanDisk SSDs fail differently from other brands because Western Digital designs its own controllers instead of buying off-the-shelf chips from Phison or Silicon Motion. Since acquiring SanDisk in 2016, WD has moved both brands onto shared proprietary silicon & BiCS 3D NAND from its Kioxia joint venture. That vertical integration makes drives cheaper to manufacture but harder to recover when they fail.

Two categories of failure dominate our WD intake. Controller & firmware failures account for the majority: the proprietary controller enters a panic state, the drive drops off the bus, & software can't reach it. The second category is physical: solder defects on portable SanDisk Extreme models, PMIC failures from power surges, & NAND degradation from cell wear. Each requires a different recovery approach & falls into a different pricing tier.

Some WD & SanDisk SSDs, particularly portable models (SanDisk Extreme, My Passport SSD), use mandatory AES-256 hardware encryption. On those drives, the encryption key lives on the controller itself, and desoldering the NAND yields only ciphertext. Even on unencrypted NVMe models like the SN770 & SN850X, proprietary flash translation layers and LDPC error correction make raw NAND reads useless without the original controller. Removing the memory chips won't help on any WD drive. The path to your data is repairing the original controller through board-level microsoldering; see our SSD data recovery overview for how hardware encryption affects recovery across all brands.

WD SATA SSD recovery (WD Blue SA510, WD Red SA500, SanDisk Ultra 3D) ranges from $200 for a simple data copy to $1,200–$1,500 for NAND swap cases. WD NVMe recovery (SN770, SN850X, SN550, SanDisk Extreme internals) ranges from $200 to $1,200–$2,500. Free evaluation. No data, no fee.

Software tools like Disk Drill, EaseUS, PhotoRec, & R-Studio work when the SSD is physically healthy & recognized by your operating system. They handle logical problems: accidental deletion (before TRIM runs), partition corruption, or a formatted volume. That covers a narrow window of failure modes.

Software can't help when the WD controller is dead, the firmware has entered a panic state, or the drive has dropped off the SATA or PCIe bus. A drive that isn't detected in BIOS is invisible to any software running on the operating system. Software also can't help after firmware corruption locks the controller in a permanent busy (BSY) state.

On modern SSDs with TRIM enabled (the default on Windows 7+ and macOS 10.6.8+), deleted files are gone within seconds to minutes. The OS tells the controller which blocks are no longer needed, & the controller unmaps those logical addresses and schedules garbage collection to erase the underlying NAND blocks. No software & no lab can reverse that erase. Recovery is only possible if TRIM didn't execute: the drive was pulled immediately, TRIM was disabled, or the file system doesn't support TRIM.

WD's proprietary controllers use Toggle-mode NAND interfaces for bidirectional data transfer between controller & flash dies. This differs from the ONFI interface common on drives using Phison controllers or Silicon Motion recovery procedures. The interface choice matters for recovery because Toggle & ONFI use different timing protocols, pin configurations, & voltage signaling; chip-off tools calibrated for ONFI NAND can't read Toggle-mode dies correctly.

Three-Tiered LDPC Error Correction

WD shifted ECC from software to dedicated hardware blocks within the controller's ARM Cortex-R processor cores. The LDPC engine operates across three correction tiers. Tier 1 applies lightweight correction when the NAND cells are new & bit error rates are low (under 1 error per 10⁸ bits read). Tier 2 engages as cells accumulate P/E cycles & read-disturb errors, running longer decoding iterations on the same hardware. Tier 3 activates near end-of-life, with the Cortex-R cores dedicating full compute cycles to maximum-length LDPC decoding.

This tiered design masks NAND degradation from the host OS until the controller can't correct errors at Tier 3. At that point, drives don't slow down gradually; they fail abruptly as uncorrectable bit errors cascade through the FTL mapping table. For recovery, the LDPC architecture means raw NAND reads without the controller's ECC engine yield compounding uncorrected bit errors. Chip-off on a modern WD NVMe drive produces a dump full of bad pages that no external tool can reconstruct. The controller's own LDPC hardware is the only path to clean reads.

FTL Journal Vulnerability on HMB-Dependent Drives

DRAM-less WD controllers (SN550, SN570, SN580, SN770, SN5000) cache their FTL mapping table in Host Memory Buffer, borrowing 64MB or more of system RAM via PCIe DMA. The FTL map gets flushed back to NAND periodically, but a power loss during an active flush corrupts the journal. The controller boots, finds an inconsistent L2P (logical-to-physical) table, & enters a firmware panic state.

Drives with onboard DRAM (SN750, SN850X) maintain the FTL in local memory & flush it to NAND periodically. The onboard DRAM retains the table long enough for the controller to complete a write cycle in progress, though consumer WD drives lack the dedicated PLP capacitor banks found on enterprise SSDs. HMB drives have no such buffer at all. The system RAM vanishes the instant power drops, & whatever portion of the FTL hadn't been committed to NAND is gone.

Recovery approaches differ by controller family. Phison controllers & Silicon Motion controllers have dedicated PC-3000 "Active Utilities" that can rebuild FTL tables from NAND page metadata. WD's proprietary FTL has no such utility. Recovery on a WD drive with FTL corruption requires reviving the original controller through board-level repair so its own firmware can reconstruct the L2P table from journal fragments stored in the NAND system area. That's firmware-tier pricing: $900–$1,200 for NVMe, $600–$900 for SATA. See our SSD controller recovery directory for how PC-3000 support varies across controller families.

nCache is the proprietary pseudo-SLC (pSLC) caching algorithm that WD and SanDisk use to mask the slow native write speed of TLC and QLC flash. The controller allocates a pool of NAND blocks to operate in 1-bit mode, absorbs incoming host writes into that pool, then folds the data into 3-bit TLC or 4-bit QLC cells during idle time. nCache has been through multiple revisions (2.0, 3.0, and 4.0 on current BiCS5/BiCS6 drives). When the cache pointers or the folding journal are interrupted mid-flush, the FTL comes back inconsistent and the drive drops to a factory alias or disappears from the bus entirely.

Static vs Dynamic Cache Allocation

nCache 4.0 splits the pSLC pool into two zones. The static zone is provisioned outside the user-addressable LBA space and is permanently locked to 1-bit programming. On consumer WD NVMe drives, the static reservation scales with capacity (roughly 6GB static on a 500GB SN850, 12GB on a 1TB). Those blocks see far higher P/E endurance than the surrounding TLC because they only ever hold two voltage states. The dynamic zone scales inversely with how full the drive is: an empty 2TB QLC drive can expose up to 500GB of pSLC because four QLC pages collapse into one pSLC page. As the user fills the drive, the dynamic zone shrinks. Recovery cases coming from a near-full drive look different from a near-empty one because the dynamic pool was much smaller when the failure occurred, and more data was already folded into native TLC or QLC.

Folding Operations and the Performance Cliff

When a sustained write exceeds the combined static and dynamic pSLC pool, the controller has to fold pSLC blocks to TLC or QLC while still accepting new host data. Write throughput collapses from 5,000+ MB/s (pSLC) to 400–500 MB/s (native QLC). The folding operation touches the FTL on every block move, so the drive is at its most exposed during this window. Power loss mid-fold leaves physical NAND blocks containing a mix of new, up-to-date data and old data the controller intended to mark stale. The file system sees that as silent data corruption or unmountable partitions rather than a clean failure.

Sync Points and Journal Fragments

Between full metadata commits, the controller writes a delta journal of L2P changes to reserved system blocks. On a graceful shutdown, the FTL closes cleanly against the last sync point. On an unexpected power loss, the drive boots, walks back to the last sync point, and tries to replay the journal against the surviving NAND state. Consumer WD and SanDisk drives do not carry the capacitor banks found on enterprise SSDs, so nothing keeps the controller alive long enough to finish a flush. If the journal log itself was mid-write when power dropped, the controller reads corrupt delta records, flags the FTL as invalid, and halts the standard boot sequence. The drive reports a factory alias ("MN-5236" or the raw controller ID) at 0GB, 20MB, or 1GB. Host tools see a device that identifies but has no usable capacity.

Presentation at the Host

nCache corruption typically presents in one of three patterns. First, ROM-mode drop: the drive identifies with a factory descriptor and near-zero capacity as described above. Second, permanent BSY: corrupted metadata loops the controller's background maintenance routine and the drive sits on the bus in a permanent busy state, refusing any ATA or NVMe command. Third, partial mount with stale pages: the FTL loads far enough for the host to see a volume, but the rolled-back journal left a block with mixed-sequence pages. Files appear truncated, headers are garbled, or the volume is mountable read-only. The first two patterns require PC-3000 SSD to intervene at the controller level; the third often allows a direct image but the checksum layer on user files has to be verified against whatever backup or redundancy the customer has.

The WD Blue SA510 SATA SSD suffers from a firmware failure that bricks the drive permanently. The controller (SanDisk A101-000125-B0) enters a panic state & refuses to initialize, reporting 0 bytes or "Unknown Device" in BIOS. No S.M.A.R.T. data, no temperature telemetry, no response to standard ATA commands.

This isn't NAND degradation. The flash cells are intact. The controller's firmware has entered a permanent stall, & the A101-000125-B0 is a proprietary SanDisk design with no public documentation. PC-3000 SSD does not have an active utility for this controller; ACE Lab has confirmed that "native SanDisk controllers are not supported."

Recovery on the SA510 requires a different approach. If the controller has an electrical fault (shorted PMIC, failed voltage regulator), we locate it with FLIR thermal imaging & replace the component using a Hakko FM-2032. If the firmware itself is corrupt but the controller hardware is intact, we attempt to access the NAND through alternative forensic methods. Pricing for SA510 recovery falls in the firmware tier ( $600–$900) or board repair tier ( $450–$600) depending on the root cause.

Western Digital sells SSDs across four product tiers: Green (budget), Blue (mainstream), Black (enthusiast), & Red (NAS/server). Each tier uses different controller silicon, NAND grades, & caching architectures. Recovery difficulty & pricing vary per tier.

Green & Blue NVMe drives are the hardest to recover because they share the same 20-82-10023-A1 controller with no PC-3000 firmware-level support. Black drives have known firmware bugs, but the bugs are documented & PC-3000 can work around them through forced link negotiation. Red drives use Marvell silicon with full PC-3000 utility support. SATA SSD pricing: $200–$1,500. NVMe pricing: $200–$2,500.

When a SanDisk Ultra 3D or an early WD Red SA500 running the Marvell 88SS1074 controller drops into a factory alias or a permanent BSY state, the SATA command set is useless. The controller ignores host commands because its own FTL is corrupt. Standard imaging tools report "Drive not ready" or time out. The recovery path is to bypass the SATA bus entirely and talk to the controller through its UART diagnostic port, force it into a loader state, and rebuild the translator in PC-3000's workstation RAM.

UART Terminal Access on 88SS1074

The 88SS1074 is a tri-core ARM Cortex-R5 design that Marvell sold to OEMs as a sandbox: they supply the silicon and a firmware template, SanDisk and WD ship their own microcode on top. Because every OEM designs a new PCB around the silicon, the RX and TX test pads and the ground reference are in a different location on each drive model. The first step is identifying the correct pads on the PCB under stereo magnification and confirming them against ACE Lab's parameter database for the specific drive variant. Thin-gauge magnet wire is microsoldered to the pads with a Hakko FM-2032 on an FM-203 base using low-residue flux.

Voltage level matters. Older Marvell 88SS9189 and 88SS9190 controllers used 3.3V UART logic. The 88SS1074 dropped to 1.8V for its internal SRAM and terminal bus. Connecting a 3.3V terminal adapter (the one labeled "Terminal 2" on a PC-3000 kit) to a 1.8V controller damages the UART pins. The correct adapter is the Terminal 3 module, which level-shifts to 1.8V. The adapter plugs into the PC-3000 Express or Portable III workstation and the wires on the drive side land on RX/TX/GND. The terminal log should print readable ASCII boot chatter once power is applied; garbled characters usually mean the baud rate parameter is wrong or the voltage level is mismatched.

Safe Mode via VSC Injection

With the terminal connected, PC-3000's Marvell utility injects a sequence of Vendor-Specific Commands that halt the drive's standard boot right before the FTL load stage. The controller stops trying to mount the corrupted translator from NAND and parks in a minimal state where its SRAM is writable from the host side. A custom volatile microcode loader is uploaded directly into the 88SS1074's SRAM, temporarily replacing the corrupted firmware. The loader gives PC-3000 raw read access to the NAND through the controller's hardware abstraction layer without ever invoking the broken FTL. Because the microcode is volatile, cutting power restores the drive to its original panicked state, so the entire imaging session has to complete in one continuous power cycle.

Thermal manipulation is often part of this stage. Degraded NAND cells shift their threshold voltages with temperature, and read stability on a dying 88SS1074 drive can swing by hundreds of millivolts between ambient and 40–50°C. We apply targeted heat from an Atten 862 hot-air station at low flow, or chill the controller with freeze spray, to find the thermal band where the SRAM loader can maintain clean reads long enough to finish the dump.

Translator Rebuild: Journal Replay vs Full NAND Scan

With raw NAND access established, the FTL has to be reconstructed as a virtual translator in workstation RAM. PC-3000 picks one of two workflows depending on what survived in the service area.

Journal Replay is the preferred path. The utility reads the service area blocks (hidden from the host, holding the factory defect list, the firmware modules, and the FTL delta journals), extracts the surviving journals, and replays them in workstation RAM. Each journal entry is a delta record: a small ledger of L2P changes since the last full commit. Replayed in order, they reconstruct the L2P table state right up to the moment of failure. For the 88SS1074, this has to be compiled per STAR (Marvell's internal name for each memory bank and channel grouping); a drive with eight NAND dies across two channels might have four STARs that all need independent journals walked. Journal Replay typically produces a complete file system tree with intact directory structure and is the faster path.

Full NAND Scan is the fallback when the service area journals were overwritten during a panicked folding event or physically damaged. Every NAND page carries an out-of-band (OOB) spare area of 64 to 128 bytes that the controller populates on write. The spare area holds the page's LBA tag, a block sequence number, and wear-leveling counter. PC-3000 reads the spare area across every physical page on every die (tens of millions of pages on a 1TB drive), parses the hex, and builds a global list of every LBA tag and which physical page claims it. Because SSDs do out-of-place writes, the same LBA often appears on dozens of different physical pages (old copies that were never garbage collected). The utility compares block sequence numbers, discards the stale copies, and pins each LBA to the physical page with the highest sequence number. The Marvell controller also XOR-scrambles and interleaves data across channels for throughput, so the utility applies the correct descrambling map from ACE Lab's parameter database before the data is usable.

Once the virtual translator is built, PC-3000's Data Extractor maps logical files onto physical pages and writes the image to a destination drive. That image is what we hand off to the file system layer for repair. Firmware-tier recovery on SanDisk Ultra 3D and early WD Red SA500 drives runs at $600–$900. For cases where the controller is electrically dead before any of this workflow can start, circuit board repair ($450–$600 SATA / $600–$900 NVMe) has to come first.

Why the 20-82 Series Cannot Run This Workflow

Nothing in the above workflow works on the proprietary 20-82 series (SN550, SN570, SN770, SN850X, SN5000, and the A101-000125-B0 inside the SA510). ACE Lab has not released an Active Utility for WD's post-acquisition in-house silicon, and the VSC command space is undocumented. The public technical consensus is that WD has shifted recent controllers to cryptographically signed diagnostic payloads, which defeats the static VSC sequences that work on older Marvell parts. The always-on AES-256 encryption built into the 20-82 die binds the key to the silicon, so desoldering the NAND and reading it in a programmer returns ciphertext. Recovery on these drives collapses back to board repair: revive the original controller electrically (PMIC replacement, PCIe PHY reflow, BGA rework with a Zhuo Mao station), let the drive's own firmware walk its own journals in-place on the NAND, and image through the natively-rebuilt FTL before the controller overheats or the fragile state destabilizes again.

The WD Red SA500, marketed for 24/7 NAS environments, has documented interoperability failures with ZFS file systems & LSI SAS host bus adapters. Initiating a standard zpool trim command on a pool backed by SA500 drives causes the drives to disconnect from the SATA/SAS bus within minutes.

Behind LSI 9300-8i SAS3 controllers (common in TrueNAS & enterprise servers), the SA500's firmware fails to handle TRIM commands through the SAS-to-SATA translation layer. The drive enters a busy (BSY) state & drops off the bus, degrading the ZFS pool. Sustained read operations during recovery imaging can trigger the same BSY timeout.

For NAS arrays with failed SA500 drives, recovery requires careful handling of the TRIM interaction. PC-3000 SSD's Marvell utility (the early SA500 uses an 88SS1074 controller) bypasses the normal SATA command set & reads the NAND through technological mode, avoiding the TRIM/BSY trigger. The imaged data is then assembled against the ZFS pool structure. If you're running SA500 drives in a ZFS pool, disable TRIM on that pool as a precaution.