Bad sectors in SSD after fresh install

[Grit]

I just reinstalled Windows 7 (no other OS's) on my Crucial C300 256GB SSD. Its the only SSD/HDD storage in the system. After getting intermittent pauses, I ran a chkdsk and found
116KB in bad sectors. If this was a HDD, I'd replace it, since that's usually a precursor to the drive failing. I have NO idea what, if anything, that means for SSDs. Also, I ran the chkdsk with "fix errors"... so what happened to the data in the bad sectors? Do I need to reinstall?

Here's the chkdsk log, in case that helps.
----------------------------------------


Checking file system on C:
The type of the file system is NTFS.
Volume label is Windows 7 Pro.

A disk check has been scheduled.
Windows will now check the disk.

CHKDSK is verifying files (stage 1 of 5)...
554752 file records processed. File verification completed.
373 large file records processed. 0 bad file records processed. 2 EA records processed. 44 reparse records processed. CHKDSK is verifying indexes (stage 2 of 5)...
612764 index entries processed. Index verification completed.
0 unindexed files scanned. 0 unindexed files recovered. CHKDSK is verifying security descriptors (stage 3 of 5)...
554752 file SDs/SIDs processed. Cleaning up 454 unused index entries from index $SII of file 0x9.
Cleaning up 454 unused index entries from index $SDH of file 0x9.
Cleaning up 454 unused security descriptors.
Security descriptor verification completed.
29007 data files processed. CHKDSK is verifying Usn Journal...
33568792 USN bytes processed. Usn Journal verification completed.
CHKDSK is verifying file data (stage 4 of 5)...
Read failure with status 0xc00000b5 at offset 0x5bfb54000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x5bfb56000 for 0x1000 bytes.
Windows replaced bad clusters in file 41
of name \Windows\Prefetch\AgRobust.db.
Read failure with status 0xc00000b5 at offset 0xd111000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0xd11c000 for 0x1000 bytes.
Windows replaced bad clusters in file 17531
of name \Windows\winsxs\amd64_microsoft-windows-f..crosoftjhengheibold_31bf3856ad364e35_6.1.7600.16385_none_baa58b03c657ca8d\msjhbd.ttf.
Read failure with status 0xc00000b5 at offset 0x34f1e000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x34f2c000 for 0x1000 bytes.
Windows replaced bad clusters in file 44542
of name \MSOCache\ALLUSE~1\{90140~2\PptLR.cab.
Read failure with status 0xc00000b5 at offset 0x20557f2000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x20557fd000 for 0x1000 bytes.
Windows replaced bad clusters in file 60629
of name \PROGRA~1\MICROS~1\Office14\OART.DLL.
Read failure with status 0xc00000b5 at offset 0x1f556e6000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x1f556e6000 for 0x1000 bytes.
Windows replaced bad clusters in file 65493
of name \PROGRA~2\ORIGIN~1\BATTLE~1\Data\cas_03.cas.
Read failure with status 0xc00000b5 at offset 0x20a8753000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x20a8762000 for 0x1000 bytes.
Windows replaced bad clusters in file 75265
of name \PROGRA~2\Steam\STEAMA~1\common\ORCSMU~1\data\scenes\Stream\LIGHTM~2.PAK.
Read failure with status 0xc00000b5 at offset 0x1f816a5000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x1f816a9000 for 0x1000 bytes.
Windows replaced bad clusters in file 89898
of name \MSOCache\ALLUSE~1\{90140~4\OutlkLR.cab.
Read failure with status 0xc00000b5 at offset 0x1f8402a000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x1f84039000 for 0x1000 bytes.
Read failure with status 0xc00000b5 at offset 0x1f8446a000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x1f84470000 for 0x1000 bytes.
Read failure with status 0xc00000b5 at offset 0x1f847a1000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x1f847ae000 for 0x1000 bytes.
Windows replaced bad clusters in file 90753
of name \MSOCache\ALLUSE~1\{92787~1\Proof.en\Proof.cab.
Read failure with status 0xc00000b5 at offset 0x1e49050000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x1e4905b000 for 0x1000 bytes.
Windows replaced bad clusters in file 91593
of name \MSOCache\ALLUSE~1\{92787~1\Proof.fr\Proof.cab.
Read failure with status 0xc00000b5 at offset 0x534e5000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x534e9000 for 0x1000 bytes.
Windows replaced bad clusters in file 91900
of name \MSOCache\ALLUSE~1\{92572~1\OnoteLR.cab.
Read failure with status 0xc00000b5 at offset 0x1f386a4000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x1f386aa000 for 0x1000 bytes.
Windows replaced bad clusters in file 91921
of name \PROGRA~1\COMMON~1\MICROS~1\TRANSLAT\ENES\MSB1ENES.ITS.
Read failure with status 0xc00000b5 at offset 0x1dd9ba3000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x1dd9bb2000 for 0x1000 bytes.
Windows replaced bad clusters in file 91990
of name \PROGRA~1\MICROS~1\Office14\PROOF\MSGR3EN.LEX.
Read failure with status 0xc00000b5 at offset 0x1fd0270000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x1fd0276000 for 0x1000 bytes.
Read failure with status 0xc00000b5 at offset 0x1fd0407000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x1fd0413000 for 0x1000 bytes.
Windows replaced bad clusters in file 92022
of name \MSOCache\ALLUSE~1\{9AFC7~1\Access.en-us\AccLR.cab.
Read failure with status 0xc00000b5 at offset 0x1e626b8000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x1e626ba000 for 0x1000 bytes.
Windows replaced bad clusters in file 92036
of name \PROGRA~1\MICROS~1\TEMPLA~1\1033\ONENOTE\14\STATIO~1\BLANK.ONE.
Read failure with status 0xc00000b5 at offset 0x1fe4588000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x1fe4589000 for 0x1000 bytes.
Windows replaced bad clusters in file 92070
of name \MSOCache\ALLUSE~1\{9877A~1\PubLR.cab.
Read failure with status 0xc00000b5 at offset 0x1fe5147000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x1fe514e000 for 0x1000 bytes.
Windows replaced bad clusters in file 92104
of name \PROGRA~1\MICROS~1\TEMPLA~1\1033\Access\NORTHW~1.ACC.
Read failure with status 0xc00000b5 at offset 0x1fe5f17000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x1fe5f23000 for 0x1000 bytes.
Read failure with status 0xc00000b5 at offset 0x1fe6094000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x1fe60a0000 for 0x1000 bytes.
Windows replaced bad clusters in file 92142
of name \PROGRA~1\MICROS~1\Office14\1033\MSACCE~1.HXS.
Read failure with status 0xc00000b5 at offset 0x1fe63a7000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x1fe63ac000 for 0x1000 bytes.
Windows replaced bad clusters in file 92147
of name \PROGRA~1\MICROS~1\Office14\1033\MSACCESS.HXS.
Read failure with status 0xc00000b5 at offset 0x1fe7188000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x1fe7195000 for 0x1000 bytes.
Windows replaced bad clusters in file 92166
of name \PROGRA~2\COMMON~1\MICROS~1\OFFICE14\1033\MSOINT~2.IDX.
Read failure with status 0xc00000b5 at offset 0x75026f000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x750271000 for 0x1000 bytes.
Windows replaced bad clusters in file 92211
of name \MSOCache\ALLUSE~1\{94297~1\SIWW.cab.
Read failure with status 0xc00000b5 at offset 0x74b11f000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x74b121000 for 0x1000 bytes.
Windows replaced bad clusters in file 92663
of name \PROGRA~1\MICROS~1\TEMPLA~1\1033\BLACKT~2.DOT.
Read failure with status 0xc00000b5 at offset 0x65a21000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x65a26000 for 0x1000 bytes.
Windows replaced bad clusters in file 95082
of name \Windows\winsxs\X86_MI~2.405\msvcr80.dll.
Read failure with status 0xc00000b5 at offset 0x20279cd000 for 0x10000 bytes.
Read failure with status 0xc00000b5 at offset 0x20279d4000 for 0x1000 bytes.
Windows replaced bad clusters in file 95376
of name \PROGRA~2\MICROS~2\AS OLEDB\10\MSMDLO~1.DLL.
554736 files processed. File data verification completed.
CHKDSK is verifying free space (stage 5 of 5)...
31238847 free clusters processed. Free space verification is complete.
Adding 29 bad clusters to the Bad Clusters File.
Correcting errors in the Volume Bitmap.
Windows has made corrections to the file system.

249954303 KB total disk space.
124243364 KB in 173381 files.
93096 KB in 29008 indexes.
116 KB in bad sectors.
662343 KB in use by the system.
65536 KB occupied by the log file.
124955384 KB available on disk.

4096 bytes in each allocation unit.
62488575 total allocation units on disk.
31238846 allocation units available on disk.

Internal Info:
00 77 08 00 a0 16 03 00 2e d1 05 00 00 00 00 00 .w..............
8f 01 00 00 2c 00 00 00 00 00 00 00 00 00 00 00 ....,...........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

Windows has finished checking your disk.
Please wait while your computer restarts.

 

[Grit]

Someone asked for the CrystalDiskInfo SMART screen, so here it is... everything looks maxed out. If the drive is bad, is this a warranty issue?

https://picasaweb.google.com/lh/photo/1TusFWiMNy6upkIstabW19VeaRASZlFQPe1qMxMs2X0?feat=directlink

BTW, I have NO idea how to post a photo... is there an easier way?

 

[Burner27]

I would suggest you update the FW to the latest version (in your case it's 0007), do a secure erase on the drive and then reinstall Windows. Let us know if you still encounter errors.

 

[Coup27]

I would suggest you update the FW to the latest version (in your case it's 0007), do a secure erase on the drive and then reinstall Windows. Let us know if you still encounter errors.

+1.

 

[mikeymikec]

I saw a similar thing happen once with an IDE drive, it turned out to be a dodgy controller driver.

 

[Burner27]

Might also try changing the SATA cable as well. What motherboard are you using?

 

[mrpiggy]

If you can do without it for a while, it's probably simpler and better to simply get it RMA'd. Why goof around with a possibly bad drive. Even if you manage to flash it so it's up and running right again, who's to say it won't happen again. Better to just RMA it. Crucial has a decent rep for taking care of their customers so it shouldn't be that big a hassle.

 

[Grit]

Its a new Asus P8Z77V-Deluxe, and I'm using their white & black SATA cables (as directed) on the Intel SATA III controller.

I've had a bad cable problem too... didn't think of that. I'll try switching it out.

 

[Shmee]

I would at least contact crucial support and see what they think.

 

[Burner27]

Its a new Asus P8Z77V-Deluxe, and I'm using their white & black SATA cables (as directed) on the Intel SATA III controller.

I've had a bad cable problem too... didn't think of that. I'll try switching it out.

Your board sheds some light on the issue as well. If you say you are on the SATAIII controller, I hope you mean the Intel ones and not the third-party ones. In that case, go into your BIOS and change the SATA port to 'Hot-Swap' for your SSD. I think it's under the Advanced Tab.

 

[Burner27]

If you can do without it for a while, it's probably simpler and better to simply get it RMA'd. Why goof around with a possibly bad drive. Even if you manage to flash it so it's up and running right again, who's to say it won't happen again. Better to just RMA it. Crucial has a decent rep for taking care of their customers so it shouldn't be that big a hassle.

But how do you know it's the drive that is causing this issue? All avenues should be investigated first to determine that it is indeed the drive causing the issue. I am not saying your theory isn't valid, but the OP should exhaust all other possibilities before saying it is the drive. Crucial will ask him if he has done certain troubleshooting first as well before issuing an RMA.

 

[Coup27]

But how do you know it's the drive that is causing this issue? All avenues should be investigated first to determine that it is indeed the drive causing the issue. I am not saying your theory isn't valid, but the OP should exhaust all other possibilities before saying it is the drive. Crucial will ask him if he has done certain troubleshooting first as well before issuing an RMA.

I agree with this. It doesn't take very long, maybe a few hours to do some of your own diagnosis and more often than not it turns out not to be the device.

 

[mrpiggy]

But how do you know it's the drive that is causing this issue? All avenues should be investigated first to determine that it is indeed the drive causing the issue. I am not saying your theory isn't valid, but the OP should exhaust all other possibilities before saying it is the drive. Crucial will ask him if he has done certain troubleshooting first as well before issuing an RMA.

Since the user stated it was a "reinstall" the assumption was that everything was working fine and the only change was a new OS.

 

[Mark R]

If you can do without it for a while, it's probably simpler and better to simply get it RMA'd. Why goof around with a possibly bad drive. Even if you manage to flash it so it's up and running right again, who's to say it won't happen again. Better to just RMA it. Crucial has a decent rep for taking care of their customers so it shouldn't be that big a hassle.

Well, it may well not be the drive in this case. The SMART diagnostics are all perfect - no bad sectors, no errors pending analysis, nothing. If the drive had genuinely reported bad sectors to CHKDSK, then at least one of those records should be abnormal. This is pretty strong (albeit not conclusive) evidence that this isn't a drive problem.

For this reason, I'd recommend first checking with another SATA cable and/or motherboard - as this wouldn't be the first time that a bad cable, or flaky motherboard, has resulted in "false" bad-sectors.

 

[Bitaddict]

What about the Windows installation disk itself? Original or burned? Custom?

 

[Rubycon]

Well, it may well not be the drive in this case. The SMART diagnostics are all perfect - no bad sectors, no errors pending analysis, nothing. If the drive had genuinely reported bad sectors to CHKDSK, then at least one of those records should be abnormal. This is pretty strong (albeit not conclusive) evidence that this isn't a drive problem.

For this reason, I'd recommend first checking with another SATA cable and/or motherboard - as this wouldn't be the first time that a bad cable, or flaky motherboard, has resulted in "false" bad-sectors.

I don't believe CHKDSK is "smart" enough (sorry for the pun!) to deal with anomalies that occur with SSDs. Conventional magnetic disks can produce a "signature" of sorts that CHKDSK will mark the sector as bad so data is not stored there. This would be a false positive with a SSD. Clearing the drive would fix that. If SMART says otherwise that's what should be believed as correct.

So the issue is what caused it in the first place? Cabling would be the first suspect. Also make sure none of the controllers are running on overclocked buses, etc.

 

[Grit]

Nothing is overclocked on the system and it never has been.

I previously had the drive connected to a board made before Intel made SATA III controllers, so it ran for a year on a 3rd party controller. I did not wipe any data before I installed fresh when I connected it to my new motherboard. It is now connected to the Intel SATA III controller w/the proper, updated drivers.

I have all SATA ports on AHCI and hot swap to off (I read hot-swapping caused some disconnect issues with SATA drives..?).

I did switch and use the new SATA cables that came with the motherboard.

I had NO indication there was any data corruption (except an occasional, intermittent pause, which I only theorize may have been caused by the data corruption) until I ran CHKDSK.

Finally, I did update to the latest firmware. Though I'm not able to do any stress tests until the weekend, everything SEEMS to be running smoothly. So perhaps firmware/corrupted data caused the problem. Curious how the data GOT corrupted in the first place now, especially since I had no direct indication.

 

[tweakboy]

How can nand flash get bad sectors,, Interesting ,, listen to the gurus and RMA it, not worth it one day its pooof gone and your not feeling to well ya know... gl

 

[mikeymikec]

Apologies if someone has already suggested this, but do you have a spare machine to try it in, just to diagnose/test it?

I don't believe CHKDSK is "smart" enough (sorry for the pun!) to deal with anomalies that occur with SSDs. Conventional magnetic disks can produce a "signature" of sorts that CHKDSK will mark the sector as bad so data is not stored there. This would be a false positive with a SSD. Clearing the drive would fix that. If SMART says otherwise that's what should be believed as correct.

So the issue is what caused it in the first place? Cabling would be the first suspect. Also make sure none of the controllers are running on overclocked buses, etc.

Is SMART 'smart' enough for SSDs? I'd have to brush up on my knowledge of SMART to consider that question.

 

[Rubycon]

It's not an issue with SMART it's the CHKDSK utility.

 

[mikeymikec]

It's not an issue with SMART it's the CHKDSK utility.

I didn't say it was an issue with SMART, I merely asked a question.

 

[Grit]

The drive is over a year old.

I switched the cable out and I'm waiting to see if I develop any other problems.

When i run chkdsk, there are no NEW errors, but it reports "116k in bad sectors". Is there any way to fix that?

I wanted to do the "factory reset" thing, but there is apparently no utility for the Crucial ReaSSD C300.

Suggestions?

 

[Burner27]

A secure erase will bring it as close to 'factory new' as you are going to get. Parted Magic has an 'erase disk' utility in it.