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


Volumes are mounted twice


I'd like to mount VeraCrypt volumes using the command line like this:
%ProgramW6432%\VeraCrypt\VeraCrypt.exe /quit /cache yes /mountoption removable /volume \Device\Harddisk0\Partition0 /letter Z
The drive letter Z is then mounted as a removable device, but other another drive letter (the first that's available) is mounted as well.

The previously unassigned drive letter stays visible in Windows/File Explorer until the computer is rebooted (see attachment).

I'm using Windows 10 Pro.

file attachments

Closed Oct 11, 2015 at 4:46 PM by idrassi


Enigma2Illusion wrote Sep 28, 2015 at 10:22 PM


Can you perform the procedures Mounir outlined in the thread below?

Did removing old TrueCrypt entries and rebooting the PC solve the problem of two drive letters?

AlexanderGross wrote Sep 28, 2015 at 11:15 PM

Many thanks, that helped!

AlexanderGross wrote Sep 28, 2015 at 11:21 PM

Sorry, that was a bit too fast. It didn't help, despite rebooting immediately after cleaning the Registry entries in question.

idrassi wrote Sep 29, 2015 at 8:04 AM

In your case, a good test would be to delete all entries under this registry key that reference VeraCrypt. Reboot and before mounting any volume, open all entries starting with "\DosDevices\", "\GLOBAL??", "#{" and "\??\Volume{" and delete those containing "VeraCrypt' in their data value. Then reboot and try again.

AlexanderGross wrote Sep 29, 2015 at 9:32 AM

Before rebooting I did just that, i.e. I removed everything containing {Vera|True}Crypt.

MichaelSchultchen wrote Sep 29, 2015 at 5:43 PM

Same problem here with Windows 10 Home.

Device volumes are mounted with a single drive letter, but file volumes are mounted with two drive letters simultaneously. One is the assigned letter (in my case P:, assigned by Favorites settings), the other one seems to be the first free drive letter on the system (in my case E:). On dismounting, only P: disappears, but E: remains as an empty drive. It is not accessible in the Windows disk manager, and VeraCrypt's "Tools->Refresh Drive Letters" doesn't remove it.

After that, mounting another favorite volume with the assigned drive letter E: doesn't work any more. ("Drive letter not available" message)

MichaelSchultchen wrote Sep 29, 2015 at 6:09 PM

I already have tried idrassi's hint and rebooted, but the problem remains...

kannix wrote Sep 30, 2015 at 1:05 AM

This problem seems to be related to changes in version 1.15, since it does not happen for me, when i revert to version 1.14:

Steps to reproduce:
  • install OS (tested with Windows 7 64Bit)
  • create new partition on second disk, no letter, don't format
  • create non system volume using VeraCrypt 1.15
  • used drive letters now are C:(OS) and D:(DVD)
    -> Screenshot 1
  • mount newly created volume in VeraCrypt using drive letter E:
What happens:
  • volume is mounted as E: in VeraCrypt as expected
  • letter F: is also in use (missing from list in VeraCrypt)
    -> Screenshot 2
  • drive F: may not be accessible until you select "Tools", "Refresh Drive Letters" in VeraCrypt
    -> Screenshot 3
If you revert to VeraCrypt 1.14 the volume is mounted only once (as expected).

My guess is, this is connected to the security fix here:
Maybe there is something special about how "\GLOBAL??\" devices are handled in Windows...

Workaround, that works for me at the moment:
Unmount unwanted volumes using "mountvol" once, e.g. "mountvol F: /d"
This way the volume is not mounted again, even after reboot.

phoenix7771 wrote Sep 30, 2015 at 2:47 PM

Same problem here with Windows 8.1

Device volume is mounted with a single drive letter, but file volume is mounted with two drive letters simultaneously.

After exit from the VeraCrypt one driver remains as an empty drive. It could be deleted from the Registry only manual. But if you mount that volume again the second drive letter will appear again.

fullmoonrising wrote Sep 30, 2015 at 10:57 PM

Same double mounting problem - Windows 10, VeraCrypt version 1.15.

Whether I try mounting using the command line or the Windows application, a second drive letter is mounted along with the actual requested drive letter in the command.

Deleting the registry keys and rebooting had no effect.

unyk wrote Oct 1, 2015 at 4:21 AM

I had the same issue on Windows 10. I deleted the ghost drive that was being created from the registry & now it looks everything is working fine. Thanks!

Fenderluvr wrote Oct 1, 2015 at 5:58 AM

Confirmed on Windows 7/SP1 (64bit) with preexisting Truecrypt volumes.

LeonM2 wrote Oct 1, 2015 at 12:21 PM

Hi All,

I am seeing and I have been using TrueCrypt and VeraCrypt to mount file containers and that is enough to see the double provided that you select "Mount volumes as removable medium" option. This corresponds to the "/mountoption removable" command line option.

Hence to make testing easier, you do not need to have whole disk encryption. Use a file container is enough.

This happens in Win7 and Win8.1 in VeraCrypt ver 1.15 64-bit. Try the 32-bit version and you also don't see the double.

I also do not install VeraCrypt; I simply expand it and use it in a standard user account, albeit I have to invoke VeraCrypt with the admin account.


LeonM2 wrote Oct 1, 2015 at 3:56 PM

Hi all,

I have done some extensive testing using 2 VM (Win7-Home 64bit) and a Windows 8-64-bit and a real machine running 8.1 64-bit. The result contradict some of my early hastily made comments.

I have also run each experiment in a standard user account and in administrator's account. My normal operation always runs in a standard user account.

In each operating environment (lots of reboots but VM is ok) I tested the 32-bit and 64-bit version of VeraCrypt 1.15. and in each experiment I also turn "Mount volume as removable medium" on and off. I mount a file container and not a whole disk.

Each experiment is preceded with a reboot to make sure the ghost drive is truly gone. I did not have to use RegEdit to delete those ghost drive in HKLM\System\MountedDevices\DosDevicees\?: Here is the conclusion from my experiment matrix:

Both 32-bit and 64-bit of VeraCrypt 1.15 duplicates the drive regardless if "Mount volume as removable medium" is checked or not. This happens in Win7, 8, and 8.1. And this happen regardless if you are using a standard user account or an administrator account.

If you are using Win7, the File explorer may not show the duplicate drive but it is there and there are 3 ways to locate it:
1) Use the VeraCrypt's program either right mouse click and select "Select File and Mount" or simply press the "Select file" button to bring up the file open dialog box,
2) Use dir in CMD to look at files in the duplicate drive.
3) If your machine has other account, do a switch user to another user's account and its file explorer will show you the duplicate or ghost drive.

In Win8 or 8.1 you do not have to do the above mentioned operation. However you may have to press F5 to refresh the file explorer for it to show the duplicate drive.

I am happy to upload the note and the tests I have covered if it is beneficial.


fullmoonrising wrote Oct 1, 2015 at 5:07 PM

LeonM2 10/1/2015 7:56 am
"Both 32-bit and 64-bit of VeraCrypt 1.15 duplicates the drive regardless if "Mount volume as removable medium" is checked or not. This happens in Win7, 8, and 8.1. And this happen regardless if you are using a standard user account or an administrator account."
My results match LeonM2's for Windows 10, VeraCrypt v1.15 installed version, 64-bit. The duplicate drive mount is created regardless of registry key deletion and reboot, removable mount or not, standard user or administrator, whether executing VeraCrypt from command line or Windows app.

codeflux wrote Oct 2, 2015 at 1:44 AM

Confirmed the same issue.
VeraCrypt 1.15 64-bit
Windows 10 Pro 64-bit
Mounting via command line or via GUI doesn't have any effect.
Tried deleting registry entries as prescribed here:
No effect after reboot - empty drive appears regardless.

Somewhat annoying.

LeonM2 wrote Oct 2, 2015 at 5:35 AM


"No effect after reboot - empty drive appears regardless."
In all my tests, VeraCrypt is never installed in the OS. I was operating it 'portable' mode. In all my test, I have no need to touch the registry. I simply reboot and the empty or ghost drive all disappear.


LeonM2 wrote Oct 2, 2015 at 8:39 AM

Hi all,

I have re-run one of the tests using a Win7 Home Premium which I have never touched the registry. In that machine I installed VeraCrypt rather than extacting the file and run it as I have been doing.

I have observed no difference from previously reported observation. Hence it is not a case of it being installed into the machine.

Furthermore, I installed the software mainly to see if I can see a permanent empty drive after reboot. I cannot see this. When a file container was mounted, I use the PsInfo tools from SysInternals to show me the list of drive. You simply use PsInfo -d and it will show you all the drives, empty or not, even when you do not see them in the file explorer.

This tool clearly shows the creation of the duplicate drive by VeraCrypt. This tool also shows the disappearance of the duplicate drive. However, the registry key HKLM\System\MountedDevices\DosDevices\E: is still there and is clearly identified as "VeraCrypt VolumeO".

However, I trust the PsInfo more than just the presence of this registry key. Perhaps there is another piece that tests the Windows that that DosDevices is actively mounted.

Can people confirm that "empty drive appears regardless" means that drive is showing up in the File Explorer or just the presence of the registry key? If you can run PsInfo, which does not require installation, does that report the empty drive?

Just to make things interesting, I had a E: in DosDevices\E: when I mount the file container into O:, hence the suffix O, and after re-booting it is still present in registry. But PsInfo shows that it is not mounted and hence it is a fair game to use. So I asked VeraCrypt to mount the file container into E: and this produces a duplicate F: reported by PsInfo.

Hence if it does not show up after reboot in your file explorer (with hide empty drive unchecked) and not in PsInfo, I reckon the ghost drive is inactive or mounted. If it is mounted I cannot complete the above experiment.



idrassi wrote Oct 2, 2015 at 7:25 PM

Thanks to all and especially Leon for the detailed analysis.

The fix for the TrueCrypt has side effects which are difficult to avoid at this stage. I'm working on a better fix but it proves very challenging. As I have written for the recycle bin issue ( there is a risk that it will not be possible to solve the TrueCrypt vulnerability without introducing instabilities like these ones.

Of course, it is out of question to leave this vulnerability open for exploits so the priority now is to come up with technical solutions that may even requires a big change in the internal architecture.

I'll keep you informed.

fullmoonrising wrote Oct 3, 2015 at 5:44 PM

The fix tip offered by kannix (Sep 29 5:50pm) has also worked for me to permanently keep the unwanted second drive from being mounted:
  1. Open a cmd window as administrator and for each unwanted second drive mounted, execute the following command where X: is the second unwanted drive mounted.
mountvol X: /d

For example, if you mounted a VeraCrypt volume as drive Z: but in addition to Z: a second drive G: was also mounted, the command would be:

mountvol G: /d
  1. Immediately reboot. After restarting, when you then remount your VeraCrypt volume(s), the second mount is longer created for that boot or any subsequent boots.
At least that's my experience, which is the same as that for kannix. My OS is Windows 10.

MichaelSchultchen wrote Oct 3, 2015 at 7:41 PM

Additional advise: After creating a new file volume, there is also an empty drive left, even if the created volume itself is not mounted.

mountvol X: /d also workes for me on Windows 10 as described above. Thanks to kannix and fullmoonrising.

zygoatinottawa wrote Oct 3, 2015 at 8:35 PM

I can also confirm that the approach recommended by kannix, fullmoonrising and MichaelSchultchen has worked for me...the phantom local drive has gone and has not reappeared after rebooting and mounting my VeraCrypt volume. Also on Windows 10 here.

LeonM2 wrote Oct 4, 2015 at 7:33 AM


Now given the fact that VeraCrypt has fixed the vulnerabilities in v1.15 BUT has this issue that creates duplicate drives, my question is:

Is the duplication of drives, which to me is more a nuisance than being attacked, a minor inconvenience to warrant the adaptation of using VeraCrypt v1.15 to replace my TrueCrypt 7.1a? I also mount my file containers as removable drive and hence the recycle bin issue is not relevant to me

The main thing to know is there any other yet to surface side effects.

VeraCrypte 1.15 running on Mint is working fine.

BTW, anyone using TrueCrypt and VeraCrypt leaves signs of such usage in the registry allowing forensic investigator to add one more pieces to their puzzle.


LeonM2 wrote Oct 4, 2015 at 1:40 PM


The recommendation to use mountvol /d is interesting. After reading about it I set up my Win7 VM to test the suggestion. It works in a strange way and this MSDN article may provide some hint on why it is so: I believe there are more information kept elsewhere by Windows on the drive letter assignment. Incidentally the drive, duplicate or the mounted one, is not shown up in the Disk Manager but shown by PsInfo.

My experiments show this:
1) On a virgin machine - one that has not used VeraCrypt - or One using a drive letter that you have not used previously for mounting file in VeraCrypt, the minute you mount a file, say using H:, it will create a duplicate drive, say E:, as we already are aware. One can use PsInfo -d to verify the duplication.

2) Then one can use mountvol E: /d, to delete the duplicate drive. Rebooting it is not necessary.

3) You can dismount H: and mount a file, same file or others, into the same drive letter, say H: and no duplicate drive will come up.

4) Assuming you have only used one drive to mount a file, say H:. even with the absence of a duplicate drive (after using mountvol /d previously or just now), the minute you mount a file into a drive letter that you have not used before, say S:, it will bring up the duplicate drive.

For those that have used mountvol to delete the duplicate drive, try to mount your file container into a different drive letter that you have been using particularly one that you have not used to mount a file container to see if you see the duplicate drive.

5) In other words, as long as you use the drive letters that you have used before (who has its associated duplicated drive removed using mountvol to delete), it will not bring up duplicate drive. Hence if you have say 4 file containers that you need to mount at maximum, just mount them into the chosen 4 drives (say S: T:, U: and V:) and then use mountvol /d to remove those duplicated ones and from then on, it will not bring up duplicate as long as you stick to these drive letters. I believe this is the behaviour that most have encountered endorsing that the use of mountvol is a work around. But this does not mean you are totally out of the woods.

If you mount the file container in a different machine, you may encounter duplicate drive there.

Because the above mentioned experiments have this system persistence behaviour, the only way I could repeat these experiments from scratch is to use a Virtual Machine which allows me to replace the test one with a virgin backup copy.


fullmoonrising wrote Oct 4, 2015 at 5:14 PM

LeonM2 wrote:
4) Assuming you have only used one drive to mount a file, say H:. even with the absence of a duplicate drive (after using mountvol /d previously or just now), the minute you mount a file into a drive letter that you have not used before, say S:, it will bring up the duplicate drive.
Yes, I got the same result on Windows 10 when mounting a drive letter not used before. The duplicate got mounted as Drive G:. Executing the 'mountvol G: /d' command as administrator prevented subsequent duplicate mounts when using that new drive letter again.

As you suggest in your point 5), I intend to just use previously mounted drive letters from now on so that the duplicate mount does not occur.

Thanks for sleuthing this, LeonM2!

idrassi wrote Oct 5, 2015 at 4:17 AM

Thank you for sharing this workaround.

I have released a beta version of 1.16 that solves this issue. This is explained in my post here:

Basically, CVE-2015-7358 fix was modified to avoid the encountered Windows side effects while protecting against practical attacks. Theoretically, the modified fix can still be abused but it will be extremely difficult and in real world situation it will be almost impossible.

Fenderluvr wrote Oct 5, 2015 at 4:51 AM

I have installed 1.16, and so far, the issue seems resolved. I will continue testing. On a side note, this issue:

(VC 1.15) Error 0x8007000F when deleting folders

seems to be resolved, as well. Please test to confirm.

Well done!

MichaelSchultchen wrote Oct 5, 2015 at 3:54 PM

Additional advise: After creating a new file volume, there is also an empty drive left, even if the created volume itself is not mounted.
With 1.16, this seems to be resolved as well. Thank you for the quick fix.

EricBleher wrote Oct 18, 2016 at 10:49 PM

I just installed VeraCrypt 1.19 to get rid of TrueCrypt, and also had the issue.
1.19 fixed a lot of security issue after the audit, and apparently rolled back some new stuff from 1.18 or other versions. Could that fix also be affected?

EricBleher wrote Oct 18, 2016 at 11:06 PM

as suggested in
idrassi wrote:
Did you try running the command "mountvol.exe /r" in an elevated command prompt after dismounting both volumes and rebooting?

Check also if the drives are not also present on the favorites list and that the option "Mount all device-hosted VeraCrypt volumes" is not checked in the Preferences dialog.
I did that and it seems it solved my issue. So all good with 1.19!

I suppose the pb appeared for me because I first defined the different partitions and containers in the favorite list, and then mounted them via a script with cmd line parameters: /v /l /k /p /q
Then got rid of the favorite list, but somehow the letters were still registered.