De-unplug USB device?

[VanguardLH]

Can you do this with USBDeview or not?

Nope, apparently not. You can't do in software the physical latch in
the hardware logic to show change in state of the logic to initiate the
transfer of the presentation data to identify the device. I can't think
of any software that's going to, for example, make a floating signal
line suddenly get pulled low or high without the device doing something
physical, like plugging into the port.

http://www.usb.org/developers/docs/ has some specs you can download.
Get http://www.usb.org/developers/docs/usb_20_101111.zip and unzip.
Read the D:\TEMP\usb_20_101111\usb_20.pdf, section 4.6.1, which says:

4.6.1 Attachment of USB Devices

All USB devices attach to the USB through ports on specialized USB
devices known as hubs. Hubs have status bits that are used to report
the attachment or removal of a USB device on one of its ports. The
host queries the hub to retrieve these bits. In the case of an
attachment, the host enables the port and addresses the USB device
through the device¢s control pipe at the default address.

The host assigns a unique USB address to the device and then
determines if the newly attached USB device is a hub or a function.
The host establishes its end of the control pipe for the USB device
using the assigned USB address and endpoint number zero.

There's more on removal of a device and enumeration. So my guess that
the device won't initiate until it gets plugged in (which, in your case
requires removal so it can then be attached) looks to be good. The
device can't say "I'm here" until it leaves and then comes back, and
that's handled in the hardware to which you don't have software control.
Besides the device presenting itself after plugged in, it also has to
first get reset on connection to ensure it is in a known state. When
the hub (controller) detects attachment, it has to get the configuration
to know the device. The spec also says:

9.1.1.1 Attached
A USB device may be attached or detached from the USB. The state of a
USB device when it is detached from the USB is not defined by this
specification. This specification only addresses required operations
and attributes once the device is attached.

9.1.1.5 Configured
Before a USB device¢s function may be used, the device must be
configured. From the device¢s perspective, configuration involves
correctly processing a SetConfiguration() request with a non-zero
configuration value.

Configured doesn't mean what was left in the registry from prior
discovery and use. It means the device identifying itself when it is
discovered.

By the way, why do you bother doing a safe removal of a flash drive? I
assumed "USB drive" meant a USB /flash/ drive (i.e., it's a memory
card). There's no spinning platter or other latency in writes in the
hardware. Maybe you meant it is a USB-attached hard disk so that does
have latency along with its interface buffer to flush.

 

[Dave \Crash\ Dummy]

Nope, apparently not. You can't do in software the physical latch in
the hardware logic to show change in state of the logic to initiate
the transfer of the presentation data to identify the device. I
can't think of any software that's going to, for example, make a
floating signal line suddenly get pulled low or high without the
device doing something physical, like plugging into the port.

http://www.usb.org/developers/docs/ has some specs you can download.
Get http://www.usb.org/developers/docs/usb_20_101111.zip and unzip.
Read the D:\TEMP\usb_20_101111\usb_20.pdf, section 4.6.1, which says:


4.6.1 Attachment of USB Devices

All USB devices attach to the USB through ports on specialized USB
devices known as hubs. Hubs have status bits that are used to
report the attachment or removal of a USB device on one of its ports.
The host queries the hub to retrieve these bits. In the case of an
attachment, the host enables the port and addresses the USB device
through the device’s control pipe at the default address.

The host assigns a unique USB address to the device and then
determines if the newly attached USB device is a hub or a function.
The host establishes its end of the control pipe for the USB device
using the assigned USB address and endpoint number zero.

There's more on removal of a device and enumeration. So my guess
that the device won't initiate until it gets plugged in (which, in
your case requires removal so it can then be attached) looks to be
good. The device can't say "I'm here" until it leaves and then comes
back, and that's handled in the hardware to which you don't have
software control. Besides the device presenting itself after plugged
in, it also has to first get reset on connection to ensure it is in a
known state. When the hub (controller) detects attachment, it has to
get the configuration to know the device. The spec also says:

9.1.1.1 Attached A USB device may be attached or detached from the
USB. The state of a USB device when it is detached from the USB is
not defined by this specification. This specification only addresses
required operations and attributes once the device is attached.

9.1.1.5 Configured Before a USB device’s function may be used, the
device must be configured. From the device’s perspective,
configuration involves correctly processing a SetConfiguration()
request with a non-zero configuration value.

Configured doesn't mean what was left in the registry from prior
discovery and use. It means the device identifying itself when it is
discovered.

By the way, why do you bother doing a safe removal of a flash drive?
I assumed "USB drive" meant a USB /flash/ drive (i.e., it's a memory
card). There's no spinning platter or other latency in writes in the
hardware. Maybe you meant it is a USB-attached hard disk so that
does have latency along with its interface buffer to flush.

Actually, none of this matters to me. I am just trying to help the OP by
verifying posted solutions.

 

[J. P. Gilliver (John)]

Can you do this with USBDeview or not?

Nope, apparently not. You can't do in software the physical latch in
the hardware logic to show change in state of the logic to initiate the
transfer of the presentation data to identify the device. I can't think[/QUOTE]
[]
But surely the "safely remove devices" bit that's built into Windows is
software rather than hardware; what the OP was after, I think, was
something that reversed what that does.

 

[Char Jackson]

Nope, apparently not. You can't do in software the physical latch in
the hardware logic to show change in state of the logic to initiate the
transfer of the presentation data to identify the device. I can't think

[]
But surely the "safely remove devices" bit that's built into Windows is
software rather than hardware; what the OP was after, I think, was
something that reversed what that does.[/QUOTE]

It looks like it's a one way street with a dead end, software wise. If
they didn't put a method of reversal in the code, there isn't much you
can do.

 

[Dave \Crash\ Dummy]

Dave "Crash" Dummy wrote:

Can you do this with USBDeview or not?
Nope, apparently not. You can't do in software the physical
latch in the hardware logic to show change in state of the logic
to initiate the transfer of the presentation data to identify the
device. I can't think

[] But surely the "safely remove devices" bit that's built into
Windows is software rather than hardware; what the OP was after, I
think, was something that reversed what that does.

It looks like it's a one way street with a dead end, software wise.
If they didn't put a method of reversal in the code, there isn't much
you can do.

It looks like the only alternative to physically unplugging and
reinserting is to reboot the system.

 

[BillW50]

In

In message <[email protected]>, VanguardLH
Dave "Crash" Dummy wrote:

Can you do this with USBDeview or not?
Nope, apparently not. You can't do in software the physical
latch in the hardware logic to show change in state of the logic
to initiate the transfer of the presentation data to identify the
device. I can't think
[] But surely the "safely remove devices" bit that's built into
Windows is software rather than hardware; what the OP was after, I
think, was something that reversed what that does.

It looks like it's a one way street with a dead end, software wise.
If they didn't put a method of reversal in the code, there isn't much
you can do.

It looks like the only alternative to physically unplugging and
reinserting is to reboot the system.

It has been stated twice in this thread alone that there are two
software products that reconnects USB device after being removed by
Safely Remove Hardware.

 

[Dave \Crash\ Dummy]

In

On Tue, 10 Apr 2012 21:34:28 +0100, "J. P. Gilliver (John)"

In message <[email protected]>, VanguardLH
Dave "Crash" Dummy wrote:

Can you do this with USBDeview or not?
Nope, apparently not. You can't do in software the physical
latch in the hardware logic to show change in state of the logic
to initiate the transfer of the presentation data to identify the
device. I can't think
[] But surely the "safely remove devices" bit that's built into
Windows is software rather than hardware; what the OP was after, I
think, was something that reversed what that does.
It looks like it's a one way street with a dead end, software wise.
If they didn't put a method of reversal in the code, there isn't much
you can do.

It looks like the only alternative to physically unplugging and
reinserting is to reboot the system.

It has been stated twice in this thread alone that there are two
software products that reconnects USB device after being removed by
Safely Remove Hardware.

Have you tried either of them?

 

[BillW50]

In

In

Char Jackson wrote:
On Tue, 10 Apr 2012 21:34:28 +0100, "J. P. Gilliver (John)"

In message <[email protected]>, VanguardLH
Dave "Crash" Dummy wrote:

Can you do this with USBDeview or not?
Nope, apparently not. You can't do in software the physical
latch in the hardware logic to show change in state of the logic
to initiate the transfer of the presentation data to identify the
device. I can't think
[] But surely the "safely remove devices" bit that's built into
Windows is software rather than hardware; what the OP was after, I
think, was something that reversed what that does.
It looks like it's a one way street with a dead end, software wise.
If they didn't put a method of reversal in the code, there isn't
much you can do.
It looks like the only alternative to physically unplugging and
reinserting is to reboot the system.

It has been stated twice in this thread alone that there are two
software products that reconnects USB device after being removed by
Safely Remove Hardware.

Have you tried either of them?

Yes, both of them! And I have used them for years now. I wouldn't want
to run a Windows machine without at least one of them. ;-)

 

[Bob I]

In message <[email protected]>, VanguardLH
Dave "Crash" Dummy wrote:

Can you do this with USBDeview or not?
Nope, apparently not. You can't do in software the physical
latch in the hardware logic to show change in state of the logic
to initiate the transfer of the presentation data to identify the
device. I can't think
[] But surely the "safely remove devices" bit that's built into
Windows is software rather than hardware; what the OP was after, I
think, was something that reversed what that does.

It looks like it's a one way street with a dead end, software wise.
If they didn't put a method of reversal in the code, there isn't much
you can do.

It looks like the only alternative to physically unplugging and
reinserting is to reboot the system.

Ok, I decided to solve this. Seemed to me that if it reappeared to the
system it should go again, so "break" the connection upstream. Answer,
disable and re-enable the associated host controller via Device
Manager. When the host controller returns the memory stick will be
recognized as if it was just inserted. You will need to trace back
through the USB hub to the host controller.
Have a great day.

 

[Paul]

On Tue, 10 Apr 2012 21:34:28 +0100, "J. P. Gilliver (John)"

In message <[email protected]>, VanguardLH
Dave "Crash" Dummy wrote:

Can you do this with USBDeview or not?
Nope, apparently not. You can't do in software the physical
latch in the hardware logic to show change in state of the logic
to initiate the transfer of the presentation data to identify the
device. I can't think
[] But surely the "safely remove devices" bit that's built into
Windows is software rather than hardware; what the OP was after, I
think, was something that reversed what that does.

It looks like it's a one way street with a dead end, software wise.
If they didn't put a method of reversal in the code, there isn't much
you can do.

It looks like the only alternative to physically unplugging and
reinserting is to reboot the system.

Ok, I decided to solve this. Seemed to me that if it reappeared to the
system it should go again, so "break" the connection upstream. Answer,
disable and re-enable the associated host controller via Device
Manager. When the host controller returns the memory stick will be
recognized as if it was just inserted. You will need to trace back
through the USB hub to the host controller.
Have a great day.

If that is the case, there's a possibility you could script it with "devcon".
One question would be, what would happen to sessions already underway with
other devices on the same host.

http://www.robvanderwoude.com/devcon.php

http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q311272

And then, another question you'd have to answer, is how exactly do you
go about identifying something, that has already been logically
removed from the computer.

Paul

 

[Andy Burns]

Ok, I decided to solve this. Seemed to me that if it reappeared to the
system it should go again, so "break" the connection upstream. Answer,
disable and re-enable the associated host controller via Device Manager.
When the host controller returns the memory stick will be recognized as
if it was just inserted. You will need to trace back through the USB hub
to the host controller.

Did you try this? Because I went further and un-installed/re-installed
the host controller and *that* still brought the device back in a
ready-to-remove state ....

 

[Stan Brown]

Because if I don't, the next time I plug it in Windows 7 wants to
scan and fix it.

Actually, none of this matters to me. I am just trying to help the OP by
verifying posted solutions.

And I appreciate it. I'm not sure why Vanguard stated so
authoritatively that USBDeview will de-unplug a USB device when
that's apparently not true. I was going to try it at work today, but
based on your experience I don't expect it will work.

 

[Stan Brown]

You can't do in software the physical latch in
the hardware logic to show change in state of the logic to initiate the
transfer of the presentation data to identify the device. I can't think

[]
But surely the "safely remove devices" bit that's built into Windows is
software rather than hardware; what the OP was after, I think, was
something that reversed what that does.

That was my thinking, yes. I'm not sure what "the physical latch in
the hardware logic" might mean.

 

[VanguardLH]

Yes, both of them! And I have used them for years now. I wouldn't
want to run a Windows machine without at least one of them. ;-)

If the reattach of the device works for you then perhaps it depends on
what hardware you have inside your box. For Dave and I, for example,
Nirsoft's USBdevView didn't work to reattach the device (to initiate the
handshaking needed for resend the presentation data from the device to
identify itself).

I figure the author of Nirsoft's tools has more inside info than we do.
He's been producing hack tools for quite awhile. In his USBdevView
program, you can right-click on a device (with Connected=Yes state) to
select Disconnect it. There is no Connect or Reconnect entry in this
context menu. You can see a device that is not connected because its
definition remains in the enumeration data in the registry. Right-click
on a Connected=No item in the list and notice there is no Connect or
Reconnect function.

For a connected device (Connect=Yes), you can use the software tools to
disconnect that device. For a non-connected device (Connect=No), it
doesn't make sense to reconnect it with software because you nor the OS
even knows if there is a physical device present in a USB port. It's
not just "not connected" but it is also "not present". Presence is
establish through the physical act of connection which initiates the
handshaking to present the device.

Try an experiement. If you have a USB flash drive, plug it into a USB
port. Wait until the handshaking has completed for the device to
present itself so the OS knows how to identify the device type. Do
something to ensure the device is available, like use Windows Explorer
to look at whatever files are on the USB flash drive. Leave the device
plugged into the USB port. Use Nirsoft's USBdevView to disconnect the
device: right-click on the USB flash drive and select Disconnect
Selected Devices, or select the device and hit F9 (to do the same
thing). You now have a device that is still physically plugged into the
port but its state is detached (or disconnected). Detached devices are
unknown devices. You should now see Connected=No for that device.
Right-click on that same device again. Notice there is no context menu
entry to [re]connect that device.

When I use Microsoft's USB Device Viewer, and after using Nirsoft's
USBdevView or Windows Safely Remove wizard to disconnect the USB flash
drive, the "USB Mass Storage Device" entry for the USB flash drive
changes. A yellowed exclamation icon appears to the left of the
device's entry in the tree list. The error is "No string descriptor".
Once detached, the presentation data will have to get resent to ensure
the device is defined to the OS. So both utilities show the device as
disconnected or detached. Neither one will let you reattach a detached
device. If it's not these 2 utilities you use, what other software do
you use to reattach a detached device?

From these two USB utilities, from what I saw from scanning the USB
specs, and what else I have read, software can detach a device (because
that's using the driver-side interface to the controller) but attaching
it requires hardware initiation (from the device-side of the
controller).

We would be interested to know what software you use to reattached a
detached USB device that was left in the USB port after it got detached.

 

[charlie]

Did you try this? Because I went further and un-installed/re-installed
the host controller and *that* still brought the device back in a
ready-to-remove state ....

It's been a bit since I got into this with earlier win versions.
Turned out that the USB device (hardware) implementation was a factor.
There were problems in both the way that a device "appeared" to windows,
and exactly how it initialized.
Next, the hardware did not always strictly follow the "standards" of
behavior that windows expected to see. Among the most notable and
problematic usb devices were such things as ethernet and wireless I/O
devices, and (naturally) usb memory devices.

Fortunately, things have improved, both with windows usb support, and
with more "uniform" devices.

As others have observed, some usb memory devices behave as expected, and
others (hopefully in the minority now) don't. With the current glut of
cheap devices, it's hard to choose, and the vendors really don't bother
to tell what's really inside.

The big questions occur when a volume user want's to buy a bunch of the
same USB memory device. Price is always a consideration, and whether or
not the lot is uniform. It's just not worth the time and grief to
see why a handful of the devices don't work as expected.

Basically, one misbehaving device is written off when it doesn't behave
as expected. If a significant number create problems, either the
supplier gets grief, and replaces things, or the next buy goes
elsewhere, sometimes both.

A real problem can occur when cheap "knockoffs" are involved.
We've seen USB memory modules that ID (and were sold) as having a larger
capacity than they actually have. By the time the average user figures
things out, it's usually too late to do anything but just go and get
another.

 

[VanguardLH]

And I appreciate it. I'm not sure why Vanguard stated so
authoritatively that USBDeview will de-unplug a USB device when
that's apparently not true. I was going to try it at work today, but
based on your experience I don't expect it will work.

I was wrong about the software reattaching (reconnecting) the device
using that freeware utility. I remembered it would disconnect or detach
the device so I figured it could also reconnect or reattach the device.
If these utilities cannot do it then maybe it's something that can't be
done by software.

I'm not an electrical engineer engaged in USB circuit or driver design.
I'm a user on the outide looking in just like you. This really isn't a
USB hardware designers newsgroup. There is a USB implementers forums at
https://www.usb.org/members_landing but it looks like membership is
tigthly regulated. So far, I havent' seen any USB circuit designers or
USB driver programmers showing up here to assist in this conversation.
You ever try to determine the actual functional characteristics of
hardware based on its specs?

So far, it looks like you can use software to change the state of the
device to detached (which also means unknown). Changing state to
attached (connected) appears to require a hardware event.

There is http://safelyremove.com/. I don't have this because it isn't
free; however, they claim their trial version is fully functional. So
you could see if the payware does something more than the freeware.
On their web site it says "Returning back a device just stopped". It
might work. BillW50 claims he has something that works so maybe this is
it. Could be this sends a reset to all the USB hubs. 11.10 of the USB2
spec mentions hub reset behavior and if that's what gets used by this
software then it makes sense where Bill mentioned all devices go
momentarily dead at the same time (for all the USB hubs that got reset).
As I recall, that software has other nice features, like masking out USB
ports that aren't in use, like for a USB-attached card reader (where you
end up with half a dozen dead drives listed in Windows Explorer). I
didn't look in the USB specs on the effect of doing a reset on the
controller because I didn't consider rediscovery. Until now I hadn't
considered using a shotgun to get letters out of my postal mailbox,
either.

Nirsoft's USB Device Viewer just shows the devices, not the hubs
(controllers) to which the USB ports go. Microsoft's USB Device Viewer
only shows the hubs and devices but doesn't give you any actions that
you can commit on them. If USB Safely Remove works by doing a reset,
I'm wondering if disabling the hub and reenabling it might do the same.
That is, you go into Device Manager and right-click on the hub (to which
your device is attached, well, still plugged in be in detached state) to
disable it. Then you enable it. Not something I want to try on my own
host right now but it might be something you consider. If you find that
works to rediscover the still plugged in USB device, and instead of
using the GUI for Device Managment, you can get Microsoft's devcon
utility which is a command-line version of Device Management.

Whether you disable and then reenable the USB hub to force it to
rediscover devices attached to it (using Device Manager or devcon), or
if Nirsoft or Microsoft's USB Device View[er] had worked, or even if USB
Safely Remove (trialware) works or not, you have to spend a lot of time
loading and entering those software tools to do what could have been
much more quickly accomplished by just removing and reinserting the USB
device. You're not saving yourself any work by using the software.

If you go the Rube Goldberg route of going through the software instead
of just unplug and replug, let us know if it worked for you.

 

[Gene Wirchenko]

[snip]

We would be interested to know what software you use to reattached a
detached USB device that was left in the USB port after it got detached.

Hello, I am part of the "We". I use Uwe Sieber's removedrive,
and its output implies that remounting in place is possible. I have
E-mailed him, and when I have a response, I will follow up.

Sincerely,

Gene Wirchenko

 

[Bob I]

Did you try this? Because I went further and un-installed/re-installed
the host controller and *that* still brought the device back in a
ready-to-remove state ....

Yep, it works as specified on my 8GB thumb drive. It even brings up the
Autoplay "what do you want to do" dialog box.

 

[Stan Brown]

Stan Brown wrote:

Nirsoft's USB Device View
http://www.nirsoft.net/utils/usb_devices_view.html

Freeware. It does more than just view. You can disconnect/connect,
enable/disable, and several other functions.

I tried this today, and as Dave has already posted, it doesn't do
what I asked for.

In fact, when I did "Disable" and then Enable", it hung so the USB
stick was connected but still disabled. I ended up having to reboot.

 

[Paul]

[snip]

We would be interested to know what software you use to reattached a
detached USB device that was left in the USB port after it got detached.

Hello, I am part of the "We". I use Uwe Sieber's removedrive,
and its output implies that remounting in place is possible. I have
E-mailed him, and when I have a response, I will follow up.

Sincerely,

Gene Wirchenko

There is a section already on the site.

http://www.uwe-sieber.de/drivetools_e.html#RemoveDrive

"RestartSrDev USB\VID_0781*PID_5406*

"

"But sometimes devices have problem code 21 after the safe removal,
which is CM_PROB_WILL_BE_REMOVED. Devices with this problem code can
be reactivated by restarting them. This can be done by means of the
Microsoft DEVCON tool (DEVCON restart DeviceInstanceID). My tool
restarts only devices with the problem code 21, so usually you can
just start it with a asterisk as paramerter to restart all devices
with code 21."

You can get devcon here to experiment with.

http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q311272

Paul