When connecting an external USB 3.0 hard drive to my USB 3.0 ports I can never safely remove it.

Somehow windows always keeps the journal files open: enter image description here "Always" as in this time I only connected the drive, copied a 10GB VM and wanted to disconnect it afterwards (like 15 minutes after copying, so all copying was done).

As you can see there is no other program keeping a handle on the disk besides System. I tried restarting explorer.exe as well as RemoveDrive.exe from Uwe Sieber. No luck, the locks on the hard drive always remain.

My only solution is just unplugging it (whereas I'm afraid of damaging the data?) or restarting the computer (always helps, doesn't it?).

Might it have something to do with me only having a SSD hard drive and the external disk is a regular drive? Might it have something to do with the USB 3.0 drivers (NEC Electronics USB Hub)? I never have this problem when using the regular USB 2.0 ports.

Any ideas on how to properly unmount the disk?

  • If any of these answers were the solution, feel free to upvote or mark them as the answer.
    – user88311
    Jun 26, 2013 at 16:54

7 Answers 7


I came by looking for a possible explanation or easier (read: automated/scripted) way to clear this "lock" on the MFT/TxF/NTFS metadata. Thought I'd throw this out there, as I have a solution that has worked for me in countless situations. I have used it to remove all manner of USB and eSATA drives that get stuck like this. The issue does seem to be primarily removable drives that mount as fixed drives, such as those in an eSATA dock or USB enclosure. USB thumb drives generally don't seem to exhibit this issue for me.

An item of note on this last distinction: the Sandisk Extreme USB 3.0, an odd beast comprised of an SSD controller in a USB key's body, also shows up as a fixed drive, though it does seem to have no issue being pulled unceremoniously and without any safe removal being done, so I'm guessing it at least turns off any write caching due to its speed and potentially something else as well, as it never seems to have this issue, always retaining its instant removability. Not necessarily a perfect example, as I haven't been thorough in my testing (this is just anecdotal) but it may shed a little light on this due to its "fixed" nature, yet apparent lack of susceptibility to this issue. Just food for thought.

<-- The Solution -->

Anyways, simply put, you need to offline the drive. You can do this in one of two ways. Note: There are slightly shorter ways to do this, but here are the ridiculously thorough steps because I don't know my audience. The GUI method is by far the fastest, owing to the fact that diskpart.exe doesn't take switches or in-line commands/arguments.

  1. GUI: Run -> "diskmgmt.msc" -> Find your drive in the physical disk list (bottom pane) -> right-click the drive (the left-most part), not the partition -> Click "Offline"


  1. CLI: Run -> "cmd.exe" -> type "diskpart" -> type "list disk", find your disk # -> type "select disk x", where x is your disk's # from the last step -> type "offline disk". Now you can exit the command prompt or just type "exit" at diskpart, then close the prompt.


  • All that's important should be to offline the volume as this will remove NTFS' hold on the drive, but offlining the disk is simpler and more thorough.

  • The disk #s are always identical between diskpart.exe and diskmgmt.msc because they're pulling the info from the same place, just in case you're curious/worried/cautious.

  • 1
    Rook, this looks great. Can't wait to try. And yes, this always happens with fixed drives for me - usually external drives hosting VMs. One question remains: After setting the external drive offline what then? Just unplug? Safely remove?
    – Dennis G
    Nov 11, 2013 at 8:57
  • This worked for me.
    – hattenn
    Apr 15, 2014 at 22:38
  • This looks useful, thanks. The answer by @elieux is simplest if it's just Task Manager causing the issue.
    – Reg Edit
    Apr 26, 2015 at 9:57
  • Just revisiting some old questions, and I checked out the link to the Uwe Sieber removedrive.exe you noted, and I have a feeling it would work via the same mechanism (offlining and dismounting are pretty close in terms of their practical implications, the former being for a physical drive (emulated or not, like an iSCSI volume) and the latter being for a mounted partition/volume (i.e. C:, X: etc)... not sure about how similarly they work under the sheets) if you used the "-e" option. Per the removedrive.exe instructions: ""[-e] try to dismount and eject if the removal fails""
    – Rook
    Sep 20, 2015 at 22:37
  • Lastly, it looks like Uwe Sieber himself explains the underpinnings of the mechanisms at play at the code/API and error levels: codeproject.com/Articles/13839/…
    – Rook
    Sep 20, 2015 at 22:43

Today, it occured to me to look in the event log. I found this right after the removal attempt:

log: System, source: Kernel-PnP, event ID: 225, level: warning

The application \Device\HarddiskVolume2\Windows\System32\Taskmgr.exe with process id 6436 stopped the removal or ejection for the device [...]

So I closed Task Manager and Safe Remove worked.

  • Excellent! This solved the issue for me. Now why couldn't Microsoft have put that information in the dialog that says "a program" is still using the drive!
    – Reg Edit
    Apr 26, 2015 at 9:43
  • Great, this solved the issue for me, too. Windows 10. Found that I had Taskmgr in Autostart. So, why does Taskmgr lock USB drives?
    – weberjn
    Jul 3, 2016 at 9:09
  • although offlining (see @rook's answer) and fsutil stuff has worked in the past for me, today it didn't. ProcessExplorer thought it was only "system" doing the locking. In any case, EventViewer showed the same culprit as you (TaskManager), so I closed that out and I was golden.
    – mpag
    Mar 15, 2018 at 20:36

I created this batch script to "unlock" any volume. Just run the .bat script as administrator, select the volume, and press ENTER. After it you should be able to use "Safe remove" as usual to detach the unit.

@echo off

set tempfile="%TEMP%\diskscrp.dsk"

echo   === Disk removal tool ===
echo   Select the disk volume number
echo   (if the disk has multiple volumes, select any of them)
echo list volume | diskpart | findstr /C:Volume /C:---
set /p volume="   Selected volume: "

echo select volume %volume% >>%tempfile%
echo offline disk >>%tempfile%
echo online disk >>%tempfile%

diskpart /s %tempfile% | findstr /C:"not valid"

if "%ERRORLEVEL%"=="1" (
  echo   Disk has been unlocked successfully.  Try to safely remove it now.

del /F %tempfile%

This script is based on @Rook suggestion, so it uses diskpart to make the disk offline. When this is done, all handles are forcibly closed. The difference in this script is that it automatically make the disk back online, so it can be recognized the next time it is connected to the system.

  • Sweet! Haven't used it but I appreciate your initiative in making it easier for everyone else... I've gotten a few other utilities that give more info (i.e. Hotswap!: mt-naka.com/hotswap/index_enu.htm) about removable/fixed drives than the built-in windows one, but haven't found a quick and dirty offline-based solution, so this is great!
    – Rook
    Sep 20, 2015 at 22:29

A large fraction of external drive/Windows OS combos have this problem, maybe most.

What I do is sleep my box (a laptop) and wait the ten seconds it takes for the external drive to power down (I can hear it). Then unplug.

If the system is asleep then all I/O operations are complete & the I/O bus is quiesced. Waiting for the drive to power down is "belt and suspenders" on top of that.

(Note that if one is too paranoid for that approach, doing a hibernate should be fully sufficient. Full power off should not be required.)

  • A workaround, but that should work.
    – Dennis G
    Jan 28, 2013 at 23:10

For now you can just attempt to disconnect the external by shutting the computer down and then unplugging it, therefore attempting data loss and then setting it up for easy removal as to prevent data loss when simply unplugging it without unmounting it.

To be honest it sounds sort of like a MBR error where the drive is stuck seeing itself as always plugged in, in which case if you were to unplug the drive while powered on you could damage the MBR and leave you with 2 options, manually repairing the MBR or attempting to use software like MBR repair to be able to access the drive again, or use software like gparted to format the disk again and set a new partition table where the error most likely occurred.

  • "then setting it up for easy removal" <- could you elaborate what you mean? How would I know that the drive thinks it's always plugged in, i.e. not being an external USB drive?
    – Dennis G
    Sep 30, 2012 at 21:51
  • Plug your drive in again once it has been removed in the powered down state and the computer has been started up again, properties, hardware, click the drive, properties, policies, optimize for quick removal. EDIT: In your question you state that it IS in fact a external usb drive.
    – user88311
    Sep 30, 2012 at 21:56
  • In most cases the system installs external drives with the "quick removal" flag set. And, I gather, this setting is supposed to make it "highly unlikely" that simply unplugging the drive will cause problems. Jan 28, 2013 at 23:03

I believe these files belong to the Transactional NTFS (TxF).

I hear Transactional NTFS is used by autoupdate, but have no clue why the system would want to place this on an external disk and then be unable to stop it upon safe removal request. Fsutil resource info doesn't show any activity.

Try in the cmd console:

fsutil resource stop E:

or, if it doesn't help,

fsutil resource setautoreset true

and reboot. You can also try stopping a TxF-related service in Computer Management / Services

  • This is pretty interesting stuff! I'll look into it the next time it happens.
    – Dennis G
    Dec 8, 2012 at 19:08
  • 2
    But... doesn't work. When executing fsutil resource stop <drive:> sysinternals handle.exe doesn't show any handles. So they are removed, but when I then try to safely remove it, the handles are back where they were.
    – Dennis G
    Dec 10, 2012 at 20:21

I had the same thing happening with a flash drive recently. Like you, I kept showing active $Extend handles and assumed they were preventing me from removing the drive safely. I stumbled across this question and tried Sem's fsutil suggestion to no effect. What did work for me was manually unmounting the drive. Since my flash drive was mounted as F:, I ran:

mountvol f: /d

I then unplugged the drive, plugged it back in, remounted it using mountvol f: <volumename> and used it for a while. When I was finished, I checked the active handles and saw the same $Extend entries I noticed previously. When I tried to do the 'normal' safe removal though, it succeeded despite the active handles.

I don't know if it was sheer chance that this worked for me, but I'm adding it here in case it helps anyone else.

  • 1
    I think the $extend stuff is a red herring -- there's some other reason that keeps Windows from dismounting the drive. Jan 28, 2013 at 23:06
  • Agreed, that realization was the biggest reason I posted this answer. I had been chasing $extend issues pointlessly, and discovered that those handles don't cause any problems with safe removal. I just hope that since that red herring got me to this question, maybe this answer will help the next unlucky fisherman :).
    – ajk
    Jan 28, 2013 at 23:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .