Win7 suddenly informs device disconnection

[tk]

In our system, we get data messages from a HID device, which is implemented as a vendor defined one, through Windows. The way to access the device is very orthodox I think: execute ReadFile in the asynchronous mode, wait its completion by WaitForXXX, and then get input data by GetOverlappedResult when the ReadFile process completes.
We have been using the system for more than ten years since the age of Win2K. But recently, maybe since we have replaced the host to Win7, we have been experiencing a trouble: The GetOverlappedResult fails and GetLastError executed just after the failure returns ERROR_DEVICE_NOT_CONNECTED(=0x0000048F). We traced the USB traffic and found that SOFs and IN tokens were sent continuously even when the failure occurred. We don't have any ideas why Windows determines that the USB connection is disconnected and returns the error code in the situation like that.
We have many systems. But the trouble is not caused in every one. Almost all of them don't cause that.
I'm very pleased if someone who has the same experience gives me some advice or hint to approach its root cause.
Thanks in advance.

[Jan Axelson]

If the IN tokens stop on the failure (not clear from your description whether this is true), check to be sure the endpoint is NAKing or ACKing every IN token packet before the failure.

If the device re-enumerates after the failure, there was a problem of some sort that caused the host to re-establish communications.

[st2000]

This suggestion is more on the mundane side - but, have you considered trying a powered USB hub just to see if the device is having a power problem?

[tk]

The USB traffic showed that the host sent IN tokens to the endpoint, which is assigned as Interrupt-IN, and the endpoint responded to each token with NAK when the failure occurred. Communication was continuing at that time. It showed neither any occurence of disconnection nor any re-enumeration.
Since the endpoint was responding to the tokens, I think it's difficult for us to think that power failure or something like that was caused with the device.

[Jan Axelson]

If the device is still connected and communicating, the error message is wrong.

Does the device send the data?

If yes, and if the application ignores the error, does the GetOverlappedResult eventually succeed?

[tk]

Yes, it does. The traffic shows that the device sent data in return to some USB's standard request. Adding to that, I can find some data sent via Interrupt-IN transfer.

If my application ignores the error, from where and how can it retry the procedure? The current version of the application is designed to consider the failure a fatal one.

[Jan Axelson]

In the application's error handling, ignore the error except for setting a flag to inform the application that the error occurred. Then check the flag on completing the transfer. This is only for testing as it looks like something is going wrong, you just don't know what yet.

[tk]

I have gotten new facts:
- The device disconnection is caused not only in Win7, but also in WinXP.
- My application starts the reading process just after completing to open the communications and getting a handle for the device.
- The trouble occurs when a device that has not been plugged into the host is installed into the host and the application gets a handle while the message, which means some brand-new device is found, by Windows is still shown in the screen. The application can get a handle, and then it can receive some Interrupt-IN packets. But soon in a while, ReadFile(GetOverlappedResult) often fails and Windows returns ERROR_DEVICE_NOT_CONNECTED.
- There is no device disconnection recorded in an USB traffic.

[Jan Axelson]

Try adding a delay between detecting the device and starting communications. If you can eliminate the error that way, you can look for a more elegant way to deal with it.

[tk]

Thank you very much, Jan. I will try.

[tk]

As far as I've observed, the problem is caused when I install a device that is HID vendor defined. If a device is a HID keyboard or mouse, it does not occur. It is caused in WinXP and Win7, but not in Win8 and Win8.1.

[Jan Axelson]

Try the delay as I suggested. You could also try the suggestion to add a hub between the device and PC. If that fixes it, it's likely something in your device firmware that is having trouble with the host controllers.

[tk]

The touble is also caused if a device is an off-the-shelf one. So I don't think that the root cause is in the firmware.

[Jan Axelson]

Do you see it only when using the host application you've described?

[tk]

After getting a handle for a device(interface), my test program repeats HidD_GetAttributes() with some interval of time, e.g., 25ms. The API completes successfully at the beginning, and soon it begins to fail; GetLastError() returned ERROR_DEVICE_NOT_CONNECTED. After some seconds, it comes to complete successfully again.
I think there is nothing special in my program and you can easily reproduce the trouble.