Verified rescue disk does not work (1.19 / UEFI / Windows 10)

[ralfbiedert]

Two days ago I enabled Full Disk Encryption on my primary drive.

The process completed successfully:

• I created a 'rescue disk' (which seems to have been an ordinary .zip file),
• copied the content (EFI folder) onto a USB disk and
• VeraCrypt verified it successfully.

I was able to reboot and use the system a number of times.

This morning, probably after some nightly updates, the VeraCrypt boot loader was gone, and Windows kept going into Recovery Mode.

Trying to use the verified 'rescue disk' (the USB stick) does not seem to work. Attempting to boot from it yields something in the lines of "Operating system not found" (the total size of the EFI folder is about 2.2 MB)

I was able to boot Mint from a stick as shown in this video and verify that I still can decrypt the partition from a manually installed Linux VeraCrypt. (On a side note, for some reason I seem to be unable to follow the 2nd part of the video using efibootmgr due to allegedly lacking EFI variables).

I am using v1.19 on a UEFI Windows 10 system. The motherboard is a Z97 Gaming 5, secure- & fast-boot disabled, the stick is a 32GB, USB 3.0, formatted FAT32.

On top of the bug report, I would also appreciate some feedback on how I could either a) manually restore the VeraCrypt bootloader w/o a working rescue disk, or b) permanently decrypt the partition w/o a working Windows ...

[gartnera]

I was installing veracrypt today. Oddly enough, I'm on the same board (Z97 Gaming 5). I installed some updates and it triggered recovery mode. I was able to go into the EFI shell then type fs1:/EFI/veracrypt/dcsboot.efi. I was then able to type my password and windows booted.

Then I did this to (hopefully) fix it permanently.

What are the contents of your EFI folder? If you don't see the dcsboot.efi, you might be able to download one from here, I'm not sure how it detects which partition is the system partition/partition to be decrypted.

[ralfbiedert]

This saved me so much time, thanks a lot! Worked exactly as described.

I think your instructions should go into some UEFI Emergency FAQ.

In addition, I have the feeling the Z97 board has trouble booting UEFI from USB sticks. If that is really the case, maybe VC could add a step encouraging users to attempt to boot from the generated stick and positively verify it will be capable of 'rescuing'.

Minimum effort could be adding a IF-THINGS-GO-WRONG.txt in / next to the generated ZIP with the information you provided and some other tips.

[FingerlessGlov3s]

Same issue. Encrypted my Windows 10 Disk today and it went for the reboot and now it wont boot (Boot Loops). Tried Rescue Disk on FAT32 USB and it does nothing... Laptop SSD Toshiba Z930 UEFI only mode set

I shall try Ubuntu VeraCrypt and see what I can do.

[inliquid]

Fuck. Guys, have you ever tried your software?

Your bootloader doesnt start on almost any of modern notebooks, it goes into rescue mode. Have you seen these threads on forums? I think ~100% of your users have got this shit. Others just removed your software and reinstalled Windows, gone for bitlocker or what so ever.

But not only bootloader, your fucking rescue disk has the same problem! It just does not work! Isn't it so hard to just try what you have compiled on a couple of machines?

[ghost]

I wouldn't use the language like "inliquid" does, though I truly am desperate myself as I seem to have lost my private and work data because of this issue - even worse, my encryption of the ssd was finished just partly - so I seem to have NO way to restore my data. Which is a catastrophe. Still, those developers did this work in their free time(!) - without getting paid for it - they too have to earn their money somehow during the days and probably have life-issues from time to time just like everybody of us. So I can't expect support and perfection like I would from a commercial company (and truly - are those programms perfect?). So no, wouldn't use that tough language. I am rather angry with myself that I didn't read about those problems BEFORE I made my work unaccessible. What keeps me alife is the hope that someone has a solution for me. Everybody else who managed to fully encrypt their disk should at least be able to restore his/her files by accessing the disk from another computer with veracrypt-function "System"->"Mount without pre-bootauthentication". I can't do that as the encryption didn't finish before I ended up in the repair-loop. :(

[inliquid]

@Micha1305 I really tried to find other words, but I can't. I read every single word in the instruction, I did everything they say very precisely. But after all it doesn't start neither from SSD, nor from rescue disk. And I see that there are a lot of other people having same problem, and it's not like brand new problem, it exists for a while already.

I understand that the software is open source and free, however

1. It's not written from scratch, it's a fork of TrueCrypt, and I never heard of such probplems with TrueCrypt (but when it was alive there was no UEFI).
2. VeraCrypt is promoted as #1 in user data encryption on mass market.
3. Contributing as developer to VeraCrypt gives you experience which you can transform into value. At least you are able to find a job in this area anywhere in the World.

My oppinion is that at least everyone has to be warned of these "unexpected" issues. I have another one when I tried to make Secure Boot working correctly I used some instruction from somewhere here which caused me to repair motherboard because of malfunction bios: https://github.com/veracrypt/VeraCrypt-DCS/issues/2

As for your problem, if the precess did not finish, I think your data was completely lost. You can try to mount it from another system but if it fails, sorry (((

[metaclips]

Please did you get yours to work I deferred and now I can't boot again

[lyubomyrv]

To all lame whinnies:

1. It is impossible to lose encrypted data even if youd hdd/sdd is badly damaged. You can mount already 100% encrypted system disk from another computer or via bootable usb stick or even via windows install disk (just press SHIFT+F10 to get command line). Veracrypt WORKS in bartPE environment from any bootable usb stick or windows install disk (just press SHIFT+F10 to get command line ignoring windows install interface).
2. You always can launch rescue bootloader at [yourbootdisk]\EFI\Boot\bootx64.efi, EFI backup disk is just zipped copy of your EFI folder. You can decrypt your system disk via bootx64.efi or encrypt it to the end even if your system is not loading or not working.
3. You MUST(!) set option OS: ANOTHER instead of OS: WINDOWS in the UEFI BIOS boot menu. It you set in bios boot menu OS: WINDOWS option, most old UEFI BIOSes often FORCE and REWRITE boot entry "Windows Boot Manager" -> \EFI\Microsoft\Boot\bootmgfw.efi and make this as default. Of course you will get "cannon find system files bla-bla" from default microsoft UEFI bootloader, because your system partition is already encrypted. During BIOS upgrades, changing BIOS unrelated settings - BIOS often rewrites your custom boot entry to microsoft's default bootloader, excluding veracrypt bootloader from boot chain. So once again - set OS: ANOTHER in UEFI BIOS boot menu BEFORE making fulldisk encryption. Latest veracrypt versions know about this issue and forcibly rewrites bootmgfw.efi with veracrypt bootloader(renaming original file into bootmgfw_ms.efi ) however this is against EFI specs (and BIOS vendors forcible adding multiple entry "Windows Boot Manager" also against specs).
4. Ensure or set MANUALLY UEFI boot entry "Veracrypt or thatsoever" pointing to \EFI\VeraCrypt\DcsBoot.efi at your boot HDD|SDD. Make this entry DEFAULT. You can do this in bios, in bios efi shell or booting from EFI USB boot stick and using free utility BOOTICEx64_2015.02.16_v1.3.3.2.exe. You can run BOOTICE utility from any BartPE environment or from windows rescue or windows install environment (just press SHIFT+F10 to get command line). Use BOOTICEx64 or BOOTICEx32 respectively. Also you can just replace \EFI\Microsoft\Boot\bootmgrfw.efi by \EFI\VeraCrypt\DcsBoot.efi file if you have crappy old EFI BIOS, which cannot load efi files from custom location. DcsBoot.efi will decrypt system partition and give it transparently to \EFI\Microsoft\Boot\bootmgr.efi
5. Once again - even if your system doesn't boot anymore, have bad sectors or badly damaged hdd|sdd - you can access and restore system partition. If it is system partition no encrypted to the end - launch \EFI\Boot\bootx64.efi from your boot drive, from your zipped copy of EFI files - doesn't matter till you remember your password. \EFI\Boot\bootx64.efi program is capable to encrypt or decrypt your system volume till the end without booting anything. Then mount 100% system encrypted from another computer, bootable disk (you can run veracrypt from very limited environment - safemode, bartPE? etc) with mount option "without pre-boot auth bla-bla" and enjoy. You can also clone your system partition evern from rescue environment or bootable disk with any software, which supports logical disks cloning - for example norton ghost. And yes again, norton ghost have x32 and x64 versions and can run from commandline in BartPe, bootable disk environment or windows installer environment (shift+F10). So you can easily clone your encrypted but not bootable or damaged system partition to another hdd|sdd and make all repairs as it was unencrypted.

[inliquid]

Wrong. You can't mount encrypted system drive on another computer. If it's regular non-system drive - you can, but it doesn't work in case of system drive.

Here -> https://github.com/veracrypt/VeraCrypt/issues/21#issuecomment-136216682

[lyubomyrv]

Wrong. You can't mount encrypted system drive on another computer. If it's regular non-system drive - you can, but it doesn't work in case of system drive.

Here -> #21 (comment)

You can do it at least for 10 years, since Truecrypt times ))) Also, if beginning of disk is corrupted or erased, there is backup header inside partition.

[inliquid]

Try yourself before posting bullshit here. Or just read the link that I gave you and see what @idrassi said, it's very clear.

[lyubomyrv]

Even at your link users are commenting about positive experience while mounting system volumes from external drives. First of all @idrassi is a programmer, and obviously not advanced user of his own product. For example, if you mount volume using password already cached in memory, VC doesn't leave a chance to define mount properties and mode before (without preboot auth, as read only etc..) instead it instantly tries to guess new slow salted algorithms, forcing users of huge park of already working truecrypt-encrypted volumes to wait. There is no another way to mount system partition with cached password as forcibly wait for useless iterations, before you get to mount options dialog. Also if your system volume is truecrypt encrypted user often have to wait three times: first time VC makes useless tries to open volume in wrong mode, second time VC tries to open volume with mount options properly set, but if user doesn't remember type of volume (truecrypt or veracrypt) he must do third try, explicitly setting "truecrypt mode" for mounting. "Truecrypt mode" mounting is 10 times faster than Veracrypt. The reason @idrassi doesn't put "Truecrypt mode" in the beginning of guess list, while trying to mount volume with cached passwword - he just doesn't have heavy usage experience of his product and isn't aware how many truecrypt-like volumes are still in job. Of course, in the future VC type containers will replace TC type containers. But cryptography is conservative. Also migration for ex. from wholedisk TC encrypted 1Tb notebook hdd to wholedisk VC encrypted 1Tb hdd is not an easy task: just installing fresh VC on top of old TC on already encrypted system disk can render system not bootable, and reliable way - whole decryption, tc uninstall, vc install and ecryption with multipass erasing is resource consuming task and unnecessary plain data expose - during migration process and because of additional traces of unencrypted data on hdd or sdd during secondary "encryption in place " of already filled with sensitive data disk. It is not about of just changing headers in place. As for now, truecrypt mount mode is disabled by default untill user explicitly sets the checkbox before trying to mount. And comparing time to make all iterations for VC container and TC container during mount tries there is no huge perfomance win because of skipping TC mode. In respect for existing users, still having a lot of TC volumes and little perfomance impact, TC mode should be in the beginning of sequence of algorithms during mount or at least a choice for few next years. And showing mount options dialog AFTER the mount procedure in the case of cached password is mistake.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because it has not had recent activity. This probably means that it is not reproducible or it has been fixed in a newer version. If it’s an enhancement and hasn’t been taken on for so long, then it seems no one has the time to implement this. Please reopen if you still encounter this issue with the latest stable version. You can also contribute directly by providing a pull request. Thank you!