"Problem ejecting USB mass storage device"

[VanguardLH]

While SysInternals' Process Explorer has been mentioned, I think their
ProcMon would be better suited. You can filter its captured output to
just show file accesses and even designated the Path to have the drive
letter of the USB-attached drive. Then try to Stop and then Eject the
USB drive and see what might still be accessing the drive.

 

[Gene E. Bloch]

While SysInternals' Process Explorer has been mentioned, I think their
ProcMon would be better suited. You can filter its captured output to
just show file accesses and even designated the Path to have the drive
letter of the USB-attached drive. Then try to Stop and then Eject the
USB drive and see what might still be accessing the drive.

Thanks for that info.

ProcMon generates so much output that it intimidated me - and I never
discovered the above. Which I'm saving.

 

[Paul]

While SysInternals' Process Explorer has been mentioned, I think their
ProcMon would be better suited. You can filter its captured output to
just show file accesses and even designated the Path to have the drive
letter of the USB-attached drive. Then try to Stop and then Eject the
USB drive and see what might still be accessing the drive.

It's handles to files that prevent dismounting, rather than file I/O.

The handle is a safer criterion, as it avoids a race condition
on a program attempting a write() just as the file system is
being dismounted. It means fewer fragments. And helps with the
less protected file systems, such as FAT32.

Paul

 

[VanguardLH]

Thanks for that info.

ProcMon generates so much output that it intimidated me - and I never
discovered the above. Which I'm saving.

I used to use their RegMon and FileMon and still prefer the separated
functionality. Then they merged it into ProcMon and removed the
downloads for RegMon and FileMon. So I eventually bit the bullet and
figured out how to use ProcMon as best as I could. I took awhile for me
to even realize the 4 toolbar buttons that toggle what type of
monitoring is performed:

Show registry activity
Show file system activity
Show network activity
Show process and thread activity
Show profiling events

Typically all I use are the registry and file monitoring. I have other
tools for monitoring network activity. I'm not wizard enough to know
how the process and thread activity would help me and haven't a clue
what they mean by profiling events.

Eventually I figured out how to modify the filtering. I could, for
example, add a drive and folder path in a Path rule when I wanted to
find out what was accessing that folder or files within it. I've also
use the Process Name filter when I want to see what a particular program
is accessing. But there's a ton of features and uses for this program
that I haven't touched nor understand.

 

[VanguardLH]

It's handles to files that prevent dismounting, rather than file I/O.

File and directory queries don't require opening files. Deletes are (or
should be) performed after you already used CloseHandle. From ProcMon's
help:

File System
Process Monitor displays file system activity for all Windows file
systems, including local storage and remote file systems.

CreateFile (which creates a file handle) is also a file system activity.
If the *file system* isn't quiescent, can you eject the drive?

 

[Jeremy Lin fan]

I used to use their RegMon and FileMon and still prefer the separated
functionality. Then they merged it into ProcMon and removed the
downloads for RegMon and FileMon. So I eventually bit the bullet and
figured out how to use ProcMon as best as I could. I took awhile for me
to even realize the 4 toolbar buttons that toggle what type of
monitoring is performed:

Show registry activity
Show file system activity
Show network activity
Show process and thread activity
Show profiling events

Someone's probably going to ask how they got 5 kinds of monitoring
into 4 buttons.

 

[VanguardLH]

Someone's probably going to ask how they got 5 kinds of monitoring
into 4 buttons.

That would be you.

Okay, a typo. It's 5 toolbar buttons. Hey, the 5 key is right next to
the 4 key. I type pretty fast and my fingers don't always obey.

 

[Paul]

File and directory queries don't require opening files. Deletes are (or
should be) performed after you already used CloseHandle. From ProcMon's
help:

File System
Process Monitor displays file system activity for all Windows file
systems, including local storage and remote file systems.

CreateFile (which creates a file handle) is also a file system activity.
If the *file system* isn't quiescent, can you eject the drive?

CreateFile returns an open handle. The text here suggests "CloseHandle"
when done with it. This is no different than doing something like fopen().

http://msdn.microsoft.com/en-us/library/aa914735.aspx

A handle is a persistent object, and we'd be concerned about
things like that which can have a half-written file in progress.
Waiting for a handle to close, means the application has either
abandoned a file it was writing, or it has committed it.

Any operation which is transient, or is handled entirely by the
file system (say, writing to the MFT), isn't of as much concern,
as when a process or application has a half-written file sitting there.
Serialization can be applied to stuff the file system controls.
(Which means, it doesn't dismount the file system, until it's stopped
modifying the MFT.)

So Handle or Process Explorer (with Handle program functions built-in)
is the tool to use.

Paul

 

[VanguardLH]

CreateFile returns an open handle. The text here suggests "CloseHandle"
when done with it. This is no different than doing something like fopen().

http://msdn.microsoft.com/en-us/library/aa914735.aspx

A handle is a persistent object, and we'd be concerned about
things like that which can have a half-written file in progress.
Waiting for a handle to close, means the application has either
abandoned a file it was writing, or it has committed it.

Any operation which is transient, or is handled entirely by the
file system (say, writing to the MFT), isn't of as much concern,
as when a process or application has a half-written file sitting there.
Serialization can be applied to stuff the file system controls.
(Which means, it doesn't dismount the file system, until it's stopped
modifying the MFT.)

So Handle or Process Explorer (with Handle program functions built-in)
is the tool to use.

So we're in agreement regarding created/open file handles. Okay, so
what happens to a dismount when there still exists file system activity
OTHER than file handles that were created before and are lingering
around but are NOT part of the current file system activity, like when
"file system activity" consistutes just queries and deletes? That's the
reason why some folks mentioned looking at file indexing (which only
looks at files and not their contents) which could keep a volume from
getting dismounted.

I was wondering if a volume with current activity (and no open file
handles) could block an eject. You'd *think* the mount manager would go
ahead and dismount the volume (again, with one having no currently open
file handles) with the result any processes that were attempting
[non-write] file system activity would get errors (volume not
accessible) but maybe not hence my question "If the *file system* isn't
quiescent, can you eject the drive?"

 

[VanguardLH]

CreateFile returns an open handle. The text here suggests "CloseHandle"
when done with it. This is no different than doing something like fopen().

http://msdn.microsoft.com/en-us/library/aa914735.aspx

A handle is a persistent object, and we'd be concerned about
things like that which can have a half-written file in progress.
Waiting for a handle to close, means the application has either
abandoned a file it was writing, or it has committed it.

Any operation which is transient, or is handled entirely by the
file system (say, writing to the MFT), isn't of as much concern,
as when a process or application has a half-written file sitting there.
Serialization can be applied to stuff the file system controls.
(Which means, it doesn't dismount the file system, until it's stopped
modifying the MFT.)

So Handle or Process Explorer (with Handle program functions built-in)
is the tool to use.

So we're in agreement regarding created/open file handles. Okay, so
what happens to a dismount when there still exists file system activity
OTHER than file handles that were created before and are lingering
around but are NOT part of the current file system activity, like when
"file system activity" consistutes just queries and deletes? That's the
reason why some folks mentioned looking at file indexing (which only
looks at files and not their contents) which could keep a volume from
getting dismounted.

I was wondering if a volume with current activity (and no open file
handles) could block an eject. You'd *think* the mount manager would go
ahead and dismount the volume (again, with one having no currently open
file handles) with the result any processes that were attempting
[non-write] file system activity would get errors (volume not
accessible) but maybe not hence my question "If the *file system* isn't
quiescent, can you eject the drive?"

I did an experiment (but I only had Windows XP at home where I was when
I ran the test). I copied a ton of folders and files onto a USB thumb
drive (drive f). I had the "Safely Remove Hardware" wizard on screen.
In a command shell, I ran "dir f: /s". With the large number for
folders and files to run through, the 'dir' command would take awhile.
While the 'dir' was running, I attempted to stop the USB device in the
"Safely Remove Hardware" wizard but got the following error popup:

The device 'Generic volume' cannot be stopped right now. Try stopping
the device again later.

Then I tried to eject the drive without first stopping it while running
the 'dir' command again and got:

'Remove Disk (F' is currently in use. If you eject this disk now,
you may lose data in any open files. Before ejecting the disk, make
sure that all files are closed and no multimedia files (such as music
or video) are playing.

Cancel Try Again Continue

I had the option to Continue but the 'dir' finished before I had a
chance to click on it. In any case, a read-only command generating lots
of file system activity was causing the drive to be in use and
interferring with a dismount.