Hi everybody
on UEFI systems because discrepancies of some systems with specifications witch can lead to repair loops
Veracrypt must modify files in \EFI\Windows\Boot directory
1) rename Windows boot loader bootmgfw.efi bootmgfw_ms.vc
2) rename a copy of DcsBoot.efi bootmgfw.efi
So even original windows boot entry is selected DcsBoot is started , mont system on C: then start copy of original bootmgfw.efi
Good but there is a big problem for example cumulative update KB4345421 bring new release of bootmgfw.efi after applying it original new windows boot loader is directly invoked leading to repair loop
the only work around is:
boot with usb key of install windows or any Windows PE and enter command line
then
mountvol b: /s
b:
cd EFI
ren Windows\Boot\bootmgfw.efi \Windows\Boot\bootmgfw_ms.vc
copy VeraCrypt\DcsBoot.efi \Windows\Boot\bootmgfw.efi
copy VeraCrypt\DcsBoot.efi \Boot\bootx64.efi
x:
mountvol b: /d
then reboot
Best regards
PS
i don't now when Windows update make change of bootmgfw.efi it's either before firts phase before reboot or second one after reboot
if it is after above probleme does not arise but you must make this
mountvol b: /s
b:
cd EFI
ren Windows\Boot\bootmgfw.efi Windows\Boot\bootmgfw_ms.vc
copy VeraCrypt\DcsBoot.efi windows\Boot\bootmgfw.efi
c:
mountvol b: /d
if you don't make this after reboot pre boot is good but system remain suspended because bootmgfw_ms.vc is not found
Last edit: petitlou60 2018-08-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Mounir
In place of using bootmgfw_ms.vc why not :
1) Make DcsBoot.efi starting bootmgfw.efi (original one)
2) bcdedit /set {bootmgr} path \EFI\VeraCrypt\Dcsboot.efi
So no need of rename and if bootmgfw.efi is simply updated no problem
and some times above bcdedit command is ok
Best regards
Last edit: petitlou60 2018-08-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
HI Alex, Mounir,
OK but with bcdedit you can easily force bad behavior systems, which attempt to boot with windows EFI Entry, to start DcsBoot.efi.
the advantage of this is to avoid to use copy of bootmgfw.efi which can become obsolete after Windows Update and start updated Windows with old boot manger can lead to strange results or bugs
This is only an suggest and i understand that you are very busy with this project
Thank you for your implication
Best regards
Last edit: petitlou60 2018-08-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As explained by Alex, we were using the standard (and clean) way to register VeraCrypt bootloader in 1.22 but it tuned out that many manufactuters (like HP) force the machine to boot only on bootmgfw.efi and so it was impossible to encrypt these machines.
After many efforts and trials but Alex and me, I finally decided to go for the renaming of bootmgfw.efi and copying dcsboot.efi as bootmgfw.efi. This is the only way to enable users to encrypt there machines from affected manufacturers like HP or Acer.
Concerning the issue with bootloader being overwritten by updates like KB4345421, I have already implemented in 1.23-BETA a mechanism based on /ReflectDrivers and /PostOOBE of Windows setup in order to be compatible with Windows major upgrades like Fall Creators and I think I can reuse the PostOOBE mechanism to ensure that bootmgfw_ms.vc is updated and that bootmgfw.efi is always a copy of dcsboot.efi.
I will try to implement this in the coming days.
Is it possible for you to help in testing this?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Mounir
As you know i have a strange bug in my Asus X75VC: secure boot failure with installed DCS keys in firmware.
So to encrypt my system i must disable secure boot!
But i can make some tests like:
see if bootmgfw.efi remain a copy o DcsBoot.efi and bootmgfw_ms.vc correctly updated
after applying any Windows Update which impact bootmgfw.efi file
Or test veracrypt driver if you attempt to increase i/o performance
Best Regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do you confirm that you performed system encryption with 1.23-BETA2 and then you installed KB4345421 and after that Windows boot directly to Repair mode?
I want to know if you actually encountered the problem or if it was just a question since you didn't know that VeraCrypt has implemented this mechanism?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you petitloup60 for the clarification.
As I said above, the PostOOBE mechanism implemented in 1.23-BETA2 should take care of the update of bootmgfw.efi and actully I have a Window 10 machine that was encrypted with 1.23-BETA1 last May and since then many Windows updates were installed and there was never a problem.
For now, it looks that things are good but if anyone encounters an issue with Windows updates, please report it so that I can analyze it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Mounir. We have this issue (still) with HP laptops. We installed around 10 of them and most have this issue. When this happens, we ask users to press F9 and manually select DcsBoot.efi. After that they can boot into Windows. Remotely we copy o:\EFI\VeraCrypt\DcsBoot.efi o:\EFI\Microsoft\Boot\Bootmgfw.efi
in \EFI\VeraCrypt\DcsProp but I'm not sure what this does. It works fine without it too.
It just happend to me again (after Windows Updates) and I was/am running version 1.23 Hotfix 2 (October 8, 2018).
Please can you help us with this? At least I want to know what the status is of this problem. There have to be other HP users with the same problem, but I can hardly find any information about this on the forums. The threads seem old, but if it is fixed, why does it still happen? Are we doing somehing wrong?
Thanks for your support.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As I have mentioned in another post 2 days ago, I'm working on a new
approach in VeraCrypt to solve all remaining issues as one can see in
Git repository history. This is the highest priority for 1.24 version
because of the large number of users affected by this.
The current implementation looks good as per my tests and I'm waiting
for Microsoft signature of the EFI bootloader in order to publish
1.24-Beta1 that contains these changes (hopeful I will receive it by the
end of next week).
As for your procedure, you don't need to insert the line in the config
file. Just copying DcsBoot.efi to ootmgfw.efi is enough but it is better
first to copy this new version of Bootmgfw.efi to bootmgfw_ms.vc and
then copy DcsBoot.efi to ootmgfw.efi. The tool VcFixBoot implement a
more complex logic to handle all possible cases and to ensure the
coherance of all files (including ones at "EFI\Boot").
Voilà voilà...I hope this clarifies the situation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Robert for the feedback. I have implemented silent mode in VcFixBoot by specifying /silent as argument to VcFixBoot.exe. You can download the new version using the same link as above.
For testing, I can share a build of 1.24-Beta1 that include 1.24-Beta1 bootloader signed by VeraCrypt custom SecureBoot key but this require either loading our key into EFI firmware using the PowerShell script I already published or disabling SecureBoot. Is this OK for you?
Thank you for your help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Mounir, yes that's fine. I will disable SecureBoot. I'm not sure if there is an easy way to simulate these Windows Updates. Obviously I can reinstall Windows and apply updates again, or restore an older image, but there might be easier solutions? Maybe if I run the bootrec /fixboot command, it will do the same thing as a normal Windows Update does?
Last edit: Robert Haerkens 2019-01-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have uploaded installers for 1.24-Beta1 that implement the new mechanism alongside other changes. You can find them in the Nightly Builds folder.
There are two types of installer: normal one (which comes included old 1.23 EFI bootloader since the EFI bootloader has not been signed yet) and the one named "CustomEFI" which includes 1.24 EFI bootloader signed by our custom SecureBoot key. Using the normal installer on an encrypted EFI system will cause warnings about wrong bootloader version to be displayed on logon.
Concerning bootrec idea, I don't think it can be run from within Windows so it can not replicate Windows Update behavior. If you run bootrec from the recovery environment, then VeraCrypt can not do anything. Testing using real update is the only real way to test this mechanism.
Thank you for your help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had tried this new VeraCrypt Setup 1.24-Beta2.exe on an HP Pavilion with Win10 Home. It will consistently prompt to reboot for updates and then go back into the boot loop. Did I pick the wrong version which fixes the HP issue?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Kelly. I too am running the Beta version on HP without problems, but I'm still on Beta 1.
At the time of Beta 1 you could chose between the 'Normal' version and a new 'CustomEFI' version. I selected the Normal version but my collegeau the 'CustomEFI' version. He too kept problems and switched to the 'Normal' version. The 'Normal' version prompt with a warning after login by the way, but this is known and due to the fact that it's bootloader is not correct signed.
I notice that in the current download there is no 'Normal' vs 'CustomEFI' version anymore. Maybe the only version is 'CustomEFI' now? And maybe that one is still 'faulty'? Maybe you can go back to Beta 1? Or maybe just wait for a comment from someone like Mounir with more inside knowledge.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@kellyahlers: can you please give an update about your issue? Does windows goes to repair mode after installing updates?
Since version 1.24-Beta2 there is only one installer since VeraCrypt bootloader was signed by Microsoft. You can try the latest Beta to be sure to have all the fixes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately it still boots back to the startup recovery. Did I miss a step where I needed to install the certificates into the HP bios or turn off secure boot? It still has shutdown & restart or update & restart as options then it goes back to the boot loop.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is no special step to do.
In HP machines, you can always boot VeraCrypt manually but pressing F9 right after powering on the PC and then select menu "Boot from EFI file": from there browse using ENTER and arrow keys to the folder "EFI\VeraCrypt" and choose the file DcsBoot.efi. Afterwards, you will see the usual VeraCrypt password prompt and Windows will load Normally. After rebooting Windows, you will not need to do this again since VeraCrypt will automatically repair the boot once Windows is loaded.
Does this fix you problem?
Anyway, it looks like Windows is still erasing VeraCrypt bootloader even with the new mechanism I implemented in VeraCrypt. I will have to work further on this to see if I can solve it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Today we found something interesting. My colleague didn't have any issues with 1.24Beta5. We compared everything in the BIOS (secure boot, etc.) and installed and remove KB4489899 time after time. It kept working on his exactly equal laptop, and it kept going wrong on mine.
Hi everybody
on UEFI systems because discrepancies of some systems with specifications witch can lead to repair loops
Veracrypt must modify files in \EFI\Windows\Boot directory
1) rename Windows boot loader bootmgfw.efi bootmgfw_ms.vc
2) rename a copy of DcsBoot.efi bootmgfw.efi
So even original windows boot entry is selected DcsBoot is started , mont system on C: then start copy of original bootmgfw.efi
Good but there is a big problem for example cumulative update KB4345421 bring new release of bootmgfw.efi after applying it original new windows boot loader is directly invoked leading to repair loop
the only work around is:
boot with usb key of install windows or any Windows PE and enter command line
then
mountvol b: /s
b:
cd EFI
ren Windows\Boot\bootmgfw.efi \Windows\Boot\bootmgfw_ms.vc
copy VeraCrypt\DcsBoot.efi \Windows\Boot\bootmgfw.efi
copy VeraCrypt\DcsBoot.efi \Boot\bootx64.efi
x:
mountvol b: /d
then reboot
Best regards
PS
i don't now when Windows update make change of bootmgfw.efi it's either before firts phase before reboot or second one after reboot
if it is after above probleme does not arise but you must make this
mountvol b: /s
b:
cd EFI
ren Windows\Boot\bootmgfw.efi Windows\Boot\bootmgfw_ms.vc
copy VeraCrypt\DcsBoot.efi windows\Boot\bootmgfw.efi
c:
mountvol b: /d
if you don't make this after reboot pre boot is good but system remain suspended because bootmgfw_ms.vc is not found
Last edit: petitlou60 2018-08-03
Hi Mounir
In place of using bootmgfw_ms.vc why not :
1) Make DcsBoot.efi starting bootmgfw.efi (original one)
2) bcdedit /set {bootmgr} path \EFI\VeraCrypt\Dcsboot.efi
So no need of rename and if bootmgfw.efi is simply updated no problem
and some times above bcdedit command is ok
Best regards
Last edit: petitlou60 2018-08-03
Hi petitlou60,
Source of the problem - EFI in some notebook do not work according to spec. I suggest solution (temporary).
https://sourceforge.net/p/veracrypt/discussion/technical/thread/d2987c18/#5098
Unfortunately better way was not found. Mounir decided to integrate the solution in BETA2 (to test). Probably this solution has to be optional.
HI Alex, Mounir,
OK but with bcdedit you can easily force bad behavior systems, which attempt to boot with windows EFI Entry, to start DcsBoot.efi.
the advantage of this is to avoid to use copy of bootmgfw.efi which can become obsolete after Windows Update and start updated Windows with old boot manger can lead to strange results or bugs
This is only an suggest and i understand that you are very busy with this project
Thank you for your implication
Best regards
Last edit: petitlou60 2018-08-03
As explained by Alex, we were using the standard (and clean) way to register VeraCrypt bootloader in 1.22 but it tuned out that many manufactuters (like HP) force the machine to boot only on bootmgfw.efi and so it was impossible to encrypt these machines.
After many efforts and trials but Alex and me, I finally decided to go for the renaming of bootmgfw.efi and copying dcsboot.efi as bootmgfw.efi. This is the only way to enable users to encrypt there machines from affected manufacturers like HP or Acer.
Concerning the issue with bootloader being overwritten by updates like KB4345421, I have already implemented in 1.23-BETA a mechanism based on /ReflectDrivers and /PostOOBE of Windows setup in order to be compatible with Windows major upgrades like Fall Creators and I think I can reuse the PostOOBE mechanism to ensure that bootmgfw_ms.vc is updated and that bootmgfw.efi is always a copy of dcsboot.efi.
I will try to implement this in the coming days.
Is it possible for you to help in testing this?
Hi Mounir
As you know i have a strange bug in my Asus X75VC: secure boot failure with installed DCS keys in firmware.
So to encrypt my system i must disable secure boot!
But i can make some tests like:
see if bootmgfw.efi remain a copy o DcsBoot.efi and bootmgfw_ms.vc correctly updated
after applying any Windows Update which impact bootmgfw.efi file
Or test veracrypt driver if you attempt to increase i/o performance
Best Regards
Actually, I have already implemented the mechanism to handle the update of bootmgfw.efi in 1.23-BETA2 so you there should be no problem if an update create new copy of bootmgfw.efi. The code is here: https://sourceforge.net/p/veracrypt/code/ci/master/tree/src/Mount/Mount.c#l9392 and https://sourceforge.net/p/veracrypt/code/ci/master/tree/src/Common/BootEncryption.cpp#l3167.
Do you confirm that you performed system encryption with 1.23-BETA2 and then you installed KB4345421 and after that Windows boot directly to Repair mode?
I want to know if you actually encountered the problem or if it was just a question since you didn't know that VeraCrypt has implemented this mechanism?
Hi Mounir
I have only start a question because i have think of problem of Windows Update of bootmgfw.efi
Best regards
Thank you petitloup60 for the clarification.
As I said above, the PostOOBE mechanism implemented in 1.23-BETA2 should take care of the update of bootmgfw.efi and actully I have a Window 10 machine that was encrypted with 1.23-BETA1 last May and since then many Windows updates were installed and there was never a problem.
For now, it looks that things are good but if anyone encounters an issue with Windows updates, please report it so that I can analyze it.
Hi Mounir. We have this issue (still) with HP laptops. We installed around 10 of them and most have this issue. When this happens, we ask users to press F9 and manually select DcsBoot.efi. After that they can boot into Windows. Remotely we
copy o:\EFI\VeraCrypt\DcsBoot.efi o:\EFI\Microsoft\Boot\Bootmgfw.efi
We also insert the line
in
\EFI\VeraCrypt\DcsProp
but I'm not sure what this does. It works fine without it too.It just happend to me again (after Windows Updates) and I was/am running version 1.23 Hotfix 2 (October 8, 2018).
Please can you help us with this? At least I want to know what the status is of this problem. There have to be other HP users with the same problem, but I can hardly find any information about this on the forums. The threads seem old, but if it is fixed, why does it still happen? Are we doing somehing wrong?
Thanks for your support.
As I have mentioned in another post 2 days ago, I'm working on a new
approach in VeraCrypt to solve all remaining issues as one can see in
Git repository history. This is the highest priority for 1.24 version
because of the large number of users affected by this.
The current implementation looks good as per my tests and I'm waiting
for Microsoft signature of the EFI bootloader in order to publish
1.24-Beta1 that contains these changes (hopeful I will receive it by the
end of next week).
Meanwhile, I have published a GUI tool called VcFixBoot that enables to
fix the boot issues when it happens so you users can run this tool after
booting into windows using F9 key and afterwards the machine will boot
normally. This tool is available at
https://sourceforge.net/projects/veracrypt/files/Contributions/VcFixBoot.zip/download
(its PGP signature is at
https://sourceforge.net/projects/veracrypt/files/Contributions/VcFixBoot.zip.sig/download).
I'm planning to implement a command line version of this tool in the future.
As for your procedure, you don't need to insert the line in the config
file. Just copying DcsBoot.efi to ootmgfw.efi is enough but it is better
first to copy this new version of Bootmgfw.efi to bootmgfw_ms.vc and
then copy DcsBoot.efi to ootmgfw.efi. The tool VcFixBoot implement a
more complex logic to handle all possible cases and to ensure the
coherance of all files (including ones at "EFI\Boot").
Voilà voilà...I hope this clarifies the situation.
Thanks Mounir, this helps a lot. If I can help you in any way (e.g. testing), please let me know.
Thanks Robert for the feedback. I have implemented silent mode in VcFixBoot by specifying
/silent
as argument to VcFixBoot.exe. You can download the new version using the same link as above.For testing, I can share a build of 1.24-Beta1 that include 1.24-Beta1 bootloader signed by VeraCrypt custom SecureBoot key but this require either loading our key into EFI firmware using the PowerShell script I already published or disabling SecureBoot. Is this OK for you?
Thank you for your help.
Hi Mounir, yes that's fine. I will disable SecureBoot. I'm not sure if there is an easy way to simulate these Windows Updates. Obviously I can reinstall Windows and apply updates again, or restore an older image, but there might be easier solutions? Maybe if I run the bootrec /fixboot command, it will do the same thing as a normal Windows Update does?
Last edit: Robert Haerkens 2019-01-19
I have uploaded installers for 1.24-Beta1 that implement the new mechanism alongside other changes. You can find them in the Nightly Builds folder.
There are two types of installer: normal one (which comes included old 1.23 EFI bootloader since the EFI bootloader has not been signed yet) and the one named "CustomEFI" which includes 1.24 EFI bootloader signed by our custom SecureBoot key. Using the normal installer on an encrypted EFI system will cause warnings about wrong bootloader version to be displayed on logon.
Concerning bootrec idea, I don't think it can be run from within Windows so it can not replicate Windows Update behavior. If you run bootrec from the recovery environment, then VeraCrypt can not do anything. Testing using real update is the only real way to test this mechanism.
Thank you for your help.
Thanks. I'm now running and testing 1.24-Beta1 (normal) on a HP Laptop 14-ck0xxx
I had tried this new VeraCrypt Setup 1.24-Beta2.exe on an HP Pavilion with Win10 Home. It will consistently prompt to reboot for updates and then go back into the boot loop. Did I pick the wrong version which fixes the HP issue?
Hi Kelly. I too am running the Beta version on HP without problems, but I'm still on Beta 1.
At the time of Beta 1 you could chose between the 'Normal' version and a new 'CustomEFI' version. I selected the Normal version but my collegeau the 'CustomEFI' version. He too kept problems and switched to the 'Normal' version. The 'Normal' version prompt with a warning after login by the way, but this is known and due to the fact that it's bootloader is not correct signed.
I notice that in the current download there is no 'Normal' vs 'CustomEFI' version anymore. Maybe the only version is 'CustomEFI' now? And maybe that one is still 'faulty'? Maybe you can go back to Beta 1? Or maybe just wait for a comment from someone like Mounir with more inside knowledge.
Thanks for the info! Is there any chance to get at this file? If not, I'll wait to hear from Mounir as to current progress.
@kellyahlers: can you please give an update about your issue? Does windows goes to repair mode after installing updates?
Since version 1.24-Beta2 there is only one installer since VeraCrypt bootloader was signed by Microsoft. You can try the latest Beta to be sure to have all the fixes.
Unfortunately it still boots back to the startup recovery. Did I miss a step where I needed to install the certificates into the HP bios or turn off secure boot? It still has shutdown & restart or update & restart as options then it goes back to the boot loop.
There is no special step to do.
In HP machines, you can always boot VeraCrypt manually but pressing F9 right after powering on the PC and then select menu "Boot from EFI file": from there browse using ENTER and arrow keys to the folder "EFI\VeraCrypt" and choose the file DcsBoot.efi. Afterwards, you will see the usual VeraCrypt password prompt and Windows will load Normally. After rebooting Windows, you will not need to do this again since VeraCrypt will automatically repair the boot once Windows is loaded.
Does this fix you problem?
Anyway, it looks like Windows is still erasing VeraCrypt bootloader even with the new mechanism I implemented in VeraCrypt. I will have to work further on this to see if I can solve it.
Hi Mounir,
Today we found something interesting. My colleague didn't have any issues with 1.24Beta5. We compared everything in the BIOS (secure boot, etc.) and installed and remove KB4489899 time after time. It kept working on his exactly equal laptop, and it kept going wrong on mine.
They only difference we knew was that I did a clean install of 1.24Beta5 and he did an upgrade from 1.24Beta2 (the one with CustomEFI vs Normal, see https://sourceforge.net/p/veracrypt/discussion/technical/thread/e1b55ec1/#6d2c).
So finally he uninstalled VeraCrypt 1.24Beta2, installed 1.24Beta5 and removed KB4489899, and bang.... "auto repair" started.
Unfortunately this is on a client's machine. I have given them the workaround but it's not ideal.
I'll keep following the thread to see if there are any new updates.
We have the same problem and have placed the work-around on our website: http://support.code54.nl/en/support/solutions/articles/4000135899-laptop-with-veracrypt-installed-doesn-t-start-after-windows-update . We advice clients to print it and keep a copy with their laptop. I have to say that I haven't experienced any problems on my own laptop (still running Beta 1). Hopefully it gets solved soon. I would like to thank the deverlopers for their effort.