I noticed VeraCrypt starts slowly when booting from sleep mode. It takes like 15 minutes (windows waiting icon moves very slowly as well) while the normal boot takes seconds... My primary and secondary partitions are both encrypted and use PIM. Is there any way to speed this up?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess it is a hibernate and not a simple sleep.
15 minutes to resume from hibernate is way too much. Of course, the speed of resume will depend on the amount of RAM of your system since Windows will have to restore RAM content from the hibernation file which is decrypted on the fly before VeraCrypt driver takes over but I have never seen it take more than 5 minutes.
Basically, this can be caused by some GPU configuration and the person who posted the issue was running Windows 10 that was an upgrade from Windows 7 and when he reinstalled Windows 10 and encrypted it, the issue disappeared.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mounir, I am also facing this issue.
When resuming from hybernate (GPT / EFI / Win10 system here) it takes maybe 1 to 2 minutes with the windows sign (the round one) moving very slowly. That is after entering password and the veracrypt process being done.
Before I encrypted resuming form hybernate would take 10-15 seconds. My hybernate file is 6GB, at 400mb per seconds (fast M2 ssd here), the expected time is 15 seconds.
What is the reason it now takes so much longer?
One last piece of information: when doing a clean boot, it take exactly the same time as before I encrypt the system drive. So the problem is linked with "resume from hybernate" only.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As an update: I have reduced the PIM, but is has no impact. The pim allow to go faster from the VeraCrypt text line to the windows screen. But what is very slow is on the windows screen (with the little dots turning).
I can upload a video if that helps.
Last edit: Serge De Coster 2016-12-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I removed the mount to favorite. Its not significantly better (maybe a little). Still slower than it should.
My slow is only 1-2 minutes. Some people mention 15 minutes. I wonder what leads to the difference.
I feel the time depends on how much memory was in use at the time of hybernation. Hence it makes it difficult to compare.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi
I would like to re-open this topic, because I have a similar problem on brand new SCHENKER laptop (i7 1.8 Ghz; 16 MB RAM and 1TB and M.2 Kingston A2000 | PCIe 3.0 x4 | NVMe Disk). I have encrypted the system partition with AES (Twofish(serpent)). Unfortunately i have forgot to do my research and i have not encrypted the whole disk, because i have installed win 10 pro using the method that creates the EFI partition.
Every time i put my computer into sleep or hibernation - after i enter the password it takes about 5 minutes to windows comes to the logon screen. Those looping doted circles moving extremely slow.
I looked online for this on how to fix this (https://sourceforge.net/p/veracrypt/tickets/83/; https://www.reddit.com/r/VeraCrypt/comments/cx4mgg/windows_10_boot_from_hibernation_super_slow/), but i'm not successful . How can i fix this?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually, I had and still have this issue on every computer where I have installed VeraCrypt (or TrueCrypt in former times). I didn't have a single machine where this issue did not appear. In most cases, resume from hibernation takes about 20 minutes on machines with 16 GB RAM (laptops as well as desktop PCs, various processors, various SSDs and HDDs, legacy BIOS and UEFI BIOS, with Windows XP Pro 32-bit, Windows 7 Pro 64-bit, Windows 10 Enterprise 64-bit (never used home versions, never used Windows 8.x)).
Until now, I didn't care about it, because I didn't put my machines into hibernation, except for testing or accidentally. But now I am thinking seriously about doing that more often to protect the environment by saving power: I have a complex environment on most of the machines which requires various actions on startup which can't be automated, so I usually leave the machines permanently on to save precious time next morning.
Hibernation / Resume would enable me to hibernate machines at the evening to save power overnight, and to restore working environments next morning in acceptable time. Today's SSDs will stand the additional wear quite a while, so the problem described here starts bothering me. I have done some research and found this article:
Or course, I know that VeraCrypt and Bitlocker are very different, but does VeraCrypt eventually clear the RAM in a similar way, and may this cause the issue?
Last edit: Snow White 2021-08-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is S3 the thing which is commonly called "standby"? If yes, I am a bit hesitant with that, because waking up from it only requires the Windows password; it does not require the VC password - the disk decryption keys are still in memory. This is not the case with hibernation.
Regarding the ticket: I guess that only a few people are affected by the issue. The majority probably doesn't use hibernation or doesn't experience the problem. Maybe I am configuring the BIOS in an unusual way or something like that. However, I am wondering why this happened on every machine I tried with. Given that, I am unsure whether I should open a ticket.
Last edit: Snow White 2021-08-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Of course, putting the PCs into standby would not be more insecure than letting them run (as I currently do), so my reasoning was somehow illogical. In that sense, standby would be a viable short-term solution, and would be better than what I do now, so thanks for the tip. I'll follow your advice now.
However, in the end, I'd like to combine power saving with enhanced security, and that would mean hibernation instead of standby, so I'd still be interested in a solution.
P.S. I believe an alternative term (eventually more correct) is Suspend-To-RAM (sigh - I am not a native speaker).
Last edit: Snow White 2021-08-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I noticed VeraCrypt starts slowly when booting from sleep mode. It takes like 15 minutes (windows waiting icon moves very slowly as well) while the normal boot takes seconds... My primary and secondary partitions are both encrypted and use PIM. Is there any way to speed this up?
I guess it is a hibernate and not a simple sleep.
15 minutes to resume from hibernate is way too much. Of course, the speed of resume will depend on the amount of RAM of your system since Windows will have to restore RAM content from the hibernation file which is decrypted on the fly before VeraCrypt driver takes over but I have never seen it take more than 5 minutes.
What version of Windows are you running? I answered a similar issue here: https://sourceforge.net/p/veracrypt/tickets/83/
Basically, this can be caused by some GPU configuration and the person who posted the issue was running Windows 10 that was an upgrade from Windows 7 and when he reinstalled Windows 10 and encrypted it, the issue disappeared.
Mounir, I am also facing this issue.
When resuming from hybernate (GPT / EFI / Win10 system here) it takes maybe 1 to 2 minutes with the windows sign (the round one) moving very slowly. That is after entering password and the veracrypt process being done.
Before I encrypted resuming form hybernate would take 10-15 seconds. My hybernate file is 6GB, at 400mb per seconds (fast M2 ssd here), the expected time is 15 seconds.
What is the reason it now takes so much longer?
One last piece of information: when doing a clean boot, it take exactly the same time as before I encrypt the system drive. So the problem is linked with "resume from hybernate" only.
As an update: I have reduced the PIM, but is has no impact. The pim allow to go faster from the VeraCrypt text line to the windows screen. But what is very slow is on the windows screen (with the little dots turning).
I can upload a video if that helps.
Last edit: Serge De Coster 2016-12-10
it might be mount favorites delay.
I removed the mount to favorite. Its not significantly better (maybe a little). Still slower than it should.
My slow is only 1-2 minutes. Some people mention 15 minutes. I wonder what leads to the difference.
I feel the time depends on how much memory was in use at the time of hybernation. Hence it makes it difficult to compare.
I fixed it by changing the encryption algo.
Triple algo and wirlpool was very slow.
Then I tried AES and 512 (all standard), no more problem.
Hi
I would like to re-open this topic, because I have a similar problem on brand new SCHENKER laptop (i7 1.8 Ghz; 16 MB RAM and 1TB and M.2 Kingston A2000 | PCIe 3.0 x4 | NVMe Disk). I have encrypted the system partition with AES (Twofish(serpent)). Unfortunately i have forgot to do my research and i have not encrypted the whole disk, because i have installed win 10 pro using the method that creates the EFI partition.
Every time i put my computer into sleep or hibernation - after i enter the password it takes about 5 minutes to windows comes to the logon screen. Those looping doted circles moving extremely slow.
I looked online for this on how to fix this (https://sourceforge.net/p/veracrypt/tickets/83/; https://www.reddit.com/r/VeraCrypt/comments/cx4mgg/windows_10_boot_from_hibernation_super_slow/), but i'm not successful . How can i fix this?
Actually, I had and still have this issue on every computer where I have installed VeraCrypt (or TrueCrypt in former times). I didn't have a single machine where this issue did not appear. In most cases, resume from hibernation takes about 20 minutes on machines with 16 GB RAM (laptops as well as desktop PCs, various processors, various SSDs and HDDs, legacy BIOS and UEFI BIOS, with Windows XP Pro 32-bit, Windows 7 Pro 64-bit, Windows 10 Enterprise 64-bit (never used home versions, never used Windows 8.x)).
Until now, I didn't care about it, because I didn't put my machines into hibernation, except for testing or accidentally. But now I am thinking seriously about doing that more often to protect the environment by saving power: I have a complex environment on most of the machines which requires various actions on startup which can't be automated, so I usually leave the machines permanently on to save precious time next morning.
Hibernation / Resume would enable me to hibernate machines at the evening to save power overnight, and to restore working environments next morning in acceptable time. Today's SSDs will stand the additional wear quite a while, so the problem described here starts bothering me. I have done some research and found this article:
https://support.microsoft.com/en-us/topic/use-of-hibernation-may-cause-slower-starts-and-resumes-when-bitlocker-drive-encryption-is-enabled-1006aec5-1f82-9cb0-f479-bcf5ec1f47ed
Or course, I know that VeraCrypt and Bitlocker are very different, but does VeraCrypt eventually clear the RAM in a similar way, and may this cause the issue?
Last edit: Snow White 2021-08-17
This topic would be worth a ticket in my opinion.
As a workaround, have you tried using S3? It's not as energy saving as S4 but still better than keeping the machine running.
Thank you very much!
Is S3 the thing which is commonly called "standby"? If yes, I am a bit hesitant with that, because waking up from it only requires the Windows password; it does not require the VC password - the disk decryption keys are still in memory. This is not the case with hibernation.
Regarding the ticket: I guess that only a few people are affected by the issue. The majority probably doesn't use hibernation or doesn't experience the problem. Maybe I am configuring the BIOS in an unusual way or something like that. However, I am wondering why this happened on every machine I tried with. Given that, I am unsure whether I should open a ticket.
Last edit: Snow White 2021-08-17
You are right, I was talking about standby. But you have some points against using it.
I guess I should add something to be correct:
Of course, putting the PCs into standby would not be more insecure than letting them run (as I currently do), so my reasoning was somehow illogical. In that sense, standby would be a viable short-term solution, and would be better than what I do now, so thanks for the tip. I'll follow your advice now.
However, in the end, I'd like to combine power saving with enhanced security, and that would mean hibernation instead of standby, so I'd still be interested in a solution.
P.S. I believe an alternative term (eventually more correct) is Suspend-To-RAM (sigh - I am not a native speaker).
Last edit: Snow White 2021-08-18