Hello,
I tried to update a laptop from W10 1803 to W10 1809 second edition while the system disk is encrypted by VeraCrypt 1.23.
The upgrade failed at the first reboot. I tried twice and it failed twice.
So I prepared a new upgrade media on which I included the VeraCrypt drivers with the veracrypt-w10-patcher.cmd method. Then it worked perfectly.
So I suppose Microsoft discarded the ReflectDrivers method in this new W10 1809 second edition.
I thank you again for your good work !
Frédéric
Last edit: Elfeclair 2018-11-16
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have also come to the conclusion that the Windows 10 1809 upgrade
broken something in the reflectDrivers mechanism after many similar
upgrade issues were encountered.
Officially, nothing changed in Windows side with regards to
ReflectDrivers mechanism but at the same time it is clearly not working
reliably for VeraCrypt.
At this point, I'm unable to find the cause. The 1809 upgrade is the
worst upgrade released by Microsoft from quality point of view and it
would not surprise me if VeraCrypt is one of its collateral damage.
I will try in the coming days to give an in depth analysis of this issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was able to perform some tests today on different machines and I found
why the upgrade works on some machines but fails on others.
First, here is a quick explanation of how VeraCrypt implements support
for Windows Upgrade: when system is encrypted with VeraCrypt 1.23 or
when VeraCrypt 1.23 is installed on a previously encrypted system, we
create a file called SetupConfig.ini in the folder
"C:\Users\Default\AppData\Local\Microsoft\Windows\WSUS" and we write the
following content to it:
So, the next time Windows starts the upgrade process, it will read the
ReflectDrivers entry from
C:\Users\Default\AppData\Local\Microsoft\Windows\WSUS\SetupConfig.ini"
and thus it will include VeraCrypt in the Windows installation image.
After the upgrade process is finished, Windows installer will execute
the script pointed by the entry POSTOOBE in SetupConfig.ini which in
turn will call VeraCrypt with the /PostOOBE switch. The objective of
this call is to recreate the file SetupConfig.ini in
"C:\Users\Default\AppData\Local\Microsoft\Windows\WSUS" because the
upgrade process deletes it. This is important if we want next Windows
upgrade to work seamlessly.
Now that I explained the Windows upgrade logic, here is the cause of the
problem: the upgrade failure happens only on machines whose Windows was
already upgrade while being encrypted by VeraCrypt (e.g. from 1709 to
1803) and on these machines, the file
"C:\Users\Default\AppData\Local\Microsoft\Windows\WSUS\SetupConfig.ini"
is missing!
Without SetupConfig.ini file, the upgrade process will fail. The absence
of this file means that the PostOOBE command was not executed by the
Windows upgrade process which is surprising and totally unexpected.
So, the root caused of this issue is the fact that Windows upgrade
process doesn't honor the PostOOBE or it fails to run it for some reason.
Instead of loosing time trying to understand why PostOOBE entry of
SetupConfig.ini is not executed (on one machine, the log file
c:\Windows\Panther\UnattendGC\Setupact.log contains a line that reads
"no enterprise edition, will not run SetupComplete.cmd"), I will
implement a mechanism in VeraCrypt so that on each boot it will check
the existence and the content of the SetupConfig.ini file in order to
restore it if it is missing. I will try to publsh Hotfix-3 of 1.23 in
the coming days.
Meanwhile, in order to ensure a smooth Windows upgrade process, always
check that the file
"C:\Users\Default\AppData\Local\Microsoft\Windows\WSUS\SetupConfig.ini"
exists and that it has the content mentionned above. If not, create this
file and its parent folder if necessary and write the content described
above to it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Many thanks for the explanation above. I have applied the procedure above and my computer does not boot anymore (it even does not show the password prompt for veracrypt).
Some more details:
Couldn't update Windows 10 to version 1803 for months
Upgraded to VeraCrypt 1.23 in September
1803 installed correctly
This morning, tried to install 1809 update and failed
I read your post above, created the SetupConfig.ini and rerun the 1809 update. Computer restarted several times to about 55% update completion, then restarted and showed a green loading bar which completed, then restarted again and now is stuck: when powered, it shuts down after 5 seconds without prompting for the decryption password.
Laptop is a Lenovo ideapad 320
Any idea what happened and how to fix this?
Many thanks in advance for your help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is the first time I hear of such problem. Normally, either the
upgrade process doesn't start at all because of the lack of the ini file
containing ReflectDriversentry or the upgrade completes without issues.
In your case, the upgrade process stopped in the middle. At this stage,
I don't see how VeraCrypt can cause this since its driver was obviously
loaded successfully by Windows for several reboots.
The first thing to do is to check the content of the EFI system
partition by booting on a Linux live CD. Specifically, we are looking
for the content of the folders "EFI/Boot", 'EFI/VeraCrypt" and
"EFI/Microsoft/Boot". The files "EFI/Boot/bootx64.efi",
"EFI/VeraCrypt/DcsBoot.efi" and "EFI/Microsoft/Boot/bootmgfw.efi" should
be identical (size around 20KB) and "EFI/Windows/Boot/bootmgfw_ms.vc"
should be present and much larger (around 2MB).
Can you please report back the content of your EFI system partition?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Many thanks for your quick feedback. I made the investigations as indicated and here is the result:
"EFI/Boot/bootx64.efi", "EFI/VeraCrypt/DcsBoot.efi" : 22.8 kB
"EFI/Microsoft/Boot/bootmgfw.efi" 1.5 MB
"EFI/Windows/Boot/bootmgfw_ms.vc" 1.3 MB
So, bootmgfw.efi seems too big compared to your expectation.
Many thanks in advance for your help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for these details. So, the problem is that bootmgfw.efi was set
to original Windows value but it should have been restored using the
PostOOBE command of VeraCrypt that is specified in the ini file.
The fix for your problem is easy and it is done in two steps in the
following order:
- copy "EFI/Microsoft/Boot/bootmgfw.efi" to
"EFI/Windows/Boot/bootmgfw_ms.vc"
- copy "EFI/VeraCrypt/DcsBoot.efi" to "EFI/Microsoft/Boot/bootmgfw.efi"
After that reboot and you should get the password prompt as usual.
Does it work now?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I tried to update a laptop from W10 1803 to W10 1809 second edition while the system disk is encrypted by VeraCrypt 1.23.
The upgrade failed at the first reboot. I tried twice and it failed twice.
So I prepared a new upgrade media on which I included the VeraCrypt drivers with the veracrypt-w10-patcher.cmd method. Then it worked perfectly.
So I suppose Microsoft discarded the ReflectDrivers method in this new W10 1809 second edition.
I thank you again for your good work !
Frédéric
Last edit: Elfeclair 2018-11-16
Hi Frédéric,
Thank you for the feedback.
I have also come to the conclusion that the Windows 10 1809 upgrade
broken something in the reflectDrivers mechanism after many similar
upgrade issues were encountered.
Officially, nothing changed in Windows side with regards to
ReflectDrivers mechanism but at the same time it is clearly not working
reliably for VeraCrypt.
At this point, I'm unable to find the cause. The 1809 upgrade is the
worst upgrade released by Microsoft from quality point of view and it
would not surprise me if VeraCrypt is one of its collateral damage.
I will try in the coming days to give an in depth analysis of this issue.
I was able to perform some tests today on different machines and I found
why the upgrade works on some machines but fails on others.
First, here is a quick explanation of how VeraCrypt implements support
for Windows Upgrade: when system is encrypted with VeraCrypt 1.23 or
when VeraCrypt 1.23 is installed on a previously encrypted system, we
create a file called SetupConfig.ini in the folder
"C:\Users\Default\AppData\Local\Microsoft\Windows\WSUS" and we write the
following content to it:
And then we create a file called SetupComplete.cmd in the folder
"C:\ProgramData\VeraCrypt" and we write the following content to it:
So, the next time Windows starts the upgrade process, it will read the
ReflectDrivers entry from
C:\Users\Default\AppData\Local\Microsoft\Windows\WSUS\SetupConfig.ini"
and thus it will include VeraCrypt in the Windows installation image.
After the upgrade process is finished, Windows installer will execute
the script pointed by the entry POSTOOBE in SetupConfig.ini which in
turn will call VeraCrypt with the /PostOOBE switch. The objective of
this call is to recreate the file SetupConfig.ini in
"C:\Users\Default\AppData\Local\Microsoft\Windows\WSUS" because the
upgrade process deletes it. This is important if we want next Windows
upgrade to work seamlessly.
Now that I explained the Windows upgrade logic, here is the cause of the
problem: the upgrade failure happens only on machines whose Windows was
already upgrade while being encrypted by VeraCrypt (e.g. from 1709 to
1803) and on these machines, the file
"C:\Users\Default\AppData\Local\Microsoft\Windows\WSUS\SetupConfig.ini"
is missing!
Without SetupConfig.ini file, the upgrade process will fail. The absence
of this file means that the PostOOBE command was not executed by the
Windows upgrade process which is surprising and totally unexpected.
So, the root caused of this issue is the fact that Windows upgrade
process doesn't honor the PostOOBE or it fails to run it for some reason.
Instead of loosing time trying to understand why PostOOBE entry of
SetupConfig.ini is not executed (on one machine, the log file
c:\Windows\Panther\UnattendGC\Setupact.log contains a line that reads
"no enterprise edition, will not run SetupComplete.cmd"), I will
implement a mechanism in VeraCrypt so that on each boot it will check
the existence and the content of the SetupConfig.ini file in order to
restore it if it is missing. I will try to publsh Hotfix-3 of 1.23 in
the coming days.
Meanwhile, in order to ensure a smooth Windows upgrade process, always
check that the file
"C:\Users\Default\AppData\Local\Microsoft\Windows\WSUS\SetupConfig.ini"
exists and that it has the content mentionned above. If not, create this
file and its parent folder if necessary and write the content described
above to it.
Dear Mounir,
Many thanks for the explanation above. I have applied the procedure above and my computer does not boot anymore (it even does not show the password prompt for veracrypt).
Some more details:
Couldn't update Windows 10 to version 1803 for months
Upgraded to VeraCrypt 1.23 in September
1803 installed correctly
This morning, tried to install 1809 update and failed
I read your post above, created the SetupConfig.ini and rerun the 1809 update. Computer restarted several times to about 55% update completion, then restarted and showed a green loading bar which completed, then restarted again and now is stuck: when powered, it shuts down after 5 seconds without prompting for the decryption password.
Laptop is a Lenovo ideapad 320
Any idea what happened and how to fix this?
Many thanks in advance for your help.
Hi Xavier,
This is the first time I hear of such problem. Normally, either the
upgrade process doesn't start at all because of the lack of the ini file
containing ReflectDriversentry or the upgrade completes without issues.
In your case, the upgrade process stopped in the middle. At this stage,
I don't see how VeraCrypt can cause this since its driver was obviously
loaded successfully by Windows for several reboots.
The first thing to do is to check the content of the EFI system
partition by booting on a Linux live CD. Specifically, we are looking
for the content of the folders "EFI/Boot", 'EFI/VeraCrypt" and
"EFI/Microsoft/Boot". The files "EFI/Boot/bootx64.efi",
"EFI/VeraCrypt/DcsBoot.efi" and "EFI/Microsoft/Boot/bootmgfw.efi" should
be identical (size around 20KB) and "EFI/Windows/Boot/bootmgfw_ms.vc"
should be present and much larger (around 2MB).
Can you please report back the content of your EFI system partition?
Dear Mounir,
Many thanks for your quick feedback. I made the investigations as indicated and here is the result:
"EFI/Boot/bootx64.efi", "EFI/VeraCrypt/DcsBoot.efi" : 22.8 kB
"EFI/Microsoft/Boot/bootmgfw.efi" 1.5 MB
"EFI/Windows/Boot/bootmgfw_ms.vc" 1.3 MB
So, bootmgfw.efi seems too big compared to your expectation.
Many thanks in advance for your help.
Hi Xavier,
Thanks for these details. So, the problem is that bootmgfw.efi was set
to original Windows value but it should have been restored using the
PostOOBE command of VeraCrypt that is specified in the ini file.
The fix for your problem is easy and it is done in two steps in the
following order:
- copy "EFI/Microsoft/Boot/bootmgfw.efi" to
"EFI/Windows/Boot/bootmgfw_ms.vc"
- copy "EFI/VeraCrypt/DcsBoot.efi" to "EFI/Microsoft/Boot/bootmgfw.efi"
After that reboot and you should get the password prompt as usual.
Does it work now?
Dear Mounir,
You're great, it worked perfectly, 1809 has installed. Than you so much!