Safely remove external USB drive fails due to $extend
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:
"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?
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.
- 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"
Or:
- 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.
Notes:
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.
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.