This project has moved. For the latest updates, please go here.

Encrypting system drive gives "0xc0000452" error possibly due to main drive not being on disk 0 + screenshots


Using VeraCrypt 1.19 (64-bit)

Initially the SYSTEM_DRV was on DISK 0, which is an older slower disk. So I copied the partitions to my DISK 2 SSD Drive which has windows installed, removed the DISK 0 drive, restarted and then put the DISK 0 back in again. Checking in AOMEI shows everything to be correctly now.

Screenshot drives

However when I try to encrypt my system drive now I get the following error:
Error: 0xC0000452
Source: VeraCrypt::Elevator::GetEfiBootDeviceNumber:371
Screenshot error

I somehow suspect system drive encryption only working for DISK 0 and isn't working in my case since the Windows installation is on DISK 2.

Now I have tried to remove DISK 0 completely and have my SSD in DISK 1 but it still shows the same error.

Any suggestions?


in90 wrote Mar 8 at 3:37 PM

I get this error as well (with v1.19 and v1.20-BETA2). It pops up directly when chosing 'encrypt system' in the menu bar of the main window.

My setup is different: I removed all internal drives from the system. Win 10 boots&runs from an USB key/thumb drive instead. No other USB devices are attached. The boot method is UEFI with Secure Boot on. Therefore, there is a small EFI partition on the drive which is followed by the main system partition containing the Win installation.

The error seems to be related to a GPT partition table on the drive.
For testing, using gdisk and parted I replaced the GPT partition table and its backup ('zapping' it, i.e. zero out?) by the appropriate msdos style MBR partition table matching the sector positions of the existing partitions. The Windows installation has to be fixed as well after this as shown here.

With a plain old MBR partition table on the drive I do not get this error anymore.

By looking into the source, it seems that PARTITION_STYLE_GPT is never set? Just a guess (can't test this now, due to lack of a development environment on Windows):
The error message is thrown in Elevator::GetEfiBootDeviceNumber() which basically calls BaseCom::GetEfiBootDeviceNumber() getting an errorneous result possibly because of an exception thrown in BootEncryption::GetEfiBootDeviceNumber(). The latter throws an exception if config.SystemPartition.IsGPT is false.

config.SystemPartition is set by BootEncryption::GetSystemDriveConfiguration() which calls BootEncryption::GetDrivePartitions() which calls the driver for partition info in case TC_IOCTL_GET_DRIVE_PARTITION_INFO.
IsGPT gets set based on pi.PartitionStyle from IOCTL_DISK_GET_PARTITION_INFO_EX
There, the PartitionStyle is set to PARTITION_STYLE_MBR but never to GPT style.
grep also does not find any other place where it is set. Is this true? How does it work then for GPT+UEFI system disks/partitions? Or am I wrong in my assumption that it is supposed to work?

Because it seems to be very much related to GPT support, I suggest to rename the issue to something like "GPT support for system encryption".

Thanks for more info on that!