Checking whether usbser.sys is still working/polling a COM port/CDC device

Question

5.00/5 (1 vote)

See more:

Hello all
Is it possible to check programmatically whether usbser.sys does still poll a specific COM port where a USB device using CDC (Communication Device Class) is connected? If yes any idea how to do that?

By the way the question is to make some test code to verify whether there is a usbser.sys problem like described e.g. at http://www.microchip.com/forums/m538194.aspx. In short what you can read there: If the pc communicates with a USB device and the communication fails (caused e.g. noisy signals, to long or bad quality usb cable) three times, then Microsoft’s driver usbser.sys stops working/polling. Usually you can reactivate the interface by unplug/plug the respective device.

Especally to recognize this situation visualized here: http://www.microchip.com/forums/download.axd?file=0;538194[^]

N.B. This question is a 'successor' from a previous q from side: USB Device simulation c#, c++[^

Many thanks in advance.
Regard]

Posted 6-Jun-12 7:39am

idle63

Updated 6-Jun-12 11:12am

v8

Add a Solution

Comments

SoMad 6-Jun-12 16:34pm

I was not aware of this problem, thank you for bringing that to my attention. I need to check if this could ever be a problem in our application when interfacing to external devices.

Soren Madsen

[no name] 6-Jun-12 16:45pm

Your welcome to this problem:) Keen on hear news. Regards, Bruno

TRK3 6-Jun-12 17:48pm

Here's a link to similar data:

http://www.embeddedrelated.com/groups/lpc2000/show/35810.php

It points out another issue that causes the same behavior and might be solvable in the device firmware. It also gives more data on the problem described in your link, but it doesn't have a solution for it either.

TRK3 6-Jun-12 17:52pm

Even if you can programmatically recognize the problem, is there anything you can do to fix it programmatically?

When I ran into a similar situation with old winusb.sys drivers I could detect a problem at the application level (although I couldn't say what the problem was), but there was no way I could reset the driver at the application level -- the ONLY thing that worked was physically disconnecting the USB cable and plugging it back in...

[no name] 8-Jun-12 11:53am

I told my customer to bring noise onto the USB cable with a hairdryer :) A standard USB cable extended with an USB extension cable and the hairdryer on the connector. Thisway it is no problem to reproduce the bad behavior of usbser.sys.
Thanks for your help. Regards, Bruno

[no name] 6-Jun-12 18:07pm

You are right even I can programmatically recognize the problem I think there is no solution to correct it programmatically (first idea is to eject the device, that is possible, but how reconnect is the question....). For me at the moment (...) it is enough to prove that usbser.sys is the problem and not my application.

If I can prove it I think the first step will be to do everything possible on hardware side (shorter and maybe better usb cables) to solve “my” case.

But of course recognizing the problem and reestablish the connection by the app will be the next step…but seems to be hopeless without the help of Microsoft.

Regards, Bruno

TRK3 8-Jun-12 13:31pm

One thing that actually might fix the problem would be to add a USB hub between your computer and the device. By doing that, you are changing the timing. Also it will be the hub that sees the corrupted signal from the device and handle the NAK/retry with the device -- the usbser.sys on the host won't see a corrupted signal, it will instead see a NRDY (not ready) from the hub, while the hub is handling the retries. So the whole behavior of the system will be different. It will either fix the problem or make it worse, depending on the hub in use (try a 1.1 Hub and 2.0 Hub and several different manufacturers -- they are not all the same).

[no name] 8-Jun-12 17:37pm

If all this seems so strange, why nobody writes a better usbser.sys? Can you provide me please with some source to control this device directly by winusb.sys?
Thanks a lot again.
Regards, Bruno

TRK3 8-Jun-12 18:50pm

Yeah, I've been meaning to dig it up for you -- I probably won't have a chance to post it for you until Monday.

[no name] 12-Jun-12 6:59am

Customer tried one hub. As you mentioned it can become worse...and it became worse :)

1 solution

Add a Solution

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Dave Kreskowiak · Accepted Answer · 2012-06-06T07:48:00

Solution 1

Not that I know of, no. I don't know of an interface exposed by it that will let you query that information.

Posted 6-Jun-12 7:48am

Dave Kreskowiak

Comments

[no name] 6-Jun-12 13:53pm

Many thanks for answering. I think also about something like hooking between usbser.sys and the class driver (like I think usb sniffers do), but at the moment I do not have a clear idea how to do that... Regards, Bruno

Checking whether usbser.sys is still working/polling a COM port/CDC device

1 solution

Solution 1

Add your solution here

Preview 0

Checking whether usbser.sys is still working/polling a COM port/CDC device

1 solution

Solution 1

Add your solution here

Preview 0

Existing Members

...or Join us