SSD Shows Up as RAW?
Do Not Format It

RAW is what Windows calls a partition it can see but cannot read. The partition table points Windows at a volume, Windows jumps to the start of that volume, and the boot sector or the file table it expects is damaged or unrecognizable.

It cannot tell whether it is looking at NTFS, FAT32, or exFAT, so it labels the file system RAW and offers to format the drive. The prompt is a symptom, not a diagnosis.

Two very different things produce that same label. On NTFS the volume boot record or the $MFT that indexes every file can be corrupt while the file data behind it sits untouched. Or the drive holds a file system Windows cannot read, such as macOS APFS, Linux ext4, or ZFS, which Windows treats as an absence of a file system rather than a foreign one.

Either way the files are usually still there. The job is to read them without letting a single write land on the drive first.

Start with CHKDSK, because the advice to run it is everywhere. On a volume Windows has already declared RAW, CHKDSK prints "The type of the file system is RAW. CHKDSK is not available for RAW drives" and stops. It does nothing.

Where CHKDSK does real harm is the in-between case, where the file system is damaged enough to throw errors but Windows still mounts it: a full CHKDSK pass reads the volume and writes corrections back, and forcing a struggling controller or degrading NAND through that write load pushes marginal blocks past the point where the controller's error correction can recover them.

Format-then-recover is worse, and it is the exact sequence the affiliate blogs push. Here is the part they leave out.

Writes and deletions on an SSD give the host operating system reason to issue TRIM, the deallocate command that tells the controller which logical blocks are no longer referenced. The operating system issues TRIM; the controller only executes it, unmapping those blocks from the flash translation layer so that reads of them return zeros, and background garbage collection then erases the physical cells.

TRIM is on by default on Windows 7 and later; on macOS it is on by default only for Apple-supplied SSDs, and third-party drives need it turned on with trimforce. The practical result on Windows is that formatting a drive you are trying to recover hands the OS a reason to unmap the very blocks that hold your files.

This is the difference between an SSD and a spinning drive. On a mechanical drive a cancelled format or a stray write is often survivable, because deleted content lingers until it is physically overwritten. On an SSD the unmap happens at the logical layer and garbage collection finishes the job on its own schedule.

Once the controller unmaps a block, it stops handing that block's data back, and no software reaches around the controller to get it. Stop writing, power the drive down, and get it evaluated.

The format-then-recover crowd has the order backwards. They tell you to format the drive to clear the RAW state, then point recovery software at it, which means the recovery runs against a drive that was already written to and may be actively unmapping blocks. Every attempt happens on the one copy you cannot afford to lose, and every failed attempt is a fresh set of writes to the original.

A read-only image inverts that risk. We read every accessible logical sector of the SSD off to a destination drive in the lab and work from that image afterward. Boot-sector rebuilds, $MFT reconstruction, and file carving all run against the copy.

The RAW drive is read once and then set aside untouched, so nothing we do downstream can make the original worse. That is the whole reason a lab recovers RAW volumes that consumer software destroyed: the software wrote to the drive, and we do not.

The fact that splits them is what the drive reports about itself. Open Disk Management and Device Manager and read the capacity and model name before touching anything else.

The SATAFIRM S11 string is worth calling out because it is specific. That identity is hardcoded only into the Phison PS3111-S11 SATA controller; a failing Silicon Motion drive instead sits in a busy hang or reports a raw silicon descriptor, and a Marvell drive locks the bus or reports 0GB with no model string.

If your drive shows that exact string, the SATAFIRM S11 firmware fix page covers the controller-specific recovery. Firmware recovery runs $600–$900 for SATA and $900–$1,200 for NVMe.

A healthy SSD pulled from a Mac or a Linux box will often show up as RAW the instant you connect it to a Windows PC. Nothing is wrong with the drive. Windows cannot parse macOS APFS or HFS+, Linux ext4, or ZFS, so it treats a file system it does not understand as no file system rather than a foreign one, and offers to format the drive.

Software affiliates miss this because their tools assume every connected drive is a native Windows disk they can push NTFS or exFAT repair at. That assumption turns a five-minute non-problem into a data-loss event. Format a Mac SSD from Windows and you overwrite the start of the APFS container; let a partition tool write a new NTFS layout and the original ext4 or ZFS structures are gone.

The safe check is simple. Read the drive back on the operating system that wrote it: a Mac SSD belongs on a Mac, a ZFS pool member belongs on the system that built the pool. If the original machine is dead and the drive holds the only copy, treat it as a logical recovery and send it in rather than forcing Windows to write to it.

If the SSD holds data you need, secure the hardware before you touch the software. These steps keep the drive in the state a lab can work with.

1. Cancel the format prompt. Do not format, do not initialize, and do not let a partition tool write a new layout. Each of those writes to the start of the volume.
2. Do not run CHKDSK. On a RAW volume it refuses to run anyway; on a partly damaged one it writes corrections you do not want on a failing drive.
3. Read the capacity and model name. A correct size and real model name points to a logical file-system problem; 0 bytes, a placeholder capacity, or a wrong string points to a firmware panic.
4. Do not point recovery software at the original. No repair tools, no format-then-scan, no firmware updates. Any recovery attempt belongs on a read-only image, never on the drive itself.
5. Power down and get an evaluation. Leave the drive off and send it for a free evaluation. We tell you which failure it is and quote before any work begins.

Recovery starts by reading what the drive reports and deciding which of the two failures it has, because the paths share almost nothing. A logical RAW recovery is software work over a healthy controller, done against a read-only image; a firmware recovery is hardware work on the controller itself. Both happen in-house at our Austin lab.

The tool that reaches a panicked controller is PC-3000 SSD, which talks to a live controller over the SATA or NVMe interface. It does not read desoldered NAND chips; that is a separate hardware path.

For a healthy drive with a RAW file system, none of the firmware work is needed, which is why reading the capacity first keeps the logical cases in the lower price tier. For an NVMe drive that never shows up in BIOS, see NVMe SSD not detected in BIOS and our NVMe recovery page.

Rush service adds +$100 rush fee to move to the front of the queue. If a firmware panic requires a matching donor for its board, 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. Every quote is firm before work starts, with no data, no charge and no diagnostic fee. Full ranges live on our pricing page.

When the RAW prompt turns out to be a controller firmware panic rather than a file-system problem, this is the kind of hardware-level work it takes. The video walks through NVMe SSD diagnosis and firmware recovery in our lab.

NVMe SSD data recovery: what a controller firmware failure looks like at the hardware level.