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?

Answer 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!

Answer 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.

Answer 3

I had found another issue with DiscCryptor and GPT disk.

I have multiple Windows 32 Bits (all Home versions from Vista to 10) on the same GPT disk (the only one present, it is a laptop with BIOS only, no U-EFI); yes and yes, it is BIOS only and disk is GPT with more than 4 primary partitions, all partitions are GPT, except one small 8MiB RAW GrubBIOS for Grub2 core.img... and yes, yes, Windows 32 Bits; remember Windows does not boot from any disk that is not MBR, i do not like Hybrid GPT+MBR, i prefer Grub2+MemDisk+VHD small files (32MiB or less).

My disk is 100% GPT, has one GPT NTFS partition for each Windows for the system (where WINDOWS folder is, but NT60 boot code & BCD is not in there), it also has an extra NTFS partition for Grub2 & MemDisk & VHD files (else that 32 Bits windows will not be able to be booted from a GPT disk, aka 32 bits on BIOS + GPT disk); that VHD files are fixed size (just to let memdisk emulate them on ram) and internally have a MBR disk with only one 32MiB NTFS partition where there is the NT60 boot code and the BCD for that specific Windows; one VHD per Windows.

This is a sample (all windows are 32Bits and Home versions, no Pro, no Enterprise, no Server, 100% legal stuff) on the GPT disk i do tests on:

• 1st sector = Grub2 boot code + GPT protective
• GPT1 = 8MiB RAW GrubBIOS (where Grub2 put core.img in RAW)
• GPT2 = 1GiB NTFS for Grub2 files + MemDisk + VHD files
• GPT3 = NTFS for 32Bits Windows Vista SP2 system (Windows folder, etc)
• GPT4 = NTFS for 32Bits Windows 7 SP1 system (Windows folder, etc)
• GPT5 = NTFS for 32Bits Windows 8 system (Windows folder, etc)
• GPT6 = NTFS for 32Bits Windows 8.1 system (Windows folder, etc)
• GPT7 = NTFS for 32Bits Windows 10 system (Windows folder, etc)
• GPT ... and so on ...

Each VHD is arround 32MiB virtual MBR Disk, like this:

• 1st sector = Nt60 boot code + MBR partition table
• MBR.1 = Primary NTFS 32MiB (where BCD stuff is)
• MBR.2 = -empty-
• MBR.3 = -empty-
• MBR.4 = -empty-

One VHD file per each windows (to isolate bootloaders & BCD).

If i want to put all that on a MBR (it is limited to 3 primary + 1 Extended) i can only put 3 Windows (Grub2 can be on a Logical inside the extended), that 3 primary ones will be the ones that have each BCD stuff (isolating BCDs of each windows)... if i allow all Windows BCD on the same partition i can put as many Windows as i want, but all of them will share the BCD, so the boot menu will be the one presented by windows, they will not be isolated, a fail on one of them touching such BCD will ruin the boot of all the rest, etc., not to mention i also want Encryption.

With that GPT + Grub2 + MemDisk + VHD files i get wat i want (except encyption), 100% isolate each Windows from the rest of Windows.

I want a BIOS and not U-EFI for three main reasons:

1. I want 100% of the HDD (except first sector, GPT table and second copy of the GPT table at end of the disk) to be encrypted... still working on how to encrypt that partition i use for Grub2 + MemDisk + VHD files... i had considered creating one extra partition for each VHD file... so that one will be encrypted as the System is and then Grub2 one with LUKs (using modules parameter when doing grub2-install).
2. My laptop has no U-EFI, it is BIOS only
3. My HDD is bigger than 2TiB (MBR only allow up to 2TiB be used, the rest is lost)

Going back to the problem with DiskCryptor, if i encrypt the booted Windows GPT partition (where WINDOWS folder is), put the boot code on the other Virtual MBR disk (that is inside the VHD file), after booting it asks for password but it allways shows the error of 'invalid password'.

But if i do not encrypt the booted Windows GPT partition (where WINDOWS folder is), and i only encrypt the partition where BCD is (the one inside the virtual MBR disk that is inside the VHD file), at boot it asks for the password and if correct one, it boots windows perfectly (except it does not automount the virtual disk partition of the BCD, i must mount it manually... must see if i get it to automount), but Windows works great.

And if i encrypt both of them (with the same password), then Windows bootmbr loads but it tells winload.exe can not be found in a blu background with white text graphical screen.

When i only encrypt the MBR part, the not automount may be caused because VHD file is not connected early enough... maybe caching password and running DisckCryptor at logon can solve that since VHD connect is done in a task schedule before logon... i must test that if i have time.

Seems like having "System reserved" or what ever you want to call it (where NT60 boot code & BCD stuff is) on a different disk is not supported by DiskCryptor, or at least not if Windows 32Bits is on GPT partition (where WINDOWS folder is).... since having that Virtual MBR encrypted works well, but having GPT partition encrypted cause different kind of errors!

I will re-try a lot more options, like creating a ISO and booting with that, etc.

Thanks i have multiply Windows, i booted with another one, install DiskCryptor, rebooted and try to mount the GPT one, it mounts OK, so i decrypt it, and fix the big problem of not been able to boot thar one, till i find a solution i will do more test on a VirtualBOX machine, prior to lead with my Laptop again... i wish DiskCryptor would have warned me before doing it... but at least i know what i am doing and i know booting form the other windows i can decrypt, also i have Clone BackUp, etc.

Maybe i miss something! Maybe i do not fully understand how to Boot or where to put DiskCryptor bootloader, how to configure it, etc.

Please have in mind i want more than 4 different Windows Home 32 Bits on the same GPT disk, i want them 100% isolated, including boot codes, BCD and such stuff... that make no other option... GPT in mandatory ... i also want them encrypted with different passwords, not only the system (where Windows folder is), also the boot partition (where BCD is), encryption Grub2 is easy for me to do so to not make thing complex i use it not encrypted till i find a working solution.

I thought protecting the boot partition (where BCD is) would be much more dificoult than system (where WINDOWS folder is) it self, but i found just the oposite.

I must test, test and test... may be i found a way.

Yes, in case someone is thinking about them, i had tried TrueCrypt and VeraCrypt, both have greater problems, TrueCrypt does not allow GPT system encription and VeraCrypt assumes GPT disk are only for U-EFI so it fails when trying to backup U-EFI stuff, no matter if i put a EFI partition, since machine has no EFI vars (BIOS only, no U-EFI) it fails.

The boot (without encryption) goes this way, Power on, BIOS run, BIOS read disk first sector, find a Grub2 bootloader code, run it, read RAW GrubBIOS (core.img) and run it, Grub2 do its stuff (read grub.cfg file) and show the menu, i choose what system i want to boot, Grub2 then loads memdisk and put in the virtual hard disk the corresponding VHD image and jumpt to it, the code on the MBR of that is run (NT60 code), then bootmgr is loaded and runs, then winload.exe, etc... normal windows boot... then my Schedule task is launched on SYSTEM account, that same VHD is connected, now the BCD is able to be accessed, logon prompt appear, i choose user, etc... normal windows continue... desktop apears.

All boot is done from the same HDD, it is on GPT style, the trick is that prior to boot windows i mount (with Grub2 + memdisk + VHD file) a Virtual MBR disk where the nt60 boot code & BCD are, that way Windows is really booting from what it knows, a MBR disk, but it is a virtual one stored in a file, stored in a GPT partition, the other good trick is thanks to Grub2 that allows to boot from GPT disk on a BIOS only PC.

Hope someone can reproduce my boot procedure and test DiskCryptor. Also hope some day VeraCrypt will not asume GPT = U-EFI.

To create the VHD i used DiskPart from windows; it can also be created, mounted, accessed, etc. after booting from the Windows Install Media and going to a console (Shif+F10 after select language) and using DiskPart.

Thanks DiskCryptor i am a little bit near to what i want, but still not there, just a little step more... boot Windows!

Next part will be mounting DiskCryptor from a SystemRescueCD (a Linux Live distro), but that will be a really hard story it able possible.