WD My Passport NVMe data recovery - case study of an unstable external SSD

The device contained a large archive of project and private data. It was not a clean "deleted files" case. The external SSD was detected irregularly, then vanished, and longer read attempts caused the workstation to hang. In that state, every unnecessary power cycle, benchmark or recovery-software scan can reduce the time in which the controller still answers predictably.

Symptoms reported by the client

• the WD My Passport NVMe appeared and disappeared from the operating system,
• directory access froze or slowed down without warning,
• read speed dropped sharply during attempts to copy larger folders,
• the client had tried short access checks, but had not formatted, initialised or run destructive repair tools.

That last detail mattered. In many SSD/NVMe cases, the best decision is not another test. It is to stop while the device still gives short windows of access and prepare a controlled recovery plan.

Why this case was high risk

External NVMe SSDs can fail in a way that feels random to the user: sometimes they mount, sometimes they disappear, sometimes the computer freezes before any file list appears. The cause may sit in the USB bridge, firmware, controller behaviour, NAND state, overheating or power stability. Unlike an HDD, there may be no noise that warns the owner to stop.

Long scans are especially risky here. They spend the limited stable window on reading everything, including low-value areas, while the controller heats up and error handling gets worse. For a client who needs project folders, accounting exports, photos or design files, a priority-driven read strategy is safer than a heroic full sweep.

Laboratory procedure used

The first step was to document the symptoms and avoid any operation that would write to the SSD. We checked whether the issue looked like enclosure/bridge instability or internal NVMe behaviour, then selected a read strategy that limited stress and focused on the most important data areas first.

• no formatting, initialisation or firmware updates were attempted,
• the work was split into controlled read sessions instead of one long scan,
• priority folders were identified before low-value data was attempted,
• the case was treated as an SSD/NVMe data recovery problem, not a standard USB copy job.

Result and practical lesson

The useful part of the result came from early restraint and a staged plan. The client did not keep reconnecting the SSD for hours, did not accept system repair prompts and did not try to update vendor tools "just in case". That preserved options for a controlled lab read.

The lesson is simple: if an external SSD works once and then disappears again, treat it as a warning, not an invitation to test harder. If the data is important, prepare the model name, capacity, last successful access, error messages and the list of priority folders before the next power-on.

Safe first step for a similar case

Disconnect the SSD, do not initialise it in Disk Management, and do not run drive repair tools. If the device contains company or client data, decide which folders matter most before diagnosis. That helps the lab choose a realistic order of work.

For more context, see what to do when an SSD is not detected, how TRIM affects deleted files, and what may happen in an SSD/NVMe brick scenario.