I was still having issues with freezes on 1.26.17 due to low memory on partition encryption on Windows 10. Does this latest version address these issues? I am running 22H2 version of Windows.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@goldengate2032: There is no change with regards to the freeze issue between 1.26.17 and 1.26.18. That's why I didn't post any update to the freeze related thread.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2025-01-22
I currently have VeraCrypt 1.26.15 and have encrypted the entire disk and have no problems.
Windows 10 1903 MBR
Overall I have never had any problems with my computer freezing and I only have 4GB of RAM
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You can only select the system encryption option "Encrypt the whole drive" if the drive is using MBR which is the old Windows method verses the Windows preferred method UEFI with GPT.
If your system is using MBR, that means in the PC BIOS settings is set to boot in Legacy BIOS mode.
On UEFI systems, your only VeraCrypt system encryption option available is the "Encrypt the Windows partition" and the other option "Encrypt the whole drive" is greyed-out.
You can check your system by clicking on the Windows Start icon and type system information. Look for the entry called "BIOS Mode". The value of "UEFI" is the newer method and therefore the only option you can select in VeraCrypt is the "Encrypt the Windows partition" option.
For UEFI systems, VeraCrypt must not encrypt the system partitions for the EFI, MSR, Recovery Tools nor the Recovery Image partitions. The Recovery Image partition is an optional setup in Windows OS.
EDIT:
The MBR vs UEFI and the subsequent system encryption options is not new to the 1.26.18 version.
Please create a new topic in the Technical section if you need to continue this discussion.
Last edit: Enigma2Illusion 2025-01-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the Source Code > History section, you can review the code change comment and you can read the comments within the changed source code to get more details.
hello,
i have a problem with veracrypt background task
my system is not crypted, but all my personal data is in veracrypt partition container
At startup a scheduled task start mount of this container with secure desktop option
this is always succesfull
Problem occurs at first attempt to mount another container
mount occurs but veracrypt background task fails with différent code (see attachement)
i need to restart background task
after all mount attempts are succesfull without problem
Yes it is a specific 1.26.18 problem
first mount of my data container is started by a schéduled task
other mount occurs when i connect USB disk or USBKey
I noticed on my Win10 22H2 Pro the Windows OS volume mounts both manually and using Favorites Hot Key a delay before I get the volume mount prompt screen using the 1.26.18 version. I use Secure Desktop setting.
I see in the release notes for Linux & MacOS:
Ensure that volume exists before starting the mount operation.
Is Windows also included using this method?
If yes, the 1.26.18 release notes for future reference should be changed to:
All OSes:
Ensure that volume exists before starting the mount operation.
.
And the removal from the Linux & MacOS notes:
Ensure that volume exists before starting the mount operation.
.
Thank you for your hard work!
Last edit: Enigma2Illusion 2025-01-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
file Data.Axml can be directly imported in task cheduler
my data container is the only favorite mounted by shortcut or with /a favorites (see first command)
command to stop wsearch service (wsearch restart automaticaly after) refresh indexer service
so my A:\ container is now indexed by windows
last command start veracrypt background task
After a lot of tests
i see that source of problem is secure desktop
with secure desktop
fist mount OK
second mount OK but background task fail
third & + ok
without secure desktop no problem
best regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@petitlou60: Thank you for the report. This appears to be a crash in VeraCrypt when the background task is run with admin rights by the task scheduler. When a second mount occurs, a notification is sent to the background task, and it seems this is what causes the crash. Afterward, the VeraCrypt background task is started with normal rights, so the issue doesn't happen in that case.
I will try to reproduce this issue to debug it. It's important because a crash should never occur.
@enigma2illusion: Thank you for reporting this as well. I didn't add volume existence validation to Windows, so that isn't the cause. Since you're using Secure Desktop, I suspect the random generator might be responsible. Secure Desktop logic uses the random generator to create a random desktop name, and it seems the initialization of the random generator is taking longer than before.
As indicated in the release notes, I have changed the implementation to use modern APIs for gathering better system entropy, including network statistics. I believe these new entropy sources require more time for initialization.
To confirm this, could you please try running it without Secure Desktop enabled?
On my side, I don't notice any lag, but I also haven't performed any precise measurements. It might depend on your system configuration.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For each test with Secure Desktop enabled, I had to reboot my PC to get the ~2 second delay with a brief popup box with the green scrolling indicator showing something about this can take a long time before I received the login box. I was unable to screen snip the popup box.
The reboot is required due to it appears that the stats are cached and subsequent mount delays without rebooting the PC is very brief occurring in 1/4 of a second with a flicker of the popup box showing before I received the login box for both Secure Desktop enabled or disabled.
Before I began testing and rebooting my PC, I had been using my PC all day and subsequent mounting with Secure Desktop enabled was 1/4 of a second with a flicker of the popup box showing before I received the login box. Thus, I conclude the stats are only gathered once for the first time Secure Desktop is used instead of each time.
I would have expected all subsequent mounts with Secure Desktop enabled without rebooting the PC to gather new stats giving the same ~2 second delay and the popup box with the green scrolling indicator showing something about this can take a long time before I received the login box.. This does not happen.
This morning due other testing unrelated to mount delay, I downgraded to 1.26.15 and there was no delay for using VeraCrypt Hot Key for mounting my Favorites and with Secure Desktop enabled on my PC before I received the login box.
.
Given your explanation, I am willing to accept the ~2 second delay if it provides greater security.
Per my original post, I thought the delay was checking for the existence of my volumes and it was an documentation error.
Can you expand on your explanation if the caching of stats for Secure Desktop needs to be per Secure Desktop session mounting or is once is enough? Please consider that some users do not reboot/shutdown their PCs daily.
By Secure Desktop session, I mean in the case the user is using their Favorites to mount multiple volumes during the same Secure Desktop session. Hence, you only collect stats once for this multiple mount session.
Kind Regards,
Enigma2Illusion
EDITED to correct my results, add clarity and fix typos.
Last edit: Enigma2Illusion 2025-01-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My external HDDS VeraCrypt encrypted partitions do not show-up in my Windows 10 OS Build 19045.5371 version. Only the non-encrypted partitions are showing in my Optimize Drives which are scheduled via Windows to defragment.
Therefore, your drive letters D and E appear to be the unencrypted partitions.
Please provide a screenshot of your Disk Management showing the drive partitions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Version 1.26 and newer VeraCrypt versions have deprecated the following features:
.
See the documentation below for remediation procedures.
Conversion Guide for VeraCrypt 1.26 and Later
Update on bumping minimum Windows version requirements for VeraCrypt
MacOS users must skip 1.26.18 and use 1.26.20.
https://sourceforge.net/projects/veracrypt/files/VeraCrypt%201.26.18/
Changes between 1.26.15 and 1.26.18 (20 January 2025):
Last edit: Enigma2Illusion 2025-02-04
I was still having issues with freezes on 1.26.17 due to low memory on partition encryption on Windows 10. Does this latest version address these issues? I am running 22H2 version of Windows.
Download and let us know
If they didn't do any work on it, there is no need to download as it is a risk that I could corrupt my system hence the reason I ask.
@goldengate2032: There is no change with regards to the freeze issue between 1.26.17 and 1.26.18. That's why I didn't post any update to the freeze related thread.
I currently have VeraCrypt 1.26.15 and have encrypted the entire disk and have no problems.
Windows 10 1903 MBR
Overall I have never had any problems with my computer freezing and I only have 4GB of RAM
The option for full disk encryption is grayed out
@mytroika
You can only select the system encryption option "Encrypt the whole drive" if the drive is using MBR which is the old Windows method verses the Windows preferred method UEFI with GPT.
If your system is using MBR, that means in the PC BIOS settings is set to boot in Legacy BIOS mode.
On UEFI systems, your only VeraCrypt system encryption option available is the "Encrypt the Windows partition" and the other option "Encrypt the whole drive" is greyed-out.
You can check your system by clicking on the Windows Start icon and type system information. Look for the entry called "BIOS Mode". The value of "UEFI" is the newer method and therefore the only option you can select in VeraCrypt is the "Encrypt the Windows partition" option.
For UEFI systems, VeraCrypt must not encrypt the system partitions for the EFI, MSR, Recovery Tools nor the Recovery Image partitions. The Recovery Image partition is an optional setup in Windows OS.
EDIT:
The MBR vs UEFI and the subsequent system encryption options is not new to the 1.26.18 version.
Please create a new topic in the Technical section if you need to continue this discussion.
Last edit: Enigma2Illusion 2025-01-23
Just for my own curiosity, this comment;
refers to using Crypto NG instead of the older CryptoAPI?
@captain150
In the Source Code > History section, you can review the code change comment and you can read the comments within the changed source code to get more details.
https://sourceforge.net/p/veracrypt/code/ci/ce7d35d4f152db7a0aa949c564eb8f5e03cde88d/
Last edit: Enigma2Illusion 2025-01-23
hello,
i have a problem with veracrypt background task
my system is not crypted, but all my personal data is in veracrypt partition container
At startup a scheduled task start mount of this container with secure desktop option
this is always succesfull
Problem occurs at first attempt to mount another container
mount occurs but veracrypt background task fails with différent code (see attachement)
i need to restart background task
after all mount attempts are succesfull without problem
Last edit: petitlou60 2025-01-27
Did this problem only occur in 1.26.18?
Did it work in 1.26.15?
If this is not directly caused by the new 1.26.18 version, please open a new topic in the Technical section and include your script.
Yes it is a specific 1.26.18 problem
first mount of my data container is started by a schéduled task
other mount occurs when i connect USB disk or USBKey
I noticed you made changes to the script from your previous posting located below:
https://sourceforge.net/p/veracrypt/discussion/general/thread/95aba7b1a2/?page=1&limit=25#7c42
Maybe try the old version?
Not sure how you are calling the XML file in the Windows Scheduler.
@idrassi
I noticed on my Win10 22H2 Pro the Windows OS volume mounts both manually and using Favorites Hot Key a delay before I get the volume mount prompt screen using the 1.26.18 version. I use Secure Desktop setting.
I see in the release notes for Linux & MacOS:
Is Windows also included using this method?
If yes, the 1.26.18 release notes for future reference should be changed to:
All OSes:
.
And the removal from the Linux & MacOS notes:
.
Thank you for your hard work!
Last edit: Enigma2Illusion 2025-01-27
file Data.Axml can be directly imported in task cheduler
my data container is the only favorite mounted by shortcut or with /a favorites (see first command)
command to stop wsearch service (wsearch restart automaticaly after) refresh indexer service
so my A:\ container is now indexed by windows
last command start veracrypt background task
Last edit: petitlou60 2025-01-27
After a lot of tests
i see that source of problem is secure desktop
with secure desktop
fist mount OK
second mount OK but background task fail
third & + ok
without secure desktop no problem
best regards
Which version of Windows OS are you running on your PC? For example Windows 10 22H2 64-bit with latest Microsoft monthly patches.
Last edit: Enigma2Illusion 2025-01-27
@petitlou60: Thank you for the report. This appears to be a crash in VeraCrypt when the background task is run with admin rights by the task scheduler. When a second mount occurs, a notification is sent to the background task, and it seems this is what causes the crash. Afterward, the VeraCrypt background task is started with normal rights, so the issue doesn't happen in that case.
I will try to reproduce this issue to debug it. It's important because a crash should never occur.
@enigma2illusion: Thank you for reporting this as well. I didn't add volume existence validation to Windows, so that isn't the cause. Since you're using Secure Desktop, I suspect the random generator might be responsible. Secure Desktop logic uses the random generator to create a random desktop name, and it seems the initialization of the random generator is taking longer than before.
As indicated in the release notes, I have changed the implementation to use modern APIs for gathering better system entropy, including network statistics. I believe these new entropy sources require more time for initialization.
To confirm this, could you please try running it without Secure Desktop enabled?
On my side, I don't notice any lag, but I also haven't performed any precise measurements. It might depend on your system configuration.
Hi @idrassi
Results of Tests
For each test with Secure Desktop enabled, I had to reboot my PC to get the ~2 second delay with a brief popup box with the green scrolling indicator showing something about this can take a long time before I received the login box. I was unable to screen snip the popup box.
The reboot is required due to it appears that the stats are cached and subsequent mount delays without rebooting the PC is very brief occurring in 1/4 of a second with a flicker of the popup box showing before I received the login box for both Secure Desktop enabled or disabled.
Before I began testing and rebooting my PC, I had been using my PC all day and subsequent mounting with Secure Desktop enabled was 1/4 of a second with a flicker of the popup box showing before I received the login box. Thus, I conclude the stats are only gathered once for the first time Secure Desktop is used instead of each time.
I would have expected all subsequent mounts with Secure Desktop enabled without rebooting the PC to gather new stats giving the same ~2 second delay and the popup box with the green scrolling indicator showing something about this can take a long time before I received the login box.. This does not happen.
This morning due other testing unrelated to mount delay, I downgraded to 1.26.15 and there was no delay for using VeraCrypt Hot Key for mounting my Favorites and with Secure Desktop enabled on my PC before I received the login box.
.
Given your explanation, I am willing to accept the ~2 second delay if it provides greater security.
Per my original post, I thought the delay was checking for the existence of my volumes and it was an documentation error.
Can you expand on your explanation if the caching of stats for Secure Desktop needs to be per Secure Desktop session mounting or is once is enough? Please consider that some users do not reboot/shutdown their PCs daily.
By Secure Desktop session, I mean in the case the user is using their Favorites to mount multiple volumes during the same Secure Desktop session. Hence, you only collect stats once for this multiple mount session.
Kind Regards,
Enigma2Illusion
EDITED to correct my results, add clarity and fix typos.
Last edit: Enigma2Illusion 2025-01-28
Maybe after first Secure Desktop session, the APIs for the stats are now in memory resulting in the ~1/4 second times.
after upgrade to v1.26.18 windows 10 19045.5131 started defragging my hdds
My external HDDS VeraCrypt encrypted partitions do not show-up in my Windows 10 OS Build 19045.5371 version. Only the non-encrypted partitions are showing in my Optimize Drives which are scheduled via Windows to defragment.
Therefore, your drive letters D and E appear to be the unencrypted partitions.
Please provide a screenshot of your Disk Management showing the drive partitions.
drives c, d, e are encrypted
disk 3: linux partitions
downgraded to v1.26.15 and it works as expected