I have two SSDs in my PC: an NVMe drive containing Windows and a SATA SSD used mostly for games and storage. Recently, the computer froze, went black, and began restarting repeatedly. Since then, I have seen filesystem corruption reported by CHKDSK, occasional BSODs involving memory and registry errors such as 0x51, and behavior suggesting that changes made during a session are not always being saved after a crash. Windows also sometimes gets stuck during startup.
I initially suspected the SATA SSD because I cannot reliably format it, delete its partitions, or perform partition operations using Windows installation media, DiskPart, Disk Management, MiniTool, or EaseUS. However, I later realized the title was incorrect: the drive most likely failing is the NVMe system drive. The SATA SSD is from a lesser-known brand purchased several years ago, while CrystalDiskInfo reports about 92% health and no major SMART warning.
Could an SSD or its controller be failing even when SMART still reports 92% health? What tests should I perform to determine whether the NVMe drive, the SATA drive, the connection, memory, or another component is responsible before replacing hardware?
2 Answers
A SMART percentage is not a guarantee that the drive is healthy. It is based on the attributes the firmware chooses to expose, and a drive can still have controller, NAND, cable, power, or communication problems without triggering a serious SMART warning. First back up or image anything important and avoid repeatedly formatting or writing to the suspect drive.
To isolate the problem, test with only the NVMe drive installed, then only the SATA drive connected. Reseat the NVMe module and check its screw and slot; for the SATA drive, replace both the data cable and power connector and try another motherboard port. If partition operations fail consistently on one drive even from a separate boot environment, replacement is safer than trusting it with data.
The BSODs should be investigated separately rather than assuming the SATA SSD is responsible. Disable automatic restart so the stop code stays visible, and check C:WindowsMinidump for crash dumps after the next failure. Those dumps can identify whether the crashes point to storage, a driver, memory, or the kernel.
Run a proper memory test as well, preferably with each RAM module tested individually. Also check Windows Event Viewer for disk, storahci, nvme, and WHEA errors. If the crashes continue with the suspect drives disconnected and a known-good boot drive installed, the issue is more likely RAM, the motherboard, power delivery, or a driver.
If the SATA drive is only being used for games and has no important files, disconnect it while diagnosing the NVMe drive. That prevents a failing secondary disk from complicating the boot and crash tests.
The fact that Windows changes seem to disappear after a crash can also happen when the system drive is failing to commit writes, but it is not proof by itself. Check whether the same behavior occurs when booting from a known-good temporary installation or another drive.