"Problem ejecting USB mass storage device"

On Tue, 16 Oct 2012 14:07:29 -0700, "Gene E. Bloch"
wrote:

On Tue, 16 Oct 2012 14:05:02 -0700, Gene E. Bloch wrote:

On Tue, 16 Oct 2012 19:37:04 +0100, Jeff Layman wrote:

As I mentioned, when a USB device sticks, I just pull the plug anyway.
Never had a problem doing that. Try it next time it happens to you.

No thanks. I'm (usually) too paranoid.

What I decided to do about EaseUS's propensity to lock the drive was to
uninstall it. That was earlier this month, but I didn't mention it in my
first post.

I'll also look at UnLock IT that Jeff Layman mentioned in this thread. I
guess I'll have to reinstall EaseUS to try it :-)

I had to laugh at the last sentence I wrote above. I'll bet you know who
Jeff layman is :-)

Nice. I've done that. :-)

--

Char Jackson

On 10/16/2012 5:07 PM, Gene E. Bloch wrote:
On Tue, 16 Oct 2012 14:05:02 -0700, Gene E. Bloch wrote:

On Tue, 16 Oct 2012 19:37:04 +0100, Jeff Layman wrote:

As I mentioned, when a USB device sticks, I just pull the plug anyway.
Never had a problem doing that. Try it next time it happens to you.

No thanks. I'm (usually) too paranoid.

What I decided to do about EaseUS's propensity to lock the drive was to
uninstall it. That was earlier this month, but I didn't mention it in my
first post.

I'll also look at UnLock IT that Jeff Layman mentioned in this thread. I
guess I'll have to reinstall EaseUS to try it :-)

I had to laugh at the last sentence I wrote above. I'll bet you know who
Jeff layman is :-)


Recently, I did have problems with USB memory sticks similar to those in
this thread.
When all was said and done.
On a multiple file bulk write by a vendor, the last file might not be
complete as to data in the file, or table entries for the file.
On initial plug in to a USB port, Win 7 might offer to "repair" the
memory stick.

What seemed to be the cause?
The stick was written with XP, and pulled when XP showed the write was
complete without going thru the safe to remove process.

If I remember correctly, there are HD related "speed up" options that
might have been in effect. Directly or indirectly, these may have been
involved.

Normally, when I have USB memory stick problems, it's either a flaky
memory stick, or poor connections to the USB port.

On 16/10/2012 21:12, VanguardLH wrote:
"Jeff Layman" wrote:

Win7HPx64.

"Windows can't stop your "XXXXX USB device" because a program is still
using it. Close any programs that might be using the device, and then
try again later"

I see this message far too often. Sometimes, it's a simple matter - the
last thing I used a File Manager for before closing it was to examine
the files on a memory stick or external hard disk. I just open it
again, and look at the files on something else, such as the internal HD.
Then the USB device can be ejected.

Sometimes that doesn't work, and nothing else does, and I just pull the
plug. Doesn't seem to do any damage.

Is there anywhere (eg Administrative Tools) where you can find out what
Win7 /thinks/ is still using the USB device? Seems a bit of a pointless
message otherwise.

You mention ejecting the USB drive. You never mentioned trying to first
stop it.

Do you stop the USB drive /BEFORE/ you try to eject it?

No. Just googled how to do that. I'll try it, but I'm not convinced it
will work as if Windows itself can't stop it automatically, I'm not sure
I will be able to do any better.

Did you choose to include your USB drive in Windows Search service
(which means the searchindexer.exe process might be accessing that
drive)? If so, do you need to index the files (and perhaps their
content) on that drive? If you only need to index the files on that
drive, don't have Windows Search indexing on the contents of those
files.

I turned off Windows Search the day I got Win7. The service has also
been disabled, so there is no chance of it trying to access the USB drive.


--

Jeff

On 16/10/2012 22:07, Gene E. Bloch wrote:
On Tue, 16 Oct 2012 14:05:02 -0700, Gene E. Bloch wrote:

On Tue, 16 Oct 2012 19:37:04 +0100, Jeff Layman wrote:

As I mentioned, when a USB device sticks, I just pull the plug anyway.
Never had a problem doing that. Try it next time it happens to you.

No thanks. I'm (usually) too paranoid.

What I decided to do about EaseUS's propensity to lock the drive was to
uninstall it. That was earlier this month, but I didn't mention it in my
first post.

I'll also look at UnLock IT that Jeff Layman mentioned in this thread. I
guess I'll have to reinstall EaseUS to try it :-)

I had to laugh at the last sentence I wrote above. I'll bet you know who
Jeff layman is :-)

Not sure, but he keeps signing the emails I send... :-)

--

Jeff

On Wed, 17 Oct 2012 03:45:42 -0400, charlie wrote:

[snip]

Recently, I did have problems with USB memory sticks similar to those in
this thread.
When all was said and done.
On a multiple file bulk write by a vendor, the last file might not be
complete as to data in the file, or table entries for the file.
On initial plug in to a USB port, Win 7 might offer to "repair" the
memory stick.

What seemed to be the cause?
The stick was written with XP, and pulled when XP showed the write was
complete without going thru the safe to remove process.

If I remember correctly, there are HD related "speed up" options that
might have been in effect. Directly or indirectly, these may have been
involved.

Normally, when I have USB memory stick problems, it's either a flaky
memory stick, or poor connections to the USB port.

I have had (and posted about) problems with memory sticks.
Usually, I copy XP to 7 and only occasionally the other way around. I
am very careful about unmounting. I still see the problem from time
to time. The trouble is in clusters. It will be fine, fine, fine,
and suddenly, many times, I see the repair offer. There is rarely any
problem detected.

At the suggestion of technical support for my memory stick, I
reformatted. That did not cure the problem.

Sincerely,

Gene Wirchenko

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.

On Wed, 17 Oct 2012 12:53:41 -0500, VanguardLH wrote:

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.

--
Gene E. Bloch (Stumbling Bloch)

VanguardLH wrote:
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

"Gene E. Bloch" wrote:

On Wed, 17 Oct 2012 12:53:41 -0500, VanguardLH wrote:

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.

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.

"Paul" wrote:

VanguardLH wrote:

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.

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?

On Wed, 17 Oct 2012 20:07:04 -0500, VanguardLH wrote:

"Gene E. Bloch" wrote:

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


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


--
Linspired

Hey, you, get off of my cloud.

"Jeremy Lin fan" wrote:

On Wed, 17 Oct 2012 20:07:04 -0500, VanguardLH wrote:

"Gene E. Bloch" wrote:

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

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.

VanguardLH wrote:
"Paul" wrote:

VanguardLH wrote:

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.

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

"Paul" wrote:

VanguardLH wrote:
"Paul" wrote:

VanguardLH wrote:

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.

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.

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" wrote:

"Paul" wrote:

VanguardLH wrote:
"Paul" wrote:

VanguardLH wrote:

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.

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.

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.