"phantom disk" still present after dismount script from task scheduler

[xznhj8129]

I have a script that runs on task scheduler that does a /dismount /force /quit to enable the volume files to be backed up. When tested the script runs fine, however when run from windows Task Scheduler (8.1), the volume letter i was using still shows as used even though it is not accessible or otherwise removable. This makes it impossible to re-use that drive letter until the computer is rebooted (i hope).
Same problem as these people: https://sourceforge.net/p/veracrypt/discussion/technical/thread/9e67bfd2/

[zasifras]

VC 1.24-Update2(64bit) on Win10 still exhibits this bug. This issue only occurs when using the command line options, for script use. Using the GUI it works fine and the drive letter is correctly freed up for use again. But the command line options dismount the disk, but still leave the drive letter unusable in Windows, where any attempted access of that drive letter causes Windows to error. Only rebooting the Win10 system will free the drive letters. So it seems there is some difference between the GUI code path and the command line code path when dismounting drives.

[mpwhiten]

I just wanted to report that I'm having similar, though slightly different, problems. While the above and other examples I can see online relate to dismounting drives through scripts / CLI, I'm ending up with "phantom drives" when mounting through the CLI and dismounting through the GUI (right-click taskbar icon -> dismount).

I've discovered a couple of nuances with this behaviour:

1. Problem only occurs if I mount the container using a PowerShell script. Mounting with the exact same parameters using a batch file results in no phantom drives when I dismount.
2. Problem only occurs for me with encrypted file containers. I can happily mount encrypted non-system partitions using either batch files or PS scripts and successfully dismount them with the GUI leaving no phantom drives behind.

I'm using VC 1.24-Update7 (64bit) on Win 10 Pro.

Batch file command:

start "" "C:\Program Files\VeraCrypt\veracrypt.exe" /quit background /letter d /mountoption label=label /volume container_path

PowerShell command:

$veracrypt = "C:\Program Files\VeraCrypt\veracrypt.exe"
$args = "/quit background", "/letter d", "/mountoption label=label", "/volume container_path"
Start-Process -FilePath $veracrypt -ArgumentList $args

EDIT: I don't know why but since I started playing around with using the PS scripts instead of batch files the phantom drive issue is now occurring for encrypted file containers no matter whether I mount with a PS script or a batch file. This is after having no problems using batch files for the past year or so.

[alt3r-3go]

I've just tried running mounts and unmounts of a container-based volume from BAT files and from PS scripts, both manually in cmd/PS and via the Task Scheduler (run on demand) - and I don't observe any such "ghosting", the drive letter is freed properly each time.

This is on newly installed Win10 1909 without any additional antiviruses or software except VeraCrypt (1.24-Update7). I would say these effects you folks observe seem to be some sort of interference from the antivirus/whatever other SW that inserts itself into volume I/O paths. Can you try disabling everything except VS and give it another try (but make sure it's indeed stopped and there are e.g. no services still running)?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because it has not had recent activity. This probably means that it is not reproducible or it has been fixed in a newer version. If it’s an enhancement and hasn’t been taken on for so long, then it seems no one has the time to implement this. Please reopen if you still encounter this issue with the latest stable version. You can also contribute directly by providing a pull request. Thank you!

[amail80]

This appears to be the same root cause as #1426. I've submitted a fix in PR #1658 — see that PR for the full root cause analysis.