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

Pre-Test for UEFI Boot fails

Topics: Technical Issues
Jun 13, 2016 at 2:12 PM
Edited Jun 16, 2016 at 12:49 PM

I tested if my system supports UEFI Boot with Veracrypt.
Installed newest Beta, AES and SHA-512 selected. No warnings displayed. I let Veracrypt reboot.
No Pre-Test is displayed nor any text. It just boots like there wasn't any change.
In Windows, Veracrypt says there was an error. Tested multiple times with SecureBoot enabled and disabled, but nothing changed.
Jun 13, 2016 at 2:55 PM
Which Beta 1.18 did you install since there are two betas? One beta is more production ready but lacks the UEFI.

Did you install the "VeraCrypt Setup 1.18-EFI-PREVIEW-BETA.exe" beta? This is the installation for Windows that will support GPT/UEFI but lacks some production features like being able to create the VeraCrypt Rescue Disk.

As noted by the developers:
Important Note: Disabling legacy compatibility mode in BIOS configuration before starting system encryption solves many Pre-Test failures. This option can be called CSM, Compatibility Mode, Legacy Mode or other names depending on the motherboard manufacturer.
Jun 13, 2016 at 3:04 PM
Of course the EFI Preview, otherwise it would say: 'System encryption for UEFI is not supported yet'.

In BIOS (Insyde) there are only two options like that:
  1. UEFI or Legacy (I use UEFI)
  2. (Only when UEFI enabled) Secureboot (as stated above)
I tried every combination, but nothing worked.
Jun 13, 2016 at 3:23 PM
SecureBoot must be disabled otherwise VeraCrypt EFI bootloader is disabled.

Since you don't see VeraCrypt password request after reboot, this means something is blocking it. Here is a procedure to investigate further:
  • Ensure SecureBoot is disabled
  • Launch system encryption wizard and complete all steps but instead of rebooting, shutdow your machine.
  • Power your PC and go to BIOS menu: look for boot entry and check the list of available boot entries
  • You should see an entry for Windows Loader and another one for DcsBoot. Is it the case? If yes, choose DcsBoot to perform Pre-Test.
If you see only Windows Loader, then you certainly have the same issue as another user on Sourceforge forum (here). Basically he needed to use extra tools to be able to boot VeraCrypt EFI loader.

I'm currently working on a possible solution for this and I will publish soon a new preview.

By the way, what AntiVirus software are you using? some of them may block custom bootloaders from installing.
Jun 13, 2016 at 3:42 PM
Edited Jun 16, 2016 at 12:49 PM
The Boot order was the problem. 'DcsBoot' (can it be renamed to 'Veracrypt' so it's use is clear for the user?) is set behind Windows bootloader so nothing happend.
Pre-Test was a success, but the time to boot after the authorization (when a line was added for a second before the boot (I think it displayed the bytes of the disk)) seems to bigger, for me up to 15 seconds (without encryption!)).
Jun 13, 2016 at 4:56 PM
Also, with Beta 18 installed, when a file volume fails to mount (because of a wrong password) the processes 'System Idle Process' and 'System' use all CPU avalible and won't display that I entered a wrong password.
I think something in the decryption fails and goes over to a loop...
Jun 13, 2016 at 10:36 PM
Thank you for the feedback. I will check the boot order issue.
For bootloader name, it will be changed to VeraCrypt (DCS stands for Disc Cryptographic Services)
You can reduce boot time by choosing a small PIM (you can use change password functionality for this). Next preview version will include a PIM benchmark that will help user see the time taken for each PIM value.

As for the time taken by password verification, it doesn't depend on the disk encrypted or not: it is the same in both cases.

Concerning the wrong password issue, it is possible that is just taking too much time. Did you select "Automatic detection" for PRF? If yes, this would explain the issue since the current EFI preview add new hash functions that are slow and this makes auto-detection more CPU intensive and last longer. It is always advices to choose the correct PRF in password dialog.
Jun 14, 2016 at 12:37 PM
A PIM Benchmark is a good idea.
Also it would be great, if you add a 'without encryption' type to the benchmark test, so we can see (fg. for old systems which have no hardware AES) how fast/slow the disk is.
I always kept 'Automaitc detection' on so it took more time to brute-force every combination (prf - password - pim).
The new hash functions slow the process down. Selecting 'SHA-512' dramatically increases the time to mount (and when password is wrong to fail).