This project has moved and is read-only. For the latest updates, please go here.

Drive and/or partition encryption and/or decryption slows to a halt, Windows freezes, and then drive becomes corrupted

Topics: Technical Issues
Oct 29, 2014 at 4:54 PM
Edited Oct 29, 2014 at 8:13 PM
Hiya team! Appreciate you taking the time to read about my problem.

I have a fresh Windows 7 64-bit install on a 256GB OCZ Vector SSD. Motherboard is Gigabyte GA-97X-SLI. CPU is Core i5-4690K.
I downloaded VeraCrypt and attempted to encrypt the entire drive, as I had successfully done in the past (on a different machine) with TrueCrypt.

The encryption process begins briskly, but for some reason is reboots my computer about halfway through (don't know if this is normal?). Then it continues, but by the time I get to about 96% complete, the status indicator begins to flicker back and forth between encrypting and "waiting," even though I have nothing else going on in the system. I have even done this without ever installing the network drivers, so I know nothing should be's not like Windows Update is secretly running, or anything like that.

As the "waiting" indicator flickers, the encryption process slows dramatically. Even if if DOES NOT indicate "waiting," it encrypts so slow that I might get about 0.001% per second. Eventually it stops completely, the program stops responding, and I have to manually turn off the system. It never reboots from there: I suspect the drive has been corrupted.

I have tried to encrypt my drive at least five times, but this always happens. I even tried it on the old version of TrueCrypt and got the same error. I have tried both encrypting, and not encrypting, the HPA: same result.
I once tried encrypting only the partition (not the entire drive). I successfully encrypted, but the error returned as I was decrypting the drive, so I think it was merely luck that I did one successful encryption.

Any thoughts, please?
Oct 29, 2014 at 11:17 PM

In the past, there have been instability issues with some disk kernel drivers when using TrueCrypt for which some workarounds were implemented but it can't cover all cases of buggy or non standard drivers. I'm not sure if this is the case with your SSD drive, maybe you are just facing a defective SSD drive.

A quick search of "OCZ Vector SSD freeze" leads to many posts that exhibit identical symptoms although not in the case of encryption. So, one possibility is that the SSD controller have issues handling high-speed write operations of encrypted data for which it can't do any compression.
Oct 29, 2014 at 11:28 PM
Hi Idrassi, thanks for the quick response. To UPDATE my post, I suspected it might be this OCZ drive, so I ran a full disk (including HPA) encryption of an old Intel brand SSD that I had lying around, and it worked like a charm. So I can conclude that this particular drive just won't encrypt, for some crazy reason.

Original problem solved.

The OCZ drive (with the failed encryption) now appears dead. If I attempt to boot it, I get the VC bootloader, which prompts me for the password, but then Windows hangs during load.
I have another (unencrypted) drive that I also boot from. The really weird thing is that drive will hang at Windows load as well, if I have the OCZ drive plugged in. If I shutdown and unplug it, the unencrypted drive will boot just fine.
If I try to run Windows 7 install disk on the OCZ drive, it does not see any drives and I cannot choose where to install Windows, because it does not see any drives.
In summary, the OCZ drive is now all messed up and my computer won't even start if I dare to plug it in! The BIOS, however, does recognize it.

I'd really like to format this drive and have it available again, but it seems dead. You will probably tell me it has failed, but this is an old drive that worked reliably for me for two years; only when I ran encryption on it did it suddenly die. Seems unlikely it's a mechanical failure...more likely it is just formatted incorrectly somehow.
Oct 30, 2014 at 9:58 PM

I think your drive controller was not able to handle correctly the fact that all its space was going to be written using encrypted data. This may explain why the more encrypted data was written, the more unstable the driver since the optimization algorithm of the controller was trying to find free space to optimize write operations.

It is possible that the internal state of the SSD controller is now completely incoherent and that you need to do a reset at the firmware level to make up and running again. I don't know if this is possible with your SSD brand and it may be the only remaining solution.
Oct 30, 2014 at 10:15 PM
Fascinating, thank you idrassi.