TRIM update hosed my Windows 7 install

[idata]

Just did the firmware update and it hosed my Windows 7 installation. The updater showed a successful firware update. Initially the computer booted just fine, but once I was within Windows it installed some drivers and asked for a reboot. That's when the trouble started. Now the drive won't boot Windows 7 anymore. I don't know if it's a Dell problem or Intel problem. The Dell BIOS claims a SMART error. I have a Dell XPS 8000.

[idata]

What I mean is full image versus cloning. I believe there are two ways with cloning being one and full image the other. Been some time since I used Acronis, but I am fairly certain there were two methods: Clone is one method and full image the other. From the drop-down menu, do you see Clone?

[idata]

Yes, you are right. I just looked at the Acronis True Image (ATI) cloning function, having never used it before. It is capable of altering the MBR partition table to resize partitions in the case of cloning an OS from one disk geometry to a different geometry. As such, I would not use it to copy the SSD image back to the same SSD after HDDErasing the SSD, because its ability to mess with the MBR would make it even more likely to change the offset of the start of the first partition back to the pre-Vista "standard" 63-sector offset.

What Acronis should do has been suggested in other forums. They should create an "offset" field to optionally allow the user to change the partition offset at image restore time. At the very least, ATI should advise the user if the offset is about to be changed to 63 sectors at restore time.

I am guessing that what is happening is this: If a user does not check off the "restore MBR" checkmark box at partition restore time, ATI is too lazy to extract the MBR from the archive in order to check the first partition offset value in the MBR partition table. Instead, the algorithm simply assumes 63 sectors and places the partition(s) accordingly. If (when) the user later restores the MBR, ATI reads the MBR and realizes that the partition table does not match the errouneously-placed partition location(s). Then, instead of moving the partitions to synchronize their locations with the partition table as extracted from the archive, ATI simply revises the partition table to match the placement of the erroneously-positioned partition(s). In contrast, if the user selects the option to restore the MBR with the partition(s), ATI must extract the MBR anyway. So it first extracts and reads the partition table and places the partition(s) accordingly, yielding a correct result.

That is just a postulation, of course. If correct, though, this would be a prime example of a problem that is endemic in today's software technology: second-guessing the user's wishes or intentions. In my mind, Microsoft is the worst offender, perhaps because of the sheer volume and complexity of their software and their attempts to protect unsophisticated users from themselves. Trouble is, I believe that they consistently under-estimate user sophistication and wind up with unnecessary banality as a result. Witness the naming of registry-coded Windows Explorer folders "My Documents," "MyPhotos," etc. Sounds like kindergarten. It seems to me that the big software companies and chip manufacturers control and infantilize the language of computing to a large degree. Remember when a "folder" was a "directory"?

[idata]

Yes, but the backup in Windows 7 is simple, straightforward and does the job, and it is free!

The renaming of folders doesn't bother me much, but the new control panel does; I liked the old control panel in Vista, and I liked the Windows Mail email program. However, we are getting off-topic here, so back to bashing Intel. 😉

[idata]

Call me lucky - knock on wood - got a Dell Inspiron 1720 laptop with a X25-M G2 80GB in it and it flashed w/o issue. A09 BIOS, T7700 C2D w/4GB RAM, running Win7 x64 in ATA mode, as that gave me better throughput than AHCI did, especially in seq read - 215MB/s vs 135. SSD was originally imaged from a Win7 install on a 200GB Hitachi in AHCI mode. Crystal Disk Info confirms that TRIM is active. FYI - I got this SSD about 2 wks ago, new from ZZF.

[idata]

Hearing from many cases, now I'm thinking changing mode between IDE/AHCI after firmware update may (or may not) cause the problem.

Well it seems to make sense thinking about how TRIM and Optimizer will do erase data which is considered to be deleted. And the theory is that when you switch SATA mode, information about which data is deleted gets corrupted.

Then, you could imagine the following cases:

Case 1. Upgraded in IDE mode, then switched to AHCI.

-> Your disk has wrong information about which data is valid and which has been deleted. And then...

Case 1-1: You are using windows AHCI driver and TRIM is enabled.

-> Your system will AUTOMATICALLY try erasing deleted data (which may haven't been deleted). Thus, IT GOES WRONG AUTOMATICALLY.

Case 1-2: You are using windows AHCI driver but TRIM is not enabled / OR You are not using windows AHCI driver.

-> Your system will not automatically try erasing deleted data. However, if you run Optimizer, or your toolbox runs Optimizer by schedule, then it goes wrong.

Case 2. Upgraded in AHCI mode, then switched to IDE

-> Well, actually I haven't heard from anyone who did like this. But it may corrupt disk information as well I guess. in IDE mode, Windows will not automatically try erasing data(not sure). Thus, it will go wrong only if user or toolbox run Optimizer.

SO, is there anyone who was unfortunate, but did not switch SATA mode during the upgrade???????????????

Of course I'm mostly guessing, but if there are few people who actually had the problem without switching their SATA mode, I will go try upgrading my SSD (which is on the way) in AHCI mode throughout the process.