Veracrypt uses/loads a file system driver (windows). I presume this is a DLL or SYS file (or maybe a process at startup). I don't know specifically and can't find any evendence of where/when/how it hooks into the system after installation. Truecrypt did
the same of course and had a similar hook.
The problem I'm discussing has been in existance since switching to Veracrypt. It's present on 32bit machines: both XP and now Win10. I can't speak for 64 bit, but I have seen comments from others suggesting they experience the same. The problem did NOT occur
with the Truecrypt driver (7.1a), only Veracrypt. (I'm only getting around to posting an issue now, but the issue has been in all recent versions of Veracrypt. Maybe as far as the beginning. I think I started around 1.09 or so. Unsure.)
The problem is that the driver has too high of a system priority - too privileged. When veracrypt is mounting or heavily accessing a drive/containuer (I use an SSD) pretty much all other system activity crawls or becomes unresponsive. Note
that I'm not talking about a particular program, I talking about the whole OS - Alt-tabbing, videos playing from internet, launching an app, even the mouse somewhat. Veracrypt grabs the OS and won't yield to standard other system operations. I'm including activities
that are memory bound only as well.
UNLIKE Truecrypt, Veracrypt (even when I was only accessing Truecrypt legacy volumes) is running at some sort of priority which is higher (or more 'severe') than what Truecrypt ever did and is high enough to block even normal UI interactions (that a decade
or two ago would often be a sign of a poorly multitasking OS).
I'm asking or suggesting that the priority of this SYS or DLL hook be reduced down to 'normal' system level. If I'm mounting a volume or accessing an encrypted drive the system hook should process things 'as fast as it can' but NOT to the extent of pushing
100% cpu and then blocking out the rest of the OS operations. The access/mount/decrypt will finish whenever it finishes - blocking or strangling the rest of the OS won't make much difference. If yielding normally to the rest of the OS makes it take 2 seconds
longer than that's fine, but my mouse and videos and other activities shouldn't lock up or go choppy (this isn't a complete freeze).
Finally, I can say this might be an issue that those with very fast CPU's still HAVE, but which they dont' NOTICE. Their CPU might simply be able to cover up (but not remove) the effect. If you go to cpubenchmark.net, I have a CPU with roughly a 1000 rating
(intel core duo). Perfectly acceptable (still) for all activities othet than gaming in 2017.
Like I've said, I've seen others comment on their system essentially locking up when veracrypt goes into that mounting 'hash interation' (or whatever) loop. That's the same issue. And it happens during normal access too (but less intensive somewhat). And remember
again that Truecrypt was used on the same machines with the same volumes and didn't exhibit.
Can the privilege of Veracrypt sys/hook/dll be lowered/fixed so that it plays nice with the system? Is there a way for me to set it myself if others don't view it as a problem or wish to change it? ("veracrypt.exe" in task manager is only the UI component
to my knowledge and not the file system hook; it is already at "normal" priority as well.)
PS: I searched for and found a somewhat random MSFT page discussing these issues and how drivers (or threads) will sometimes pick their priority level:
All I'm asking is if the driver priority or threads can be reduced back to "truecrypt levels" (which always worked and never had this problem.) Somewhere in the conversion to Veracrypt the level was increased and it clogs the system.