Resume virtual COM port after USB unplug/plugin

NTDEV
1

Hi,

I would like to support a weird feature in my own usb2serial driver.
Its a KMDF driver that on the lower end talks with USB stack and on the higher end
it creates a child “serial” device that is exposed as a virtual COM port.

I would like to support the following use case:
A user unplugs then plugs in the USB cable while an application owns an open handle to the virtual COM port. In case the plugged in USB device is identical to what was plugged out I would like to bring the file handle back to live. So that the application would not need to close/open file handle.

Does anyone know how this can be done ?
I guess that just failing the IRP_MN_QUERY_REMOVE_DEVICE (or KMDF’s EvtDeviceQueryRemove) would not work.

Thank you in advance,
Alexey.

2

PnP does not allow this, unless the app will participate.

So, splitting to 2 drivers is maybe the only idea. The lower one is PnP one
and is the hardware handler. The upper one exposes itself to the apps,
registers for PnP device arrival notifications, and comes back to life when the
new instance of the hardware arrived.

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

wrote in message news:xxxxx@ntdev…
> Hi,
>
> I would like to support a weird feature in my own usb2serial driver.
> Its a KMDF driver that on the lower end talks with USB stack and on the
higher end
> it creates a child “serial” device that is exposed as a virtual COM port.
>
> I would like to support the following use case:
> A user unplugs then plugs in the USB cable while an application owns an open
handle to the virtual COM port. In case the plugged in USB device is identical
to what was plugged out I would like to bring the file handle back to live. So
that the application would not need to close/open file handle.
>
> Does anyone know how this can be done ?
> I guess that just failing the IRP_MN_QUERY_REMOVE_DEVICE (or KMDF’s
EvtDeviceQueryRemove) would not work.
>
> Thank you in advance,
> Alexey.
>
>

3

Thanks for the answer,

I already have two drivers.

The lower one is a USB function driver that creates a child device of
type FILE_DEVICE_SERIAL_PORT.
The USB driver also creates an interface with direct callbacks that can
be queried and used by the upper driver.

The upper driver is the function driver loaded for the child created by
lower USB driver.
This upper driver handles all the COM port related stuff and redirects
the I/O to the lower USB driver.

As you can see, this scheme is completely PnP.
When USB device is removed, the lower driver must remove its child, i.e.
the COM device.
I am looking for a solution that would allow the USB pdo to be properly
removed, while virtual COM pdo is kept perfectly alive as long as the
file handle for the COM port is held by application.

Thanks,
Alexey.

Maxim S. Shatskih wrote:

PnP does not allow this, unless the app will participate.

So, splitting to 2 drivers is maybe the only idea. The lower one is PnP one
and is the hardware handler. The upper one exposes itself to the apps,
registers for PnP device arrival notifications, and comes back to life when the
new instance of the hardware arrived.

4

> I am looking for a solution that would allow the USB pdo to be properly

removed, while virtual COM pdo is kept perfectly alive as long as the

It must be a PDO independent of USB stack PnP-wise, use IoReportDetectedDevice
to plant a parent of the new PnP tree, and then create children for it.

The only relation between these COM ports and the USB driver should be via PnP
device interfaces, not the PnP tree parent-child relation.

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

5

This should do the job.

Thanks a lot !

Maxim S. Shatskih wrote:

type=“cite”>

I am looking for a solution that would allow the USB pdo to be properly
removed, while virtual COM pdo is kept perfectly alive as long as the

It must be a PDO independent of USB stack PnP-wise, use IoReportDetectedDevice
to plant a parent of the new PnP tree, and then create children for it.

The only relation between these COM ports and the USB driver should be via PnP
device interfaces, not the PnP tree parent-child relation.

6

Why are you trying to do this? What problem are you really trying to
solve? With a solution like this hwere you split the handle away from
the lifetime of the hardware, you also have to consider the following:

Are you going to create a handle for nonexistent hardware before it is
every plugged in?

For how long are you going to create handles after the hardware is gone?

What are you going to do with i/o and IOCTls that expect strict timing
and actual hw response? In the COM port case, I don’t see how this
could ever work while the app has the Com port open and expects it to
keep on functioning.

As for how to enumerate the 2nd stack, IoReportDetectedDevice is not a
supported enumeration method in a KMDF driver. You would have to
install a root enumerated bus driver (like toaster’s busenum) and
communicate with the bus driver to tell it to enumerate you “fake”
device which is not tied to the real presence of hw.

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alexey Polonsky
Sent: Monday, May 21, 2007 2:46 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Resume virtual COM port after USB unplug/plugin

This should do the job.
Thanks a lot !

Maxim S. Shatskih wrote:

I am looking for a solution that would allow the USB pdo to be
properly
removed, while virtual COM pdo is kept perfectly alive as long
as the

It must be a PDO independent of USB stack PnP-wise, use
IoReportDetectedDevice
to plant a parent of the new PnP tree, and then create children for it.

The only relation between these COM ports and the USB driver should be
via PnP
device interfaces, not the PnP tree parent-child relation.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

7

Thanks a lot for your comments.

style=“font-size: 11pt; font-family: “Calibri”,“sans-serif”; color: rgb(192, 0, 0);”>Why
are you trying to do this?  What problem are you really trying
to solve?

The customer’s app may instruct the device to restart its firmware. The
host sees this as a USB unplug/plug in.

The app was originally written for RS232 (hence the usb-2-serial
driver) and, unfortunately, modifying the app or the firmware is not an
option.

As a solution, I need to keep the COM file handle alive across USB
unplug/plugin.

style=“font-size: 11pt; font-family: “Calibri”,“sans-serif”; color: rgb(192, 0, 0);”> color=“#000000”>

To accomplish this, I am going to create a ROOT enumerated device which
will become a parent of COM children.

When a USB dev is plugged in, a new COM child will be enumerated.

When a USB dev is plugged out:

   - no COM file handle ==> the COM child is removed

   - there is a COM file handle ==> the COM child will fail all
subsequent read/write/ioctl style=“font-size: 11pt; font-family: “Calibri”,“sans-serif”; color: rgb(192, 0, 0);”> color=“#000000”>with IoStatus.Status = STATUS_DEVICE_NOT_CONNECTED.

   - COM file handle is closed while USB dev is unplugged  ==> the
COM child is removed

When the USB dev is plugged in while COM file handle is open, I’ll
check USB instance id (hwid +
physical location), if it’s the same, I’ll revive the COM file handle.

style=“font-size: 11pt; font-family: “Calibri”,“sans-serif”; color: rgb(192, 0, 0);”>>
Are you going to create a handle for nonexistent hardware before
it is every plugged in?

no

style=“font-size: 11pt; font-family: “Calibri”,“sans-serif”; color: rgb(192, 0, 0);”><o:p></o:p>

style=“font-size: 11pt; font-family: “Calibri”,“sans-serif”; color: rgb(192, 0, 0);”>>
For how long are you going to create handles after the hardware
is gone?

after the HW is gone, the file handle will remain
alive until its closed by the app.

style=“font-size: 11pt; font-family: “Calibri”,“sans-serif”; color: rgb(192, 0, 0);”><o:p></o:p>

style=“font-size: 11pt; font-family: “Calibri”,“sans-serif”; color: rgb(192, 0, 0);”>>
What are you going to do with i/o and IOCTls that expect strict
timing and actual hw response?

style=“font-size: 11pt; font-family: “Calibri”,“sans-serif”; color: rgb(192, 0, 0);”> color=“#000000”>All HW related IOCTL’s and Read/Write will fail with
IoStatus.Status = STATUS_DEVICE_NOT_CONNECTED

style=“font-size: 11pt; font-family: “Calibri”,“sans-serif”; color: rgb(192, 0, 0);”>>
In the COM port case, I don’t see how this
could ever work while the app has the Com port open and expects it to
keep on
functioning.<o:p></o:p>

Since style=“font-size: 11pt; font-family: “Calibri”,“sans-serif”; color: rgb(192, 0, 0);”>the
app instructs the device to restart the firmware, it cannot expect that
the device will be functional immediately after that.

Thanks,

Alexey.

Doron Holan wrote:

cite="xxxxx@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com"
type=“cite”>



style=“font-size: 11pt; font-family: “Calibri”,“sans-serif”; color: rgb(192, 0, 0);”>Why
are you trying to do this?  What problem are you really trying
to solve?  With a solution like this hwere you split the handle away
from the lifetime
of the hardware, you also have to consider the following:<o:p></o:p>

style=“font-size: 11pt; font-family: “Calibri”,“sans-serif”; color: rgb(192, 0, 0);”><o:p> </o:p>

style=“font-size: 11pt; font-family: “Calibri”,“sans-serif”; color: rgb(192, 0, 0);”>Are
you going to create a handle for nonexistent hardware before
it is every plugged in?<o:p></o:p>

style=“font-size: 11pt; font-family: “Calibri”,“sans-serif”; color: rgb(192, 0, 0);”>For
how long are you going to create handles after the hardware
is gone?<o:p></o:p>

style=“font-size: 11pt; font-family: “Calibri”,“sans-serif”; color: rgb(192, 0, 0);”>What
are you going to do with i/o and IOCTls that expect strict
timing and actual hw response?  In the COM port case, I don’t see how
this
could ever work while the app has the Com port open and expects it to
keep on
functioning.<o:p></o:p>

style=“font-size: 11pt; font-family: “Calibri”,“sans-serif”; color: rgb(192, 0, 0);”><o:p> </o:p>

style=“font-size: 11pt; font-family: “Calibri”,“sans-serif”; color: rgb(192, 0, 0);”>As
for how to enumerate the 2nd stack,
IoReportDetectedDevice is not a supported enumeration method in a KMDF
driver. 
You would have to install a root enumerated bus driver (like toaster’s
busenum)
and communicate with the bus driver to tell it to enumerate you “fake”
device
which is not tied to the real presence of hw.<o:p></o:p>

style=“font-size: 11pt; font-family: “Calibri”,“sans-serif”; color: rgb(192, 0, 0);”><o:p> </o:p>

style=“font-size: 11pt; font-family: “Calibri”,“sans-serif”; color: rgb(192, 0, 0);”>d<o:p></o:p>

style=“font-size: 11pt; font-family: “Calibri”,“sans-serif”; color: rgb(192, 0, 0);”><o:p> </o:p>

style=“border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; border-width: 1pt medium medium; padding: 3pt 0in 0in;”>

style=“font-size: 10pt; font-family: “Tahoma”,“sans-serif”; color: windowtext;”>From: style=“font-size: 10pt; font-family: “Tahoma”,“sans-serif”; color: windowtext;”>
xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]
On Behalf Of Alexey Polonsky

Sent: Monday, May 21, 2007 2:46 AM

To: Windows System Software Devs Interest List

Subject: Re: [ntdev] Resume virtual COM port after USB
unplug/plugin<o:p></o:p>

<o:p> </o:p>

This should do the job.

Thanks a lot !

Maxim S. Shatskih wrote: <o:p></o:p>

I am looking for a solution that would allow the USB pdo to be properly<o:p></o:p>

removed, while virtual COM pdo is kept perfectly alive as long as the<o:p></o:p>

<o:p></o:p>

<o:p> </o:p>

It must be a PDO independent of USB stack PnP-wise, use IoReportDetectedDevice<o:p></o:p>

to plant a parent of the new PnP tree, and then create children for it.<o:p></o:p>

<o:p> </o:p>

The only relation between these COM ports and the USB driver should be via PnP<o:p></o:p>

device interfaces, not the PnP tree parent-child relation.<o:p></o:p>

<o:p> </o:p>

<o:p></o:p>

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer <o:p></o:p>

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

8

This just doesn’t seem like it would work to me. Any application which
starts receiving failure on i/o and IOCTLs is going to stop talking to
the device. I guess if this application knows that it restarted the
firmware and is expecting errors to be returned, it would work, but this
is definitely not a generic solution. I also urge you to push back and
get the application fixed. You do realize that you are creating a very
complicated mess involving *more* drivers to fix an application. You
are potentially decreasing the stability of the machine for this one
app. If you fix the app, you do not have this horrendous and awful
workaround.

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alexey Polonsky
Sent: Tuesday, May 22, 2007 3:26 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Resume virtual COM port after USB unplug/plugin

Thanks a lot for your comments.

Why are you trying to do this? What problem are you really trying to
solve?

The customer’s app may instruct the device to restart its firmware. The
host sees this as a USB unplug/plug in.
The app was originally written for RS232 (hence the usb-2-serial driver)
and, unfortunately, modifying the app or the firmware is not an option.

As a solution, I need to keep the COM file handle alive across USB
unplug/plugin.

To accomplish this, I am going to create a ROOT enumerated device which
will become a parent of COM children.
When a USB dev is plugged in, a new COM child will be enumerated.
When a USB dev is plugged out:

  • no COM file handle ==> the COM child is removed
  • there is a COM file handle ==> the COM child will fail all
    subsequent read/write/ioctl with IoStatus.Status =
    STATUS_DEVICE_NOT_CONNECTED.
  • COM file handle is closed while USB dev is unplugged ==> the COM
    child is removed
    When the USB dev is plugged in while COM file handle is open, I’ll check
    USB instance id (hwid + physical location), if it’s the same, I’ll
    revive the COM file handle.

Are you going to create a handle for nonexistent hardware before it is
every plugged in?

no

For how long are you going to create handles after the hardware is
gone?

after the HW is gone, the file handle will remain alive until its closed
by the app.

What are you going to do with i/o and IOCTls that expect strict timing
and actual hw response?

All HW related IOCTL’s and Read/Write will fail with IoStatus.Status =
STATUS_DEVICE_NOT_CONNECTED

In the COM port case, I don’t see how this could ever work while the
app has the Com port open and expects it to keep on functioning.

Since the app instructs the device to restart the firmware, it cannot
expect that the device will be functional immediately after that.

Thanks,
Alexey.

Doron Holan wrote:

Why are you trying to do this? What problem are you really trying to
solve? With a solution like this hwere you split the handle away from
the lifetime of the hardware, you also have to consider the following:

Are you going to create a handle for nonexistent hardware before it is
every plugged in?

For how long are you going to create handles after the hardware is gone?

What are you going to do with i/o and IOCTls that expect strict timing
and actual hw response? In the COM port case, I don’t see how this
could ever work while the app has the Com port open and expects it to
keep on functioning.

As for how to enumerate the 2nd stack, IoReportDetectedDevice is not a
supported enumeration method in a KMDF driver. You would have to
install a root enumerated bus driver (like toaster’s busenum) and
communicate with the bus driver to tell it to enumerate you “fake”
device which is not tied to the real presence of hw.

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alexey Polonsky
Sent: Monday, May 21, 2007 2:46 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Resume virtual COM port after USB unplug/plugin

This should do the job.
Thanks a lot !

Maxim S. Shatskih wrote:

I am looking for a solution that would allow the USB pdo to be
properly
removed, while virtual COM pdo is kept perfectly alive as long
as the

It must be a PDO independent of USB stack PnP-wise, use
IoReportDetectedDevice
to plant a parent of the new PnP tree, and then create children for it.

The only relation between these COM ports and the USB driver should be
via PnP
device interfaces, not the PnP tree parent-child relation.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer