84

I'm constructing a backup script for Windows 7, and the last action I want it to perform is to safely "remove" the USB drive that it is backing up to. I am under the impression that plugging the drive into the same USB port all the time will keep the same DEV_ID (correct me if I'm wrong). With a command line (or PowerShell), how can I tell Windows to safely remove the hardware automatically without user input?

Just as a place holder, other OSes that may have a way to do this would be great to know as well.

Peter Mortensen
  • 12,090
  • 23
  • 70
  • 90
Canadian Luke
  • 24,199
  • 39
  • 117
  • 171
  • 6
    I have to admit disappointment by some of the “answers” below which clearly did not understand what is being asked and provided options that are obviously useless for the task of automation as asked.` ಠ_ಠ – Synetech Dec 05 '13 at 03:39
  • > I am under the impression that plugging the drive into the SAME USB port all the time will keep the same DEV_ID, correct me if I'm wrong. That is correct. Windows treats a drive and the port it’s plugged into as an identifying pair. By plugging it into a different port (in which it has never been plugged), you will trigger Windows’ driver-installation function. Worse, if you have assigned a non-consecutive drive-letter to the volume, then plugging it into a new port will not retain that letter, and it will get the next available letter and you must assign a letter manually again. – Synetech Dec 05 '13 at 03:44
  • 1
    (Oddly enough, if you plug a drive into a port and let Windows install drivers for it, then assign a non-consecutive drive-letter to it, then unplug it an plug in a *different* drive that is of the same make, model, and size, then Windows will treat it exactly as though you plugged in the previous drive again.) – Synetech Dec 05 '13 at 03:45
  • Could you update title to be correct. I was looking for answers on removing USB "devices" not USB "drives". –  Apr 10 '15 at 12:43

9 Answers9

80

Besides Uwe Sieber's RemoveDrive mentioned in the other answer, there are a whole bunch of utilities that can accomplish this. A small list follows:

  • USB Disk Ejector is primarily a GUI-based utility but can be used equally well from the command-line to eject the drive that the program is running from, or any drive by specifying the drive letter / (partial) drive name / mountpoint etc. Free and open source.

    USB Disk Ejector

  • USB Safely Remove is not free but it's a disk removal utility on steroids, with lots of advanced features, including of course command-line support. Zentimo is its bigger brother, with even more features.

    USB Safely Remove

  • Microsoft's own DevCon is the command-line version of Device Manager. Besides the original Win2K/XP-era version available from the KB page, there are newer releases (both 32 and 64-bit) available from various MS sources as mentioned in this Where to find DevCon.exe article. DevCon.exe for Windows 7 (and probably Windows 8 as well) can be found buried in the appropriate Windows Driver Kit (WDK), as mentioned in this thread (which also contains download links to the extracted executable).

    devcon status * or devcon hwids * or devcon findall =usb (for a more compact listing) should tell you the hardware ID of the device. For example:

    USB\VID_0781&PID_7113\0001162825
    Name: USB Mass Storage Device
    Driver is running.

    You can then try removing the device with devcon remove "USB\VID_0781&PID_7113" (wildcards like * are allowed, but be careful or you might end up removing something else entirely!)


Someone asked "Is there a DOS prompt (cmd.exe from Win7) command to eject a thumb drive?" which was unfortunately closed as a duplicate of this thread. However, the question was about ejecting USB drives while in the Windows Recovery Console / System Recovery Command Prompt, so it is unlikely any of the utilities above will help. In such a situation, the following method using Diskpart should work:

  1. Type diskpart and wait for the diskpart prompt (DISKPART>)

  2. Type list volume

  3. Note the volume number of the USB drive carefully (use listed properties such as drive letter, label, type and size for help)

  4. Type select volume <number>, where <number> is the volume number noted above

    Diskpart

  5. Type remove all dismount

  6. Type exit to quit Diskpart

Now you should be able to safely remove your USB drive without fear of data loss.

Karan
  • 55,947
  • 20
  • 119
  • 191
  • 1
    Thanks for taking time to respond to my question even after SU closed it. I went ahead and acted on Jared Tritsch's suggestion and removed the drive just by removing it. Once I get laptop operational again, I'll experiment with with DISKPART. Here's the link to Microsoft's Specs for DISKPART. http://technet.microsoft.com/en-us/library/bb490893.aspx – zundarz Oct 12 '12 at 03:19
  • 2
    @zundarz: You're welcome! The default **Removal policy** in Windows for removable devices is **Quick removal**, which disabled write caching and allows one to remove the drive without needing to safely remove it first. See [this screenshot](http://i.stack.imgur.com/S3zET.jpg) for more. Thus Jared's suggestion about yanking the drive shouldn't ordinarily cause data loss if removable drives are treated the same way in the Recovery Console as well. Still, for peace of mind I always take care to safely remove each drive before pulling it out. Might be a placebo, but keeps me from worrying. :) – Karan Oct 12 '12 at 04:28
  • P.S. Be careful with Diskpart - it's powerful and hence quite dangerous. The reason I used it for drive dismounting is because it's available from both XP's Recovery Console and Vista/7's System Recovery Options / Command Prompt. – Karan Oct 12 '12 at 04:38
  • I tried using `Diskpart` while in normal Windows mode. This is the message I get after performing step 5 above. "DiskPart successfully removed the drive letter, but your computer needs to be rebooted before the changes take effect. Diskpart successfully dismounted the volume." I tried using it on a removable media (SD card) rather than a removable device (such as the SD card reader or USB flash drive). The LED indicator on the reader didn't go off but it stayed lit (i.e. it stopped flashing as it occasionally does when a SD card only sits in it). So I guess it's safe to remove then. – Samir May 25 '13 at 18:04
  • My SD card reader shows up as "Removable Disk" in the Computer view (Explorer). So I guess what Diskpart did is it tried dismounting the reader itself, rather than the SD card inside it. I haven't tried it with an external disk drive. It might be different story there. But generally I think the reboot message from Diskpart can be ignored. – Samir May 25 '13 at 18:07
  • Reinserting the SD card in the reader didn't help. I tried to unplug the reader, plug it back in, and then insert the SD card again. The P: drive which is the one I select as volume when I did the `remove dismounted all` command in Diskpart didn't show up again in Explorer. But drive N: did show up. I have one of those dual-slot readers where N: is for CF cards and P: is for SD cards. The N: drive worked normally. – Samir May 25 '13 at 18:14
  • Diskpart is probably right then about the reboot. Reboot is required now for me to get back the P: drive to be able to read SD cards. But from safety point reboot is not required. It's safe to remove the media one you get that message. However, this shows that there's a difference in "ejecting" the "Removable Media" (SD, CF, et. al.) and "safely" removing things like "Removable Devices" (external HDD, UFD, et. al). – Samir May 25 '13 at 18:16
  • 5
    To [undo](http://superuser.com/questions/599983/how-to-undo-remove-all-dismount-in-diskpart) the `remove all dismount` command you must use the `mountvol` command. For more information see Technet library [here](http://technet.microsoft.com/en-us/library/cc731985%28v=ws.10%29.aspx) and also [here](http://technet.microsoft.com/en-us/library/cc772586%28v=ws.10%29.aspx). After you have used `mountvol` you must reboot for the changes to take effect. Alternatively, you can also use Disk Management to assign a new drive letter. – Samir May 26 '13 at 12:44
  • None of these options really address the question that was asked. `:-|` They’re good, but belong in *other* questions about ejecting removable media, not this one. – Synetech Dec 05 '13 at 03:21
  • 1
    i'd consider the last command to be the best as it doesn't require third-party software to implement the solution –  Nov 20 '14 at 03:34
  • I've tried this method but once I plug the usb again, the usb has no path. I have to assign it back from Device Manager. – CroCo Dec 25 '14 at 02:12
  • @Samir you are right, I remounted using `diskmgmt.msc` and assign letter. – Smeterlink Apr 20 '20 at 02:17
36

RemoveDrive has served me well in the past

stijn
  • 2,007
  • 1
  • 17
  • 26
  • 5
    **removedrive\x64>RemoveDrive.exe f: -L** is the code, for those who are in hurry – fedmich Aug 09 '14 at 07:31
  • This ended up working for me. Interestingly an WqlEventQuery I have wired up still waits to fire until you physically pull the drive out. Don't know a ton about this stuff, but it surprised me. Doesn't happen to be an issue for me in this case. – samuelesque Apr 02 '15 at 17:44
  • 2
    RemoveDrive is good, but the problem is that it actually removes the whole drive. For card-readers, instead of simply ejecting the card (like right-clicking and selecting Eject from My Computer), and allowing you to plug another on in, it removes the whole card-reader, requiring it to be physically unplugged and re-plugged, or worse, rebooting if the card reader is built in (it is possible to do it through software but it is annoying). – Synetech May 01 '16 at 22:33
  • You can run it from cygwin too. – Kevin Sadler Nov 11 '17 at 13:54
24

To answer to this question... You don't need third party stuff.

With a Command Line (or PowerShell), how can I tell Windows to safely remove the hardware automatically without user input?

Run this command: RunDll32.exe shell32.dll,Control_RunDLL hotplug.dll to bring up the Safely Remove Hardware dialog box:

The Safely Remove Hardware Dialog

climenole
  • 3,428
  • 1
  • 19
  • 30
  • 4
    Can you describe what that does? – Canadian Luke Oct 12 '12 at 06:19
  • 1
    launch the safe removal for usb – climenole Oct 12 '12 at 13:53
  • 14
    Won't I still need to click something then? – Canadian Luke Oct 12 '12 at 14:54
  • @Luke I just tried that, it brings up the Safely Remove Hardware dialog. So yes, you would still need to select the device, click Stop button, and then Close to close the dialog box. Note that the command is case sensitive, so you have to type it exactly like it says or you will get an error from RunDLL. – Samir May 25 '13 at 17:43
  • 4
    This is pretty cool, but unfortunately for automation purposes, it is no better than any of Karan’s suggestions. – Synetech Dec 05 '13 at 03:28
  • **control hotplug.dll** also works, just to add to your answer – fedmich Aug 09 '14 at 07:27
  • 1
    __control hotplug.dll__, i.e., without ___RunDLL__ doesn't work for me on Vista SP2 – user66001 Jun 25 '15 at 20:57
  • If you have to remember this command/don't like capitals much, all that is really needed (at least for me on Vista SP2) is to capitalise the __Contol_RunDLL__. I.e., __rundll32.exe shell32.dll,Control_RunDLL hotplug.dll__ – user66001 Jun 25 '15 at 21:03
  • its because function names within *.dll libraries are case sensitive, unlike most of the things in Windows which are in-case-sensitive by default –  Oct 25 '17 at 10:14
  • While I'm delighted to not go 3rd party, and your description w/ images is excellent, it's failing. Win10 recognizes "Kingston DataTraveler 3.0 USB device" but upon clicking stop and OK, "The 'Kingston DataTraveler 3.0 USB device' is not removable and cannot be ejected or unplugged." Win7 sees "Generic- Compact Flash" but it reports success after Stop and OK. Yet when I immediately reissue command on W7 without touching the drive, this time it oddly now recognizes "Kingston DataTraveler 3.0 USB device", but upon Stop and OK, " [...] device is not removable and cannot be ejected or unplugged." – MicrosoftShouldBeKickedInNuts May 17 '19 at 01:04
8

Since it's a backup device, it means it's a storage device, therefore it can be done from powershell - just replace X: with your desired drive letter:

$driveEject = New-Object -comObject Shell.Application
$driveEject.Namespace(17).ParseName("X:").InvokeVerb("Eject")
Overmind
  • 9,924
  • 4
  • 25
  • 38
  • 1
    I have seen this solution on [serverfault](https://serverfault.com/questions/130887/dismount-usb-external-drive-using-powershell) as well as on [stackoverflow](https://stackoverflow.com/questions/40285581/safely-remove-usb-drive), but I seem to be unable to get it working with my external HDD. There's no error-message, it simly does nothing. Using `"F:"` or `"F:\"` didn't make a difference, as did running PowerShell as admin. Safely removing via the Taskbar is working. What am I doing wrong? – flolilo Aug 21 '17 at 01:46
  • The actual powershell command does not return any error (red text) message ? – Overmind Aug 21 '17 at 05:55
  • If I unplug F:\ and run the command, I get an error that I can't run a method that is NULL (the message is in German, so I'm not completely sure that I got the translation right). If I run the commands with F:\ plugged in, there is no message at all - `$error` is empty, too. I'm running PowerShell 5.1 on Win10 Pro by the way. F:\ is an external USB HDD that has only one partition (F:\) - it can be safely removed via the taskbar without problems. – flolilo Aug 21 '17 at 10:08
  • Interestingly, when I use a USB-pendrive (also with one partition), it works flawlessly. Both have enabled `Better performance` in their removal policy, though that does not seem to make any difference (USB pendrive works with both settings, USB HDD doesn't). A second pendrive I own also does not like to be ejected via the PowerShell-command. **Working:** Transcend JetFlash 700 (16GB, FAT32), **Not working:** Seagate Expansion Portable 2015 (4TB, NTFS), Sandisk Extreme (32GB, exFAT). All tried out multiple times on the same USB-port. Again, safely removing via Taskbar-icon always works. – flolilo Aug 21 '17 at 12:28
  • @flolilolilo i have the same problem... –  Aug 27 '17 at 12:05
3

Couldn't find an internal command (thanks MS), not a single script out there worked either, removing letter is a poor way to do eject, interactive way is also not cool, and hate to use 3rd party tools. In my case, using something that's on my drive for 20years: the inhouse Microsoft Windows Sysinternals helps the case:

sync -e x:
  • flushes usb drive
  • ejects usb drive
  • keeps letter
  • doesn't distort USB tree

in case of locks, use Sysinternals handle or procexp to find out.

user533385
  • 51
  • 3
1

try with ejectjs.bat - it does not require external binaries.

Example usage:
::eject drive
call ejectjs.bat G
::eject all applicable drives
call ejectjs.bat *
npocmaka
  • 1,259
  • 12
  • 12
1

According to this 7tutorials-article, you can enable safe unplugging by setting "Quick removal". This will disable write caching per device, of which the performance impact is "negligible"? Their steps for Windows 7 are below.

(Edit) According to this howtogeek-article, you should still be careful when setting "Quick removal". This will disable write caching, and will thus prevent most problems. But some program(s) may still be writing stuff 'live', until explicitly ejected/removed. (End of edit)

Steps:

  • plug in the device in the USB drive
  • open Device Manager
  • expand Disk Drives
  • right-click your removable drive, e.g. "USB2.0 Flash Disk USB Device."
  • select Properties
  • click the Policies tab
  • enable "Quick removal" (disable "Better performance")

(Edit) Note that you need to use Device Manager to change the setting, it can not be done from the File Explorer. (At least in my Windows 10 edition.)

  • 1
    This sounds like a great idea for backup drives! It seems this is the default setting though (At least on my `Seagate BUP Slim BK USB External Drive`). – Arvo Bowen Apr 06 '16 at 20:57
  • 1
    Devices with write-cache enabled are not quick-removable. – Overmind Aug 22 '17 at 06:21
  • 1
    Possible to set this globally so that it applies to any and all USB storage that is attached in the future? – DuckMaestro Jul 12 '18 at 06:43
0

This option works in DOS and WSL, and ejects the device without asking any questions or popping open UI dialogues etc:-

https://gist.github.com/gitcnd/0fcc98e2dd2b18b844770666d95e8bf7

And yes, IT DOES WORK PERFECTLY (even if you're in "dos" on the "D:" drive - it still ejects fine!).

It is better to use the above original source of this answers, instead of my copy below (because copies don't get updated or have maintenance etc applied to them, like github does)... but here is all is:-

  1. Create a WSL "bash" script: /usr/local/bin/ejectusb
#!/bin/bash

cmd.exe /c start python3 C:\\windows\\ejectusb.py

-or-

  1. Create a DOS .bat file: C:\windows\ejectusb.bat
python3 C:\windows\ejectusb.py
  1. Create the ejection code: C:\windows\ejectusb.py
#!/usr/bin/python3

import string
import ctypes
from ctypes import wintypes  # Using ctypes.wintypes in the code below does not seem to work

# Ignore windows error popups. Fixes the whole "Can't open drive X" when user has an SD card reader.
ctypes.windll.kernel32.SetErrorMode(1) #type: ignore

# WinAPI Constants that we need
# Hardcoded here due to stupid WinDLL stuff that does not give us access to these values.
DRIVE_REMOVABLE = 2 # [CodeStyle: Windows Enum value]

GENERIC_READ = 2147483648 # [CodeStyle: Windows Enum value]
GENERIC_WRITE = 1073741824 # [CodeStyle: Windows Enum value]

FILE_SHARE_READ = 1 # [CodeStyle: Windows Enum value]
FILE_SHARE_WRITE = 2 # [CodeStyle: Windows Enum value]

IOCTL_STORAGE_EJECT_MEDIA = 2967560 # [CodeStyle: Windows Enum value]

OPEN_EXISTING = 3 # [CodeStyle: Windows Enum value]

# Setup the DeviceIoControl function arguments and return type.
# See ctypes documentation for details on how to call C functions from python, and why this is important.
ctypes.windll.kernel32.DeviceIoControl.argtypes = [ #type: ignore
    wintypes.HANDLE,                    # _In_          HANDLE hDevice
    wintypes.DWORD,                     # _In_          DWORD dwIoControlCode
    wintypes.LPVOID,                    # _In_opt_      LPVOID lpInBuffer
    wintypes.DWORD,                     # _In_          DWORD nInBufferSize
    wintypes.LPVOID,                    # _Out_opt_     LPVOID lpOutBuffer
    wintypes.DWORD,                     # _In_          DWORD nOutBufferSize
    ctypes.POINTER(wintypes.DWORD),     # _Out_opt_     LPDWORD lpBytesReturned
    wintypes.LPVOID                     # _Inout_opt_   LPOVERLAPPED lpOverlapped
]
ctypes.windll.kernel32.DeviceIoControl.restype = wintypes.BOOL #type: ignore



def checkRemovableDrives():
    drives = {}

    # The currently available disk drives, e.g.: bitmask = ...1100 <-- ...DCBA
    bitmask = ctypes.windll.kernel32.GetLogicalDrives()
    # Since we are ignoring drives A and B, the bitmask has has to shift twice to the right
    bitmask >>= 2
    # Check possible drive letters, from C to Z
    # Note: using ascii_uppercase because we do not want this to change with locale!
    # Skip A and B, since those drives are typically reserved for floppy disks.
    # Those drives can theoretically be reassigned but it's safer to not check them for removable drives.
    # Windows will also behave weirdly even with some of its internal functions if you do this (e.g. search indexing doesn't search it).
    # Users that have removable drives in A or B will just have to save to file and select the drive there.
    for letter in string.ascii_uppercase[2:]:
        drive = "{0}:/".format(letter)

        # Do we really want to skip A and B?
        # GetDriveTypeA explicitly wants a byte array of type ascii. It will accept a string, but this wont work
        if bitmask & 1 and ctypes.windll.kernel32.GetDriveTypeA(drive.encode("ascii")) == DRIVE_REMOVABLE:
            volume_name = ""
            name_buffer = ctypes.create_unicode_buffer(1024)
            filesystem_buffer = ctypes.create_unicode_buffer(1024)
            error = ctypes.windll.kernel32.GetVolumeInformationW(ctypes.c_wchar_p(drive), name_buffer, ctypes.sizeof(name_buffer), None, None, None, filesystem_buffer, ctypes.sizeof(filesystem_buffer))

            if error != 0:
                volume_name = name_buffer.value

            if not volume_name:
                volume_name = "Removable Drive"

            # Certain readers will report themselves as a volume even when there is no card inserted, but will show an
            # "No volume in drive" warning when trying to call GetDiskFreeSpace. However, they will not report a valid
            # filesystem, so we can filter on that. In addition, this excludes other things with filesystems Windows
            # does not support.
            if filesystem_buffer.value == "":
                continue

            # Check for the free space. Some card readers show up as a drive with 0 space free when there is no card inserted.
            free_bytes = ctypes.c_longlong(0)
            if ctypes.windll.kernel32.GetDiskFreeSpaceExA(drive.encode("ascii"), ctypes.byref(free_bytes), None, None) == 0:
                continue

            if free_bytes.value < 1:
                continue

            drives[drive] = "{0} ({1}:)".format(volume_name, letter)
        bitmask >>= 1

    return drives

def performEjectDevice(device):
    # Magic WinAPI stuff
    # First, open a handle to the Device
    #handle = ctypes.windll.kernel32.CreateFileA("\\\\.\\{0}".format(device.getId()[:-1]).encode("ascii"), GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, None, OPEN_EXISTING, 0, None )
    handle = ctypes.windll.kernel32.CreateFileA("\\\\.\\{0}".format(device[:-1]).encode("ascii"), GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, None, OPEN_EXISTING, 0, None )
    #handle = ctypes.windll.kernel32.CreateFileA("E:/".encode("ascii"), GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, None, OPEN_EXISTING, 0, None )

    if handle == -1:
        # ctypes.WinError sets up an GetLastError API call for windows as an Python OSError exception.
        # So we use this to raise the error to our caller.
        raise ctypes.WinError()

    # The DeviceIoControl requires a bytes_returned pointer to be a valid pointer.
    # So create a ctypes DWORD to reference. (Without this pointer the DeviceIoControl function will crash with an access violation after doing its job.
    bytes_returned = wintypes.DWORD(0)

    error = None

    # Then, try and tell it to eject
    return_code = ctypes.windll.kernel32.DeviceIoControl(handle, IOCTL_STORAGE_EJECT_MEDIA, None, 0, None, 0, ctypes.pointer(bytes_returned), None)
    # DeviceIoControl with IOCTL_STORAGE_EJECT_MEDIA return 0 on error.
    if return_code == 0:
        # ctypes.WinError sets up an GetLastError API call for windows as an Python OSError exception.
        # So we use this to raise the error to our caller.
        error = ctypes.WinError()
        # Do not raise an error here yet, so we can properly close the handle.

    # Finally, close the handle
    ctypes.windll.kernel32.CloseHandle(handle)

    # If an error happened in the DeviceIoControl, raise it now.
    if error:
        raise error

    # Return success
    return True


mydrives=checkRemovableDrives()
if mydrives:
    #print(mydrives)
    for drive in mydrives:
        print("Ejecting drive {0} {1}".format(drive,mydrives[drive]))
        if performEjectDevice(drive):
            print("Success")
            exit(0)
        else:
            print("Failed")
            exit(0)
else:
    print("No removable drives")

Note that I have not installed "python" on my Windows-11, it's just magically there somehow (I do use WSL (Windows Services for Linux) and Fusion360, both of which include python)

0

For those of you trying/struggling to make a functional powershell script out of the answer of Overmind, consider this:

The following sentence:

$driveEject.Namespace(17).ParseName("X:").InvokeVerb("Eject")

seems to be, somehow, asynchrounous (at least, my tests show that). This implies that if the script ends before the InvokeVerb is completed, the USB won't be removed.

To solve this, you should add a Start-Sleep -Seconds 3 instruction after the InvokeVerb("Eject") call. "3 seconds" seems to be enough time to allow the InvokeVerb("Eject") to finish. Or,

You can run the script with the -NoExit flag; however, this solution is far from perfect because such flag will leave the session open and the only way to terminate it is to type down "exit" yourself in the powershell console, killing the purpose of the script (which is to automate things!) (Important: adding exit to your script will make no difference!).

It is important to mention that, using the powershell command described previously, will unmount the flash drive (USB), but its icon will be still visible in the "This PC" window!

Carlitos Way
  • 101
  • 2