I recently attached two GPT-formatted USB hard drives to my Win10 workstation. I had to update the BCD store on them so I used Diskpart to assign letters S: and T: to the EFI partitions on the drives. Now I have two phantom drive letters S: and T: that are now permanently mapped to my PC even though I no longer have the hard drives in question attached.

enter image description here

I tried plugging the drives back in so I could remove the letter, but the EFI partitions on those drives did not get drive letters (which is the normal behavior). I tried using Diskpart again to assign them the same letters, but it tells me that those letters are already in use.

The drive letters do not correspond to anything in the Disk Management console, so I can't remove them from there. There's nothing in Device Manager that's holding them either. I opted to show hidden devices and removed every grayed out storage volume listed, but the drive letters remain.

These drive letters are "stuck" now and I can't get rid of them.

Any ideas?


The command to remove a drive letter - which shouldn't be needed, but hey, Win10, there are still some bugs - is mountvol <drive> /D, so for you it would be mountvol S: /D and mountvol T: /D. You can also try mountvol /R, which should remove all drive letter assignments for which there is no currently mounted drive. You can also try using /P in place of /D, but it's intended to be used while the volume is actually present.

You can also use the remove command in diskpart to remove drive letter assignments. You mentioned using mountvol to try re-assigning the drive letters but didn't mention trying to remove them. I'm pretty sure it just calls the same APIs as mountvol, actually.

All of these commands will need to be run as Administrator, naturally.

| improve this answer | |
  • I can't use diskpart to remove it because you must first select the volume to operate on before you can remove it, and the letters do not correspond to anything. Looks like mountvol isn't doing the trick either. /D says the system cannot find the file specified. /R says the directory is not empty. – Wes Sayeed Nov 5 '15 at 16:43
  • Those are... odd errors. I presume that they persist through reboots, and those attempts were made after a reboot. The next place you could check is the HKLM\SYSTEM\MountedDevices registry key; if there are values there called things like \DosDevices\S:, delete them. However, I suspect that's what caused the "File Not Found" error from mountvol; it tried to delete those values programmatically and they aren't there. Worth checking, though. – CBHacking Nov 6 '15 at 2:57
  • 1
    Yes, they do persist through reboots, and no, HKLM\MountedDevices does not have any references to them. However, the problem went away on its own after some Windows updates. I posted the real culprit in my answer. – Wes Sayeed Nov 16 '15 at 23:32
  • 1
    @CBHacking Thank you, this worked for my issue concerning Google Drife File Stream. One day it left the G: partition and created H: to use as the new one. I could not find a way to remove it, but your suggestion of mountvol /R worked to delete the google drive filestream phantom disk – Cas Nouwens Apr 4 '18 at 13:19

This problem went away on its own after some Windows Updates forced a reboot of the computer.

This behavior appears to be a bug. I suspect that the reason the phantom drive letters persisted through a reboot was because of Windows 10's "Soft Restart" and "Fast Startup" features, which do not actually shut down or reboot anymore when you tell it to do a shutdown or reboot.

It was likely because the system never actually went through a full HW initialization (and thus never checked the presence of those drive letters) until Windows Updates forced the issue by doing a full reboot.

Brief Overview of the Soft Restart and Fast Startup Features:

In an effort to shorten startup times in Windows 8 and Windows 10, Windows no longer does a full shutdown/restart anymore. The Fast Startup feature (introduced in Windows 8) does a partial hibernation when shutting down the system. Certain core processes (but not all of them as in a full hibernate) have their states saved so that they can be resumed without going through a full initialization on the next startup. This behavior only affected shutdowns, not restarts, and you can turn it off via the Power control panel.

Windows 10 extends this behavior with the Soft Restart feature. When doing a restart, the system resets software as though it were doing a reboot, but does not reinitialize hardware or the kernel, making reboot times faster. You can't turn this feature off.

In Windows 10, the ONLY way to do a FULL reboot of the system is to issue a shutdown -r -f -t 0 from the command line.

| improve this answer | |
  • What about if you've disabled hibernate (powercfg /H off)? I would certainly expect that to disable soft shutdown, and probably soft restart as well. Another thing that seems like to prevent Soft Restart is using the advanced startup options to, say, boot to BIOS/EFI SETUP. – CBHacking Nov 17 '15 at 10:11
  • I just confirmed that this works on Windows 10 Build 10586. FYI: You don't need -f when you do -t 0; shutdown -r -t 0 works too. – Granger Feb 2 '16 at 7:36
  • Just fyi, you CAN turn the feature off from Control Panel\All Control Panel Items\Power Options\System Settings , also known as "Choose what the power buttons do". It's also disabled by definition when hibernation is completely disabled with powercfg -h off. – sCiphre Jan 4 '17 at 18:44
  • I have had this problem despite years of rebooting and upgrades. I believe it was related to the use of VirtualClone drive (or some similar tool) that reserves the drive letters. Maybe I had even done some command line to reserve them. – Fuhrmanator Aug 22 '19 at 11:14

Not the answer you're looking for? Browse other questions tagged or ask your own question.