This project has moved and is read-only. For the latest updates, please go here.

Serious memory leak ?

Topics: Technical Issues
Nov 16, 2014 at 7:19 PM
Edited Nov 20, 2014 at 11:18 AM
Hi,

I was planning to migrate to Veracrypt, but during copying of data I noticed that I cannot copy data from 1 veracrypt volume to another veracrypt volume. When both are mounted and I'm starting to copy the memory raises in a couple of seconds to 95% of use and basically this causes the system to perform very slowly so I must stop the copy operation. The memory stay on the high level until I dismount the volume, after dismounting the volume the memory is back to a normal level (20%). Any suggestions on what could be wrong ?
One additional finding is that when looking into memory using RAMMAP I can see one of this volumes in "File Summary" tab - even when not mounted and it have a total 5 GB of memory showing in the list - I'm really puzzled why this is showing there..

Image

The issue occurs only when copying data from Veracrypt encrypted volume to some other volume (can be normal, not encrypted volume). The same action - copy from a truecrypt volume cause very little memory use. Really hoping this issue can be solved as I already have some data there which isn't backed up...and seems that I cannot copy it now anywhere..

This is basically doing the same but from truecrypt volume (to veracrypt):
Image
Nov 16, 2014 at 7:47 PM
Edited Nov 16, 2014 at 7:51 PM
Hi,

This has been reported previously on Sourceforge VeraCrypt forum. This is not a memory leak in VeraCrypt but rather a well know issue in Windows.
Here is the link of the discussion: https://sourceforge.net/p/veracrypt/discussion/technical/thread/fb8c352d/ where you can find my answer at the bottom with technical details about a solution.

Thanks for updating us if the solution solves your issue.
Marked as answer by ebsk on 11/16/2014 at 11:58 PM
Nov 16, 2014 at 8:19 PM
Edited Nov 20, 2014 at 11:19 AM
Thanks for quick input. I tried this workaround and indeed now I'm able to copy without the 'memory issue', so that's good. But I'm wondering about the the difference between TC and VC here as truecrypt isn't causing this particular memory issue (doesn't need any workaround in the same environment).
Other issue I'm noticing now is high CPU usage - when copying from truecrypt it's around 50% and from veracrypt it's almost constantly 95%-99% (but isn't such a problem as with the memory).

Hereby some screens for confirmation. The same copy operation from TC -> VC and VC -> VC volumes as per CPU (large file > 4GB):

VC->VC
Image

TC->VC
Image
Nov 16, 2014 at 8:42 PM
I really can't explain the difference of behavior between TrueCrypt and VeraCrypt at this stage. VeraCrypt driver uses the same source code as TrueCrypt and the only differences are related to security : various security checks, erasing sensitive memory, using secure string function and using secure integer functions to avoid potential overflows. Of course these security modifications have a cost but it should not be so high.

What is really suspicious is why Windows doesn't exhibit the cache issue with the TrueCrypt driver? The only explanation is that Windows "recognizes" somehow TrueCrypt and adapts its behavior to it. Microsoft is doing this for the drivers of many manufacturers so maybe they also put TrueCrypt in this special list.
The other possibility is that the binary of the TrueCrypt driver doesn't correspond exactly to the published sources...but I doubt it.

I'll try to analyze this from my side. I will also compare the behavior of the TrueCrypt shipped with version 7.1 with the one I compile myself just to check if there is any difference.
Nov 17, 2014 at 7:12 AM
Edited Nov 17, 2014 at 7:13 AM
If I may add something is that when looking into RamMap I can always see the original VC container file under "File Summary" tab (usually after some copy operation is done to or rather from the encrypted disk). I never noticed that with TC. And before implementing the workaround mentioned earlier (SetSystemFileCache) this "File" or rather memory mapping of a file was getting very large (5-6GB it looked like everything which was being copied from the volume was adding to this space) + it didn't get any lower until the volume was actually unmounted, after the workaround this 'space exhaustion' doesn't happen, however, the file is still there but it just take less space.
Nov 17, 2014 at 11:17 PM
I did many tests with TrueCrypt and I see the file copied in the "File Summary" tab as it is the case with VeraCrypt. Are you sure your really checked TrueCrypt with RAMMAP?
Actually this file mapping is done by Windows itself for the copy operation and it has nothing to do with TrueCrypt/VeraCrypt which are only responsible for encrypting/decryption blocks of data without any knowledge of the filesystem. After the end of the copy operation, Windows flushes slowly this cache and you'll see memory usage decreasing with time.

Also, be careful with RamMap: when using it, the memory usage will increase with a non negligible percentage. So, don't do use it with doing memory consumption measurements.

Anyway, in my case, I see absolutely no difference of behavior between TrueCrypt and VeraCrypt for file copying operations in any scenario. There must be other factors linked to Windows itself. Even Microsoft is unable to explain why this issue is happening on some machine and not the others (http://support2.microsoft.com/kb/976618/en-us).

Concerning the CPU issue, are you using the same encryption algorithm for both TrueCrypt and VeraCrypt volumes?
The most probable reason of your CPU pattern is that you are using AES for the TrueCrypt volume which will use the hardware acceleration and for VeraCrypt you are using an algorithm different from AES (like Serpent) or a cascade of algorithms with will not use any hardware acceleration and therefor it will consume more CPU. Do you confirm this? What CPU are you using by the way?
Nov 18, 2014 at 4:24 PM
Edited Nov 20, 2014 at 11:19 AM
In regard to RamMap - I was referring to the fact that I was able to see a path to 'encrypted VC container file' there rather than the copied files, the copied files it's normal in both cases but I was able to see the VC container in "File summary" as well. However, cannot reproduce it now, but probably should be easy if you mount VC container on a 'fresh' windows 7 and copy a large file from the partition to somewhere else, then the container file will probably show under the 'File Summary' tab and use a lot of memory very quickly during the copy (behavior on first screenshot). I was puzzled why - instead of a copied file the 'container' file was showing there and growing in space.

With CPU issue you have a valid point that the 2 containers I tested had different encryption algorithms used (AES vs stacked). Now that is clear to me.
CPU is AMD Phenom II X6 1090T.

Update: I was able to reproduce it, earlier just didn't notice..
So both containers are mounted, but only 1 is visible in RamMap:
Image
Nov 18, 2014 at 11:02 PM
Sorry for confusing what was mapped in memory.
This is indeed very puzzling!! I have just done tests on my usual PC and the VC container file didn't show up in memory even after many copies. But I'm using AES for both TC and VC, so:
  • What is the cascade algorithm combination that you are using in VeraCrypt?
  • Is it possible for you to do a test with TrueCrypt using exactly the same encryption algorithm as for VeraCrypt?
When you copy data from or to a encrypted container (TC or VC), Windows sends I/O request packets (IRP) to the driver that correspond to data that has to read/written and if the encryption/decryption if slow, Windows will use more cache in order to make the operation appear to the user as having normal speed while at the same time waiting for the driver to complete previous IRPs.
On the other hand, if the encryption/decryption is quick (like in the case of hardware accelerated AES), Windows will use almost no cache because all I/O request packets are treated by the driver instantly.

At this stage of the analysis, the use of slow cascades algorithms is the most probable culprit behind this behavior and it should be the same for TrueCrypt.
To be confirmed by further tests.
Nov 19, 2014 at 10:00 AM
Edited Nov 20, 2014 at 11:19 AM
Basically TC reveals the same behavior when using A-T-S algorithms.
Image
Nov 19, 2014 at 10:47 AM
Edited Nov 19, 2014 at 11:07 AM
Thanks for the confirmation!

I will have to update the FAQ and Troubleshooting with this new information. The use of cascade algorithms, even if it is controversial, is popular for those who need maximum assurances about the encryption security and definitely this will trigger this memory cache issue if the performance of the speed of the cascade algorithm on the machine is too slow with respect to what Windows expects.

Can you please post the screenshot of the "Tools -> Benchmark" dialog? This can give an idea about the type of configurations where this issue may occur.

I have tries with a PC equipped with a Core i7-2600K CPU and 8GB of memory and the issue doesn't occur even when using the slowest cascade algorithm (AES-Twofish-Serpent). Here is mine as a base of comparison:
Image
Nov 19, 2014 at 11:01 AM
Edited Nov 20, 2014 at 11:20 AM
Hereby the screenshot from both applications:
Image
Nov 19, 2014 at 12:59 PM
Thanks.

We can speculate that the minimum speed limit a cipher must have to avoid the cache issue under Windows is around 200 MB/s but this certainly depends on other factors.
Dec 4, 2014 at 5:22 PM
Edited Dec 4, 2014 at 5:24 PM
An alternative solution when migrating a lot of data from one drive to another drive is to use MicoSoft's Robocopy command line tool.

I have used robocopy at work and at home successfully when copying large number of files (in the thousands) using robocopy to avoid the slow down from Windows Explorer.

Here are examples for the command line from source drive X to target drive Y.

Copy the entire disk drive that was physically connected to another PC to the current PC. Drive letter X is the source disk drive that was connected to another PC and drive letter X is the target disk drive that is owned by the current PC. By "owned", I mean the disk drive files were all created by the same user account on the current PC. Whereas the source drive was connected to another PC or the current PC with a different account owner.

NOTE: The command is on one line.
robocopy "X:" "Y:" /E /B /R:3 /W:3 /XD "X:\$RECYCLE.BIN" "X:\RECYCLER" "X:\System Volume Information" "X:\boot" /COPY:DAT /DCOPY:T /EFSRAW /NP /NDL /NFL /Log:C:\Temp\copy.log
Copy the entire source drive to target drive with all files owned by the same PC and the same Windows user account.
robocopy "X:" "Y:" /E /B /R:3 /W:3 /XD "X:\$RECYCLE.BIN" "X:\RECYCLER" "X:\System Volume Information" "X:\boot" /COPY:DATS /DCOPY:T /EFSRAW /NP /NDL /NFL /Log:C:\Temp\copy.log