Vista refuses to safely remove external usb hard drive

[Roof Fiddler]

I have no programs accessing anything on my external usb hd, and no explorer
windows or command prompts running. The activity light on the drive shows no
activity. When I click the "safely remove hardware" icon in the task tray
and click "safely remove usb mass storage device - drive (f:)" it says
"Windows can't stop your 'generic volume' device because it is in use." and
immediately the external drive goes into a flurry of activity with its
activity light staying on almost constantly. Windows resource monitor shows
that svchost is the culprit, reading the drive at about 2MB/sec
continuously. Sysinternals process explorer confirms that nothing besides
"System" and "svchost.exe" have any handles open for the drive. The disk
activity continues for several minutes, then stops. If I try "safely remove
hardware" again, it again refuses, and goes into another flurry of disk
activity. The result is that I can't safely remove the device, unless I shut
down the machine first, which kind of defeats the point of usb drives being
hot pluggable. This is infuriating.

[Alexander Suhovey]

I've seen this happening on XP too every now and then, so there's nothing
new in this behavior on Vista. Two ways I usually troubleshoot/workaround
this issue: configuring drive for quick removal and tracking down offending
process.

1. To configure drive for quick removal, Open Device Manager; expand "Disk
drives" node; double click drive in question; on the Policies tab make sure
"Optimize for quick removal" radio-button is checked. This will slow down
file operations on the drive but will allow you to remove it at any moment
without even using (sometimes failing) "Safe Removal" function.

2. Two usual suspects that can keep your USB drive busy are System Restore
and Indexing. I'd check their settings to see if your system configured to
either create restore points for this drive or to index its contents for
instant search. Also, I'd find out exact instance of svchost that has
handles open to this drive and which services are running under this
instance. I use Sysinternals' handle.exe and built-in tasklist.exe
command-line utilities for this. First, you run

handle DRIVE:

to get PIDs of processes that have handles open on the drive. Then you can
run

tasklist /SVC /FI "PID eq PROCESS_ID"

where PROCESS_ID is the PID you've got from handle. If it's svchost that has
handles open, you'll get the list of services that run under this instance
of svchost.

To get friendly names of services, you can use sc.exe built-in utility:

sc qc SERVICE_NAME | find /i "DISPLAY_NAME"

where SERVICE_NAME is the name you've got from taskilst output.

Example:
======================8<========================
C:\>handle H:\

Handle v3.2
Copyright (C) 1997-2006 Mark Russinovich
Sysinternals -

System pid: 4 1C8:
H:\$Extend\$RmMetadata\$TxfLog\$TxfLogContainer00...
System pid: 4 270:
H:\$Extend\$RmMetadata\$TxfLog\$TxfLog.blf
System pid: 4 27C:
H:\$Extend\$RmMetadata\$TxfLog\$TxfLogContainer00...
System pid: 4 288: H:\$Extend\$RmMetadata\$Txf
System pid: 4 368: H:\System Volume
Information\{3808876b-c176-4e48-b7...
System pid: 4 36C: H:\System Volume
Information\{477ccf48-a888-11db-b5...
svchost.exe pid: 1148 5BC: H:\$Extend\$ObjId
svchost.exe pid: 1148 5C4: H:\System Volume Information\tracking.log

C:\>tasklist /SVC /FI "PID eq 1148"

Image Name PID Services
=============== ========= =======================================
svchost.exe 1148 AudioEndpointBuilder, CscService,
EMDMgmt,
hidserv, Netman,
PcaSvc, SysMain,
TabletInputService,
TrkWks, UmRdpService,
UxSms,
WdiSystemHost, WPDBusEnum, wudfsvc

C:\>sc qc AudioEndpointBuilder | find "DISPLAY_NAME"
DISPLAY_NAME : Windows Audio Endpoint Builder

C:\>sc qc CscService | find "DISPLAY_NAME"
DISPLAY_NAME : Offline Files

C:\>sc qc EMDMgmt | find "DISPLAY_NAME"
DISPLAY_NAME : ReadyBoost

C:\bin>
======================8<========================

[Uwe Sieber]

This is a known bug in XP that seems to be still present in Vista.
When a save removal is tried Windows can send a message about that
and all processes that hold open but non essential handles should
close them now. But the indexing service doesn't care.

My commandline tool RemoveDrive can prepare a drive for save removal:

Started with parameter -i it stops the indexing service for a moment.
Horrible workaround, but it works...
Sample:
removedrive u: -i

For stopping a service admin previleges are required.

[Roof Fiddler]

I'd already rebooted the machine in order to
safely remove the drive by the time I got your message, but I tried your
suggestions just now and the svchost with handles open on the drive has the
services
Windows Audio Endpoint Builder
ReadyBoost
Infrared monitor service
Network Connections
Program Compatibility Assistant Service
Superfetch
Tablet PC Input Service
Distributed Link Tracking Client
Desktop Window Manager Session Manager
Diagnostic System Host
WLAN AutoConfig
Portable Device Enumerator Service
The only services in that list I can think might be using the drive are
readyboost and superfetch. The drive is a regular hard drive, not a flash
drive, so readyboost wouldn't be using it, so that leaves just superfetch.
But I don't know if this current service list is the same as it was
yesterday when I was unable to safely remove the drive, and I can't test now
because I'm using the drive. If I'm again unable to remove the drive the
next time I try, I'll check the services again and post the list.

The drive is not set "Optimize for quick removal" because even if it were I
wouldn't want to remove it without successfully using the "safe removal"
function. Using optimize for quick removal might prevent filesystem
corruption when I just unplug it with no warning, but it won't prevent
potential data loss or other problems with programs which actually have
handles open on the drive for legitimate reasons. I guess I could manually
check the handles every time before yanking the drive but I really want to
be able to use the "safe removal" function as an easy reminder that I might
have forgotten to close some file I had open on the drive.

System Restore is turned off, and indexing is not enabled for this drive.

[Opinicus]

Will Vista stop turning System Restore on every time I connect a USB drive?

If it will, that's reason enough to move on from WinXP in my book.

I can see your point, but turning off write cache doesn't remove tray icon
so you can still use it to safely remove your USB drive.

Yes, is activates it on the system volume only. Indeed unbelievable
that this nonsense behaviour hasn't been fixed in five years.

Better late than never. Where do I sign up?

I've found that stopping the 'Windows Search' service solves this problem for me. Stop the service, do a 'Safely Remove' on the drive, then start it back up.

Windows Search is not set up to index that drive, but it seems to prevent it from ejecting anyway, not sure why.

[Roof Fiddler]

I just now tried to safely remove the drive again, and Vista is refusing, so
I performed the checks you suggested:
C:\>handle f:

Handle v3.2
Copyright (C) 1997-2006 Mark Russinovich
Sysinternals - www.sysinternals.com

System pid: 4 C58:
F:\$Extend\$RmMetadata\$TxfLog\$TxfLog.blf
System pid: 4 D3C: F:\$Extend\$RmMetadata\$Txf
System pid: 4 DE0:
F:\$Extend\$RmMetadata\$TxfLog\$TxfLogConta
iner00000000000000000001
System pid: 4 E04:
F:\$Extend\$RmMetadata\$TxfLog\$TxfLogConta
iner00000000000000000002
System pid: 4 EA4: F:\System Volume
Information\{3808876b-c176
-4e48-b7ae-04046e6cc752}
System pid: 4 EC0: F:\System Volume
Information\{4efbe3e4-aeb6
-11db-883c-005056c00008}{3808876b-c176-4e48-b7ae-04046e6cc752}
svchost.exe pid: 1084 920: F:\System Volume
Information\tracking.log
svchost.exe pid: 1084 934: F:\$Extend\$ObjId
svchost.exe pid: 1084 944: F:

C:\>tasklist /svc /fi "pid eq 1084"

Image Name PID Services
========================= ========
============================================
svchost.exe 1084 AudioEndpointBuilder, EMDMgmt, Irmon,
Netman, PcaSvc, SysMain,
TabletInputService, TrkWks, UxSms,
WdiSystemHost, Wlansvc, WPDBusEnum

C:\>sc qc AudioEndpointBuilder | find /i "display_name"
DISPLAY_NAME : Windows Audio Endpoint Builder

C:\>sc qc EMDMgmt | find /i "display_name"
DISPLAY_NAME : ReadyBoost

C:\>sc qc Irmon | find /i "display_name"
DISPLAY_NAME : Infrared monitor service

C:\>sc qc Netman | find /i "display_name"
DISPLAY_NAME : Network Connections

C:\>sc qc PcaSvc | find /i "display_name"
DISPLAY_NAME : Program Compatibility Assistant Service

C:\>sc qc SysMain | find /i "display_name"
DISPLAY_NAME : Superfetch

C:\>sc qc TabletInputService | find /i "display_name"
DISPLAY_NAME : Tablet PC Input Service

C:\>sc qc TrkWks | find /i "display_name"
DISPLAY_NAME : Distributed Link Tracking Client

C:\>sc qc UxSms | find /i "display_name"
DISPLAY_NAME : Desktop Window Manager Session Manager

C:\>sc qc WdiSystemHost | find /i "display_name"
DISPLAY_NAME : Diagnostic System Host

C:\>sc qc Wlansvc | find /i "display_name"
DISPLAY_NAME : WLAN AutoConfig

C:\>sc qc WPDBusEnum | find /i "display_name"
DISPLAY_NAME : Portable Device Enumerator Service

How do I find out which of those 12 services is the culprit?

More info:
A file which I used earlier on F is foo.tc (a truecrypt volume). Before I
attempted to safely remove F, I of course dismounted foo.tc and shut down
truecrypt. "handle f:" as I showed in my previous post confirms that
truecrypt isn't accessing anything on F, and windows task manager's process
list confirms that truecrypt isn't running, and no other program on my
system uses .tc files, so nothing has any business accessing that file now.
But every time I try to safely remove F, Vista refuses and simultaneously
svchost.exe (PID 1084) begins reading f:\foo.tc at about 15MB/sec for
several minutes. It has NO BUSINESS doing that! As I mentioned before,
system restore is turned off (for all drives) and indexing is turned off for
F.
So one of the following services is reading f:\foo.tc for no good reason:
Windows Audio Endpoint Builder, ReadyBoost, Infrared monitor service,
Network Connections, Program Compatibility Assistant Service, Superfetch,
Tablet PC Input Service, Distributed Link Tracking Client, Desktop Window
Manager Session Manager, Diagnostic System Host, LAN AutoConfig, Portable
Device Enumerator Service.
How do I find out which one?

[Alexander Suhovey]

Well, depending on TrueCrypt volume size, this may be directly related to
the issue. In my experience most of problems with ejecting USB volumes on XP
were related to working with big files (like ISO images or virtual hard
disks).

At this point I can only guess that this has something to do with write
caching/superfetch when working with big files. Even if you dismount
TrueCrypt volume and close program, there still can be data in cache waiting
to be written down to spindles.

One thing I'd try is sync.exe utility by Mark Russinovich. It forces all
file system data to be flushed to disks, including removable ones.
http://www.microsoft.com/technet/sys...Disk/Sync.mspx

Unfortunately I cannot reproduce the problem at will so I can't say if it
will actually work but I think it worth a try.

And if it doesn't help, I'd still try to turn write caching off on USB disk
in question to see if (1) problem goes away and (2) loss of performance is
tolerable. As I mentioned earlier, you will still be able to use "Safely
Remove" feature, it just will not be mandatory.

[kkumar176]

Vista 64 bit have solution in Microsoft, we can request a fix and it will be send by email for free

I have another interesting tool which should called in cmd as shown in clip_3.jpg below, (my removable drive 500GB transcend is removed successfully only by this tool)

RemoveDrive V1.9.1 - prepares removable drives for safe removal
Freeware by Uwe Sieber -

Works under Windows 2000, XP, Server 2003 and Vista only.

Usage:
RemoveDrive DriveSpec: [-l][-h][-w:nnnn]

DriveSpec: is the drive to remove, e.g. U: or \ for the current drive
[-l] loop until success
[-h] show open handles (admin rights required, exprimental)
[-w:nnnn] wait nnnn milliseconds before close
[-d] show debug information

[treboreevob]

For anyone having this problem, I've found that if you open task
manager, click 'end process' on explorer.exe, and then click file: new
task, and enter explorer.exe, you should then be able to safely remove
your usb device.

(sorry if this was already suggested, but I was having the same
trouble, and thought I would share what worked for me)

My "solution" solved the problem. I found the same remedy on a
different forum site.

The fact that it works (on my vista-based machine) should be enough to
take the word "solution" out of quotations, because it is no longer a
hypothetical method, but a viable one.

Another FACT, is that this problem is still going unanswered. Just
because the thread is old, does not mean that there are no recurrences
of the problem. I posted the same results on another forum, where users
were claiming to have no solution to this problem as of May of this
year.

You've got that all wrong, kiddoo, no one here 'needs' to do anything.
Our help is totally voluntary and from the goodness of our hearts.
You care to 'review'?

Just hang in there and someone might be able to help you.
Your particular problem exceeds the scope of my expertise.
Sorry about that.

[jasoncollege24]

I too have this exact same problem with no viable solution. Using sysinternals Process Explorer I found that the open handles are from "System" with a PID of 4. When I right click the specific handle for "G:\$Extend\$RmMetadata\$TxfLog\$TxfLogContainer00000000000000000002" and choose properties, Process explorer tells me that it is file, endpoint builder, or driver. My F:\ drive and G:\ are the same drive split in two partitions. it did this once with the F:\ partition, and didn't do it again for that one, but refusecd to let go of my G:\ partition.

Seriously... someone needs to give a viable solution that does not involve ending the Explorer.exe process as this is not how the system is supposed to operate, and ending explorer tends to cause other issues as well.

actually yes... honestly, i'm not usually like that. I do sincerely apologize. Seems this particular issue is part of a very long list of things that finally got to me...

would still like some help to try to solve this issue. I've had it happening for at least a month on my system, but i haven't changed anything that would cause it to do this. Since my iTunes library is on the G: drive, shutting down iTunes, emptying the recycle bin, and ending the iTunes helper process usually would allow me to remove the drive safely.

Today is actually the first time I've seen the file entry that i mentioned earlier for the USB disk. other times, i never bothered to run process explorer after i realized it was iTunes causing the problem before, but lately I've had to either shut down, hibernate, or put the computer to sleep to remove the drive.

My earlier point of ending the explorer.exe process is a valid one. Ending explorer.exe then restarting it, can generally fail to load some of the icons that i need in the system tray (like my battery, network, and volume icons in Vista). This causes me to have to restart my computer to get those back, which kinda defeats the purpose anyway.

[alexdrudi]

Same files open for me. Solved stopping "Windows Search" service for a few seconds.

Uwe Siebers' workaround didn't work for me (it kept retrying to stop the service with no success).

I remember in a similar situation the culprit one of the "Google*" processes, I killed it and the drive could be removed safely. Unfortunately I can't reproduce the situation and I don't remember the exact name so I can't be more specific on this.

As a sidenote, I believe the OS should be able to solve the problem by itself, since this is a serious data integrity issue