My steps for updating Force GT to 1.3.2

Up to this point I've been seeing an average of 1 BSOD per 24 hours even with an RMA replacement drive dropped into a brand new Z68 motherboard and new Windows 7 install. The first drive was BSODing regularly in a completely different mobo/chipset/processor/windows load.

 

I found some info on a competitor's site that indicated Sandforce and this other company are very aware of issues specifically related to the BIOS, AHCI, and Windows and how the three track information about SSDs in a computer. Specifically, there is a lot of voodoo being tracked (DMI only?) in the BIOS and in Windows that simply updating the SSD firmware does not clear these other pools of configuration details. Based on their info and some additional precautionary steps I added, here is how I went about updating to 1.3.2 to hopefully chase the BSOD demons away. I will update again once I have a chance to monitor system stability.

 

 

1. Backup with Acronis True Image

2. Update BIOS to latest release

3. Power down (pull plug)

4. Clear CMOS for 1 minute

5. Power up and reconfigure CMOS

6. Boot to Windows

7. Update Corsair Firmware to 1.3.2

8. Power down (pull plug)

9. Remove power from SSD for 1 minute (a competitor's site indicated that Sandforce strongly recommends this step)

10. Clear CMOS for 1 minute

11. Power up and configure BIOS

12. Boot off USB stick and run Parted Magic -> Secure Erase

13. Power down (pull plug)

14. Remove power from SSD for 1 minute

15. Clear CMOS for 1 minute

16. Power up and reoconfigure CMOS

17. Boot from Acronis True Image CD and restore data to Corsair (including disk signature)

18. Reboot into Windows (Corsair). I did see Windows re-add the drive but just to be safe make sure Windows gets updated info from BIOS/SSD...

19. Go into Device Manager, navigate to disk drives, navigate to the SSD drive, right click on it...uninstall

20. Reboot back to Windows, let the drive be installed again and reboot

21. Power down completely

22. Boot to Windows

23. Pray to the Silicon Gods that F4 and 7A BSODs have been banished to the 666th level of Hell or Redmond, whichever is further

It has now been 4 days since I did the steps above and ZERO BSODs :biggrin:

 

I'll give it another week and post my success/failure.

Cheers. I'll probably be following this very elaborate guide for when/if my SF bug reappears..

It is now roughly 8 days and still ZERO BSODs.

Obviously I am an idiot, where did you get your Acronis True Image? Did it come with your drive, it seems to come with many peoples drives when they buy it but mine did not have one.

http://www.acronis.com/homecomputing/products/trueimage/

As Wired pointed out, TrueImage is a paid app. It is one of the best tools for imaging, cloning, and backing up drives at the sector level. It can also resize images to fit a new drive, assuming that the total actual data is less than the new drive size.

I forgot to mention: 11 days and ZERO BSODs.

So what would be the order of steps with a clean win 7 install and not a system image?

Force 3 and Force GT Firmware 1.3.3

So what would be the order of steps with a clean win 7 install and not a system image?

 

Note that most of the steps I took could still be relevant. You still need to update your system BIOS. You still need to flash your drive if it isn't already at 1.3.2. or 1.3.3. And if you flash it, you need to follow those steps I gave to ensure that the BIOS and the drive are correctly talking to each other.

 

99 times out of 100, it all just works. I'm one of the poor saps where the drive, the BIOS and Windows refused to get along. Until I dug deeply, I had no idea how bad the SATA spec was. I've been building computers and/or programming for nearly 30 years. The stuff I saw about SATA guts was downright scary. I'd say the guys that designed the spec saw some nasty possibilities at the edge cases (or didn't even bother thinking of the edge cases). They didn't prepare for them in advance. Fast forward ten years. We now have devices pushing as much data via SATA as conventional memory controllers dealt with when the SATA spec was being written. Add in a whole bunch of power saving states that were invented in the last 10 years. It doesn't take much for something to go POOF. This doesn't absolve Sandforce of making a big mistake in the 2281 controller logic but it does seem to indicate this may happen more frequently in as the SATA spec advances.

Fast forward ten years. We now have devices pushing as much data via SATA as conventional memory controllers dealt with when the SATA spec was being written.

 

Not to mention we are now at the data rate limits of the SATA cables available these days too. This is why a properly manufactured cable that falls well within spec is essential.