using IOCTL_INTERNAL_USB_RESET_PORT faild with USB2.0 Hub

Jan Menzel

unread,

Jul 27, 2005, 11:16:02 AM7/27/05

to

Hi all!
My devices uses bulk pipes to exchange data. If a transaction fails, I
follow the guidelines from Mr. Oney book to recover: 1. read the port
status (IOCTL_INTERNAL_USB_GET_PORT_STATUS) and if it shows that the
devices is connected but the port is disabled, I abort the pipe (via
URB_FUNCTION_RESET_PIPE) and then reset the device via
IOCTL_INTERNAL_USB_RESET_PORT followed by resetting the failed pipe. All
this works fine while operating our device behind a USB1.1 hub. But if
the device is operated behind a USB2.0 hub,
IOCTL_INTERNAL_USB_RESET_PORT fails with STATUS_DEVICE_DATA_ERROR after
5 seconds. Additionally, the device gets stopped, the driver unloaded,
reloaded and the device stated again. If there is still a handle open,
the driver receives an additional IRP_MN_REMOVE_DEVICE after the
IRP_MJ_CLOSE. All this only seems to happens, if the Port status is 2
(USBD_PORT_CONNECTED but not enabled).
Can anyone please advice me how to handle failures of bulk pipes
correctly while the device is below a USB2.0 hub? Thank You!

Best Regards
Jan

skodali98

unread,

Aug 8, 2005, 1:57:12 PM8/8/05

to

Jan,
Did you ever figure out the solution to your problem above?

Jan Menzel

unread,

Aug 10, 2005, 12:17:05 PM8/10/05

to

Hi all!
Look like its related to an other problem: For testing my USB device
released short disconnects from the USB. As a result my driver receives
IRPs in the sequence SURPRISE_REMOVE, REMOVE_DEVICE and ADD_DEVICE. But
if a handle to the driver is open, the REMOVE_DEVICE is postponed until
it has been closed.
Is there a way to avoid this postponing?
Is there a way to keep the handle valid while cycling thru
SURPRISE_REMOVE ADD_DEVICE?
Thank You in advance for Your help.

Best Regards
Jan Menzel

Maxim S. Shatskih

unread,

Aug 10, 2005, 1:50:52 PM8/10/05

to

> if a handle to the driver is open, the REMOVE_DEVICE is postponed until
> it has been closed.
> Is there a way to avoid this postponing?

No. This is by design on NT OSes. Not so on Win98.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com

Jan Menzel

unread,

Aug 11, 2005, 4:52:43 AM8/11/05

to

Maxim S. Shatskih wrote:
>>if a handle to the driver is open, the REMOVE_DEVICE is postponed until
>>it has been closed.
>>Is there a way to avoid this postponing?
>
>
> No. This is by design on NT OSes. Not so on Win98.
>

Hi Maxim!
Thank You for your quick response.
Does that mean that the only to not lose the device at all is to close
all handles to the driver before the SURPRISE_REMOVE has been processed
so that the REMOVE_DEVICE does not get postponed?
Is there any way to close the handles from within the driver?

Best Regards
Jan

Maxim S. Shatskih

unread,

Aug 11, 2005, 5:04:52 AM8/11/05

to

No. Your app must catch the removal notification and close the handles.
Then re-open them on device re-arrival.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com

"Jan Menzel" <jan.men...@gmx.de> wrote in message
news:3m0huqF...@uni-berlin.de...