Windows 10 Update 1511 fails with DiskCryptor whole disk encryption

Question

I am running Windows 10 with DiskCryptor whole disk encryption on the system drive. The latest Windows 10 update fails to install. When I restart the system to install the update, I get the following sequence of events:

• I enter my DiskCryptor password which unlocks the disk
• Windows Update asks for the keyboard layout
• Windows Update then fails shortly after

If I push through the process far enough I get to a message that indicates it cannot continue because a file (or files) is locked.

My colleague also uses DiskCryptor on his system drive and has had an identical experience.

So:

• Is this a known issue with whole disk encryption generally?
• Is this an issue with DiskCryptor specifically?
• If so, is it a bug MS will be fixing or will it require a workaround?

Solution 1

This appears to be a problem with Full Disk Encryption software generally (with the presumable exception of MS's own BitLocker). From the VeraCrypt coordinator himself:

Windows 10 version 1511, build 10586 update fail

TrueCrypt would have had the same problem. It is this specific Windows update that seems to disable filter drivers used for on the fly encryption and if Windows was encrypted using TrueCrypt, it would have failed too. There is nothing magical in TrueCrypt driver that would have prevented this.

Microsoft is doing something nasty in the update installer. VeraCrypt driver is working as expected but this installer clearly blocks it during the process of updating the system. By doing this, Microsoft is breaking FDE software other than Bitlocker and Microsoft partners ones.

What is the best way to report this to Microsoft? Obviously, on VeraCrypt, we are lacking man power to investigate further such deep kernel blocking by the update installer.

The workaround is described in a separate forum post:

You must decrypt the system encryption before performing any OS upgrades.

Also, Windows 10 November update requires decrypting the OS in order to apply the Windows 10 1511 update. Normally this is not necessary.

NOTE: Dismount and disconnect any external encrypted volumes attached to your PC before you begin the OS upgrade. I have seen users complain in the past that the Windows OS upgrade sees the encrypted drive/partition as RAW format and Windows tries to be too helpful by automatically quick formatting the partition and assigning a drive letter to make it usable by Windows.

---

UPDATE: Just to close the loop, I performed the following steps with no ill effects. As always, backup first!! I did not need my backup, but I can't guarantee you won't need yours ;).

1. De-crypt the system drive (most likely C:)
   • I have a secondary hard drive (D:)
   • This D: drive was also encrypted
   • I did not de-crypt my D: drive
2. Apply the Windows update
   • The DiskCryptor bootloader still prompted me for a password at each reboot
   • I just pressed [Enter] without any password and the machine booted
3. Re-encrypt the system drive

Quick note about the encrypted D: drive (secondary drive):

Be very careful when Windows 10 boots up and the C: drive is still un-encrypted. The D: drive does not get auto-mounted at startup in this scenario. If you double-click on the D: drive, Windows will not recognize it and offer to format it for you. To mount the drive, you need to open DiskCryptor, choose the D: drive, click on [Mount], and enter the password.

Windows did not automatically format my secondary drive, but it would have been very easy for me to do it accidentally. Proceed with care!

Solution 2

I realize this is thread is a little old but for the sake of searchers ... The presence of DiskCryptor prevents Windows (10) 1709 (at least) updates without any specific related errors being reported - just blue screen at the end and reinstall old version ... does not matter if DiskCryptor drives are actually mounted or not.

Simple solution is to uninstall DiskCryptor, run the update(s) and reinstall - worked for me after many days of researching why my systems were not updating.

But after the update is installed, at least with the Creators update, the behavior of mounted drives has changed. Mounted volumes are no longer dismounted when doing a Windows shut down. In fact it appears that DiskCryptor prevents a Windows shutdown if any DiskCryptor drives are mounted, and the station just goes to sleep (which if you're not observant, may not be noticed) - when waking up, drives are all still mounted! I tested this on two Lenovo laptops w/Win 10 home, and 1 desktop w/Win 10 Enterprise - no diff. Hope this helps someone and I hope Windows patches this quickly - unless the intent is to force the move to BitLocker :( btw this new behavior was not present when I tested it with TrueCrypt. Drives automatically dismount on shut down.

Comments

[Ramhound]

"Normally this is not necessary." - Actually normally it is. What is described is normally what happens, at least it is what happens, ever since Windows 8.1 and Windows 8.1 Update 1. What I think the author of that statement means is, updates that don't change the kernel, if that is the case then and only then would I agree with that statement. Before I noticed this answer, I was going to ask, "you did decrypt the drive before you attempted the upgrade" turns out this would have been the solution.

[Ramhound]

It is worth pointing out. Any "update" to Windows that change the major or minor build number more then likely will require this procedure to have happen, at least until, these alternative FDE solutions support GPT and thus UEFI. I also wouldn't say its a problem with FDE, but legacy FDE solutions, that are the problem.

[alfredtofu]

That NOTE in the last part is particularly troubling to me. I have a secondary hard drive that is also encrypted. It appears that I should physically disconnect the drive's cable before I decrypt the system drive and apply the update. Otherwise I run the risk of Windows formatting the secondary encrypted drive and losing all the data on it. Is that right?

[Ramhound]

Let me preface my response with, you should have a backup of the data, but I don't agree with that part of the comment.

[munrobasher]

This is very annoying to say the least but I'm glad you posted so I didn't waste hours of my time trying to see if I'd broken something

[munrobasher]

Sadly Ramhounds observations about lack of support for GPT & UEFI is the core problem in legacy applications. The next question therefore is there any product which can encrypt a Windows 10 laptop that has neither the TPM chip OR the correct version of Windows. My client is trying to save money (false economy maybe) and has bought laptops with Windows 10 home. At least one can upgrade Windows 10. Lack of TPM is a bigger issue

[Martin Argerami]

@munrobasher: the GPT/UEFI support is not the answer. I had a laptop with GPT/UEFI and FDE via Bestcrypt. Update to 1511 failed repeteadly; eventually, the hp recovery software kicked in and left the hd unbootable. I had to reinstall.

[munrobasher]

Not good! We've had to stick with TrueCrypt on the non-TPM systems and convert the disk to MBR via image, clean, switch, restore. Fortunately the company only had three laptops without TPM and the new Yoga 500s have them fitted. That said, I'm not looking forward to the Redstone release in a few weeks! We've already purchased an external hard drive ready to image before fiddling!

[cablop]

I confirm this behavior does happen with Truecrypt and Windows 10. System won't update, asks for keyboard but leads you to a page telling you you need to restore the system. You just need to shut down and turn on the PC again and continue using the previous version, as if you didn't updated the Windows.

[Ramhound]

This does not really answer the author's question.

[DavidPostill]

This is not an answer to the original question. If you have a new question please ask your own question (referencing this one for context if it helps).

[flith]

+1, I've been having the same issue with Windows 10 and Diskcryptor, and I was just about to try disabling the encryption when I decided to check online first if others had had the same problem. Turns out they have, so thanks for confirming it for me! Off we go then...

[Oran D. Lord]

I was having this issue while performing any feature update (1511 to 1703, 1607 to 1703, 1703 to 1709, etc) with Symantec Drive Encryption enabled. I had to completely uninstall the program and reboot after decrypting the drive, or the updates would fail with obscure error codes.