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

Background Cpu usage spike & Network drives in 1.17+

Topics: Users Discussion
Mar 23, 2016 at 8:34 PM
I noticed that upon upgrading to 1.17 or the Beta 2 of 1.18 the background cpu usage of VeraCrypt has spiked from 0.01 to around 0.20ish. While still not a huge amount, I thought it was worth investigating.

Watching the VeraCrypt.exe process with procmon I found it was looping around opening and closing keys at HKCU\Network trying to find every available 'free' drive as a network drive. Upon further inspection I found that it appears to be linked to the newly loaded mpr.dll (it's a windows file)

Looking at the release notes I assumed it is related to this:
"Hide disconnected network drives in the list of available drives. Add option to make them available for mounting."

Selecting the newly added option, "Make disconnected network drives available for mounting" fixed the extra CPU usage but the lengths I had to go to track down and make this simple change and restore the 0.01 background usage was rather annoying. Quite a few users may not notice. However, those people who actualy make use of Network Drives are more likely to pay attention to the settings and/or want to mess with it. So perhaps this option should be checked by default to avoid others from needing to track it down?
Mar 24, 2016 at 1:38 AM
Thank you for investigating this issue and coming up with a workaround. I appreciate your efforts.

This option was added to avoid conflicts where VeraCrypt automatically choose the first available drive that happen to be a disconnected network drive and when this network drive is connected afterwards. The decision was made to make VeraCrypt ignore such mapped drives since they are not supposed to be used by anything else (this is also Windows behavior which doesn't allocated network mapped drive letters to removable disks upon their arrival).

The culprit is the function WNetGetConnection that is called several times every 500ms and this causes more CPU usage. I have pushed a modification to cache WNetGetConnection results with a validity of 2 seconds that should should reduce CPU usage while maintaining usability:

I will try to build a new 1.18 beta that includes this tomorrow.