Delay on USB HID detach

[matevzb]

We designed a USB composite HID device (3 HID interfaces). The device is running fine, but there is one peculiarity - when we disconnect the device from Windows host, the system needs about 10 seconds to detect and signalize this event (beeps). On other systems (linux, OS X) there is no such delay. When we disconnect and reconnect the device immediately, Windows system also needs about 10 seconds to detect the removal and then the new device.
The device has been tested with USB-IF suite and no problem was found...

Does anyone has any idea on what could it be and how to debug it? There must be something wrong in device descriptor - HID driver relationship. Namely, when the detach event is being observed, the device has already been disconnected...

[Jan Axelson]

What are you using to detect the device detachment?

[matevzb]

Well, since we are using system HID drivers, we don't detect the detachment by ourselves.
On the other hand, when a USB device is detached, Windows produces the detachment sound. This sound usually comes immediately after detachment, but in our case, it takes up to about 10 seconds for this to happen.
Also, this is directly visible when the device is rebooting to bootloader mode - the device reboots, re-initializes the USB stack and waits for master to enumerate the device. It takes 10 seconds for the master to start communicating...

[Jan Axelson]

I can't think of anything that would have so much effect on the time required to detect physical removal of a device.

On attachment,a hardware protocol analyzer will show what is happening on the bus. That will tell you whether the device is causing the delay, for example by delaying in responding to enumeration requests, or whether the host system is the source of the delay. If you don't have a hardware analyzer, use whatever debugging tools you have to monitor enumeration requests.

Also check the setupapilog file:

http://support.microsoft.com/kb/927521

And:

http://www.lvr.com/forum/index.php?topic=350.0

[matevzb]

Nothing special seems to be reported by the system. Moreover, nothing special is visible in the traffic (Beagle USB analyzer) - all enumerations are done in time, no errors, no unanswered requests...
Is there any mechanism to see the Windows HID driver debug output or something similar?

[Jan Axelson]

>Also, this is directly visible when the device is rebooting to bootloader mode - the device reboots, re-initializes the USB stack and waits for master to enumerate the device. It takes 10 seconds for the master to start communicating...

The device should emulate detach and reattach by removing the pull-up, waiting, and reconnecting the pull-up.

procmon might tell you something:

http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

Also see:

http://answers.microsoft.com/en-us/windows/forum/windows_7-hardware/usb-connection-delays/fd40765e-f452-40c7-8c24-b8ed33ff2ad8?msgId=0de41fbb-3903-4fe4-be03-dc4c0f685a40

[matevzb]

Jan, the device is operating according to the specification. I just pointed out that this behaviour is observed either if device is physically still attached to the host or not.

The aim is to solve the problem with the lengthy detachment procedure that is in the domain of the Windows HID driver (the device is 'dead' when it is detached and has no influence on the system anymore). Have you been in contact with any MS engineer on USB drivers?

[Jan Axelson]

I don't know if it's the HID driver or something at a lower level causing the delay you're seeing. Some things that might help to isolate the reason are: does it happen on every Windows system you try? Does it happen on every attachment/removal or only the first time, or randomly? Do RegisterDeviceNotification or System.Management methods detect attachment and removal quickly or do they see the same delay?