What may cause very high CRC errors on SSD (Apart from bad SATA cables, if any)

crcsatasmartssd

My SATA SSD, in a span of about 2 years has developed over 37K CRC errors. These have not linearly increased. There have been just 3 -4 instances where Windows hung and later after inspecting SMART parameters I found a substantial increase in the CRC error Count. The increase has been sudden in amounts to 7 – 8K at a time. SSD otherwise operates normally.

I am wondering what the reason for such a behavior could be. I have good quality SATA cables and they are not excessively bent or twisted in the cabinet.

Moreover the issue seems to be self-limiting. Without touching anything (No need to re-seat SATA cable or so) it recovers on its own and then works just fine for another few months before showing such a sporadic behavior.

That makes me wonder if there's something on the SSD itself that might be causing this?

I have another HDD connected to the same SATA controller, it has never shown such a behavior so far.

System Configuration –
Motherboard 880GM USB3, SATA II, AMD SB710 Chipset, Windows 7 64, 8GB RAM, Samsung EVO 850 120GB SSD, Seagate Barracuda 2.5 HDD.

enter image description here

Best Answer

I had the same issue but found the root of the problem. It has nothing to do with bad cable/RAM/CPU. It's because of incompatibility between your Samsung SSD and your AMD chipset's SATA controller. The best solution to prevent occasional stuttering and increasing CRC errors is to disable NCQ (Native Command Queue) in your SATA driver

  1. If you use the default storahci MS driver add to the registry [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\storahci\Parameters\Device] "NcqDisabled"=dword:00000001 or "SingleIO"=hex(7):2a,00,00,00,00,00

  2. If you use the AMD SATA driver add this instead: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\amd_sata\Parameters\Device] "AmdSataNCQDisabled"=dword:0000000F or "AmdSataQueueDepth"=dword:00000001

Another solution is to switch your SATA controller to IDE mode but it results in slower performance than the above workarounds.