Hi folks,
We have an embedded device using serial over USB to communicate to Windows XP-Windows 7. Using MS usbser.sys and MS serenum.sys the communications work for the most part. The only real problem we have is on surprise removal (unplug USB cable.) with an “user land” application having the port open, we are unable to open the com port again after re-connecting. Couple of questions:
1.) Doing lots of searching, this appears to be a known limitation of serenum.sys. Is this true? It correctly adds new ports, but really doesn’t care about when devices are unplugged. I think Doran said maybe two years ago that that was in fact, per design.
2.) How do I fix this problem without making a change to the application, or the device? Since usbser.sys and serenum.sys mostly work, is there a solution where I can for the most part keep them in tact? I’m not that familiar with these two drivers, can I do something like src\general\toaster\kmdf\toastmon? Do I dare use src\serial\serenum?
Thank you,
Jon
>problem we have is on surprise removal (unplug USB cable.) with an “user land” application having
the port open, we are unable to open the com port again after re-connecting.
This is normal. Close the user-land application, then re-plug the device.
Or - the application must listen for PnP notifications and close the handle when notified on surprise removal.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Thanks for the Quick reply Maxim.
Yes, I agree that if we could cover this with procedures, or a modification of the application that that would be the way to go. Unfortunately I can’t.
Do you think we could do something to produce an error in the application, essentially closing the port from the kernel side via an upper filter on top of serenum.sys? Or maybe sending IOCTL_INTERNAL_SERENUM_REMOVE_SELF to serenum from there?
Jon
Write the second watchdog app and terminate the first app from the second one via window close or TerminateProcess.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> Thanks for the Quick reply Maxim.
>
> Yes, I agree that if we could cover this with procedures, or a modification of the application that that would be the way to go. Unfortunately I can’t.
>
> Do you think we could do something to produce an error in the application, essentially closing the port from the kernel side via an upper filter on top of serenum.sys? Or maybe sending IOCTL_INTERNAL_SERENUM_REMOVE_SELF to serenum from there?
>
> Jon
>
Unfortunately I have to do it from an INF/driver side of things, they have no application or application installer, the COM port gets used in generic 3rd party applications.
>installer, the COM port gets used in generic 3rd party applications.
Then the lame apps will misbehave, and the correct ones will not.
I would just forget about this issue in this case.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Here’s the thread from 2008 in which Doron is talking about IOCTL_INTERNAL_SERENUM_REMOVE_SELF . Second post, 3) in particular seems to be on topic. Isn’t this similar to my situation?
(would help if I actually pasted the link into the previous post…)
http://www.osronline.com/ShowThread.cfm?link=123093