USB-COM with persistent handle across disconnect-reconnects.

Hello NTDEV!

Our device is a USB-COM serial device, but we don’t use the usbser.sys driver because the handle is not persistent across resets of the device. Our company has outsourced a driver that would allow a handle to the serial port to be persistent across disconnect-reconnect. The current driver is WDM and has been working for years, but on windows 8/8.1 the driver BSOD’s with the 9F bug check.

Our long term plan is to re-write the driver in WDF.

I’m looking to understand the basic architecture we should be be pursuing for our driver. The initial thought was to create an architecture where:

  1. FDO connected to the USB Device
  2. PDO to enumerate a bus that relays communications and enumerates the serial FDO’s
  3. FDO Serial device to maintain the handle to the user mode application.

My understanding of WDM/WDF is limited yet expanding, and I’m looking for suggestions about how to structure this from a fundamental aspect.

Thank you in advance for your time and effort spent to answer questions!

Hmmmm… Which handle gets closed when who resets which the device, by doing what exactly?

Peter
OSR
@OSRDrivers

These are usually old point of sale terminals that open a com port at the
start of the day, run until close if the store then shutdown.

The problem happens when you unplug or reset the USB scanner device.

Usbser.sys will reattach to the device, but the program still has a handle
to the old com port open, which is not reconnected, and usbser enumerates a
new com port.

The current driver will enumerate a serial port when the device attaches,
and will keep it ‘alive’ as long as a program still has an open handle to
the serial port. The driver will reconnect the serial port to the device if
it was still active. If the device leaves while no handle is open, or the
handle is closed while the device is not attached, then the serial port is
removed from the system.

The idea was to use the bus driver to enumerate the serial port, maintain
the persistence of the serial port side, facilitate the reconnection, and
removal when appropriate.

Let me know any other questions and I will do my best to answer them.
On Sep 3, 2014 4:31 PM, wrote:

> Hmmmm… Which handle gets closed when who resets which the device, by
> doing what exactly?
>
> Peter
> OSR
> @OSRDrivers
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Why not make life simple and write an upper filter driver?

Intercept opens in you filter… Create a separate open between the filter and the FDO. The filter’s open (to the FDO) can get reset or whatever, without affecting the open from the app to the filter.

Pass everything else through…

If that would work it would be *very* simple to implement in KMDF.

Peter
OSR
@OSRDrivers

It would be easier to change the application. Use RegisterDeviceNotification and handle WM_DEVICECHANGE

Wait… If you UNPLUG the device, the FDO will go away. So the filter approach won’t work in that case.

Hmmmm… How about using a root enumerated device then? Same approach exactly as I previously described, just not a filter.

If serusb would really work for you device, it seems ridiculous to write a driver to try to duplicate its functions just for the purpose of managing the open handle problem.

Peter
OSR
@OSRDrivers

Changing the app is certainly a better idea, but I suspect it’s not possible. He said something about “old cash register”…

Peter
OSR
@OSRDrivers

Changing the application is not possible for us as there are 100s of
applications that rely on persistent serial ports, where designed that way,
and the new hardware only has USB. We sell the hardware, not the
application.

In this case we need to have our driver ‘behave’ like a physical serial
port and not remove itself from the system.
On Sep 3, 2014 6:17 PM, wrote:

> It would be easier to change the application. Use
> RegisterDeviceNotification and handle WM_DEVICECHANGE
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

If the driver is not allowing the USB enumerated PDO to complete removal
(by for example blocking things at the FDO level) that might account for
the bugcheck. Instead of hanging the serial PDOs off of a hot-pluggable
FDO, instead a root enumerated FDO could be used for the bus functionality,
allowing the related USB FDOs to come and go as needed and maintaining the
state of the serial PDOs as per your handle based approach.

Mark Roddy

On Wed, Sep 3, 2014 at 7:41 PM, Roscoe Casita
wrote:

> These are usually old point of sale terminals that open a com port at the
> start of the day, run until close if the store then shutdown.
>
> The problem happens when you unplug or reset the USB scanner device.
>
> Usbser.sys will reattach to the device, but the program still has a handle
> to the old com port open, which is not reconnected, and usbser enumerates a
> new com port.
>
> The current driver will enumerate a serial port when the device attaches,
> and will keep it ‘alive’ as long as a program still has an open handle to
> the serial port. The driver will reconnect the serial port to the device if
> it was still active. If the device leaves while no handle is open, or the
> handle is closed while the device is not attached, then the serial port is
> removed from the system.
>
> The idea was to use the bus driver to enumerate the serial port, maintain
> the persistence of the serial port side, facilitate the reconnection, and
> removal when appropriate.
>
> Let me know any other questions and I will do my best to answer them.
> On Sep 3, 2014 4:31 PM, wrote:
>
>> Hmmmm… Which handle gets closed when who resets which the device, by
>> doing what exactly?
>>
>> Peter
>> OSR
>> @OSRDrivers
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
> — NTDEV is sponsored by OSR Visit the list at:
> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

I don’t get it though. If the USB device is disconnected/falls off the bus, the entire stack is unloaded, no matter if you enumerate a child or open the filter. The only way to separate the handle from the stack is to have a separate root enumerated stack which is what is opened by the app.

d

Bent from my phone


From: xxxxx@osr.commailto:xxxxx
Sent: ?9/?3/?2014 6:07 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] USB-COM with persistent handle across disconnect-reconnects.

Why not make life simple and write an upper filter driver?

Intercept opens in you filter… Create a separate open between the filter and the FDO. The filter’s open (to the FDO) can get reset or whatever, without affecting the open from the app to the filter.

Pass everything else through…

If that would work it would be very simple to implement in KMDF.

Peter
OSR
@OSRDrivers


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

Sereunm fails in two ways, one is the invalid handle left behind, the
second is indirectly related to the first.

Serenum will reconnect to the device, and enumerate a new com port because
someone still has a live handle to the old com port.
On Sep 3, 2014 6:20 PM, wrote:

> Wait… If you UNPLUG the device, the FDO will go away. So the filter
> approach won’t work in that case.
>
> Hmmmm… How about using a root enumerated device then? Same approach
> exactly as I previously described, just not a filter.
>
> If serusb would really work for you device, it seems ridiculous to write a
> driver to try to duplicate its functions just for the purpose of managing
> the open handle problem.
>
>
> Peter
> OSR
> @OSRDrivers
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

You must use a root enumerated driver which declares itself to be a com port. It then opens the USB device. If you have N USB devices, you can install N root enumerated devices to match. No need for a bus driver

d

Bent from my phone


From: Roscoe Casitamailto:xxxxx
Sent: ?9/?3/?2014 6:25 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] USB-COM with persistent handle across disconnect-reconnects.

Changing the application is not possible for us as there are 100s of applications that rely on persistent serial ports, where designed that way, and the new hardware only has USB. We sell the hardware, not the application.

In this case we need to have our driver ‘behave’ like a physical serial port and not remove itself from the system.

On Sep 3, 2014 6:17 PM, > wrote:
It would be easier to change the application. Use RegisterDeviceNotification and handle WM_DEVICECHANGE


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>

Serenum does not enumerate com ports, it enumerates devices attached to com ports. Is the app relying on the device serenum enumerates or the COMn name of the port itself?

d

Bent from my phone


From: Roscoe Casitamailto:xxxxx
Sent: ?9/?3/?2014 6:29 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] USB-COM with persistent handle across disconnect-reconnects.

Sereunm fails in two ways, one is the invalid handle left behind, the second is indirectly related to the first.

Serenum will reconnect to the device, and enumerate a new com port because someone still has a live handle to the old com port.

On Sep 3, 2014 6:20 PM, > wrote:
Wait… If you UNPLUG the device, the FDO will go away. So the filter approach won’t work in that case.

Hmmmm… How about using a root enumerated device then? Same approach exactly as I previously described, just not a filter.

If serusb would really work for you device, it seems ridiculous to write a driver to try to duplicate its functions just for the purpose of managing the open handle problem.

Peter
OSR
@OSRDrivers


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>

I believe this is how the current driver works, simple one to one root
enumerated device that reconnects as needed.

The goal is to move this to wdf for maintainability.

I was curious about using the bus based approach to enum the device s as
needed, so that we only have 1 root enumerated bus, with child fdo’s.
On Sep 3, 2014 6:28 PM, “Mark Roddy” wrote:

> If the driver is not allowing the USB enumerated PDO to complete removal
> (by for example blocking things at the FDO level) that might account for
> the bugcheck. Instead of hanging the serial PDOs off of a hot-pluggable
> FDO, instead a root enumerated FDO could be used for the bus functionality,
> allowing the related USB FDOs to come and go as needed and maintaining the
> state of the serial PDOs as per your handle based approach.
>
> Mark Roddy
>
>
> On Wed, Sep 3, 2014 at 7:41 PM, Roscoe Casita
> wrote:
>
>> These are usually old point of sale terminals that open a com port at the
>> start of the day, run until close if the store then shutdown.
>>
>> The problem happens when you unplug or reset the USB scanner device.
>>
>> Usbser.sys will reattach to the device, but the program still has a
>> handle to the old com port open, which is not reconnected, and usbser
>> enumerates a new com port.
>>
>> The current driver will enumerate a serial port when the device attaches,
>> and will keep it ‘alive’ as long as a program still has an open handle to
>> the serial port. The driver will reconnect the serial port to the device if
>> it was still active. If the device leaves while no handle is open, or the
>> handle is closed while the device is not attached, then the serial port is
>> removed from the system.
>>
>> The idea was to use the bus driver to enumerate the serial port, maintain
>> the persistence of the serial port side, facilitate the reconnection, and
>> removal when appropriate.
>>
>> Let me know any other questions and I will do my best to answer them.
>> On Sep 3, 2014 4:31 PM, wrote:
>>
>>> Hmmmm… Which handle gets closed when who resets which the device, by
>>> doing what exactly?
>>>
>>> Peter
>>> OSR
>>> @OSRDrivers
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>>
>>> OSR is HIRING!! See http://www.osr.com/careers
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>> — NTDEV is sponsored by OSR Visit the list at:
>> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
>> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
>> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
>> the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> — NTDEV is sponsored by OSR Visit the list at:
> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

The apps rely upon “comN” to open, so the drive currently makes a symbolic
link.

Sorry for some of my terminology, this is my first real foray into kernel
mode.
On Sep 3, 2014 6:32 PM, “Doron Holan” wrote:

> Serenum does not enumerate com ports, it enumerates devices attached to
> com ports. Is the app relying on the device serenum enumerates or the COMn
> name of the port itself?
>
> d
>
> Bent from my phone
> ------------------------------
> From: Roscoe Casita
> Sent: ‎9/‎3/‎2014 6:29 PM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] USB-COM with persistent handle across
> disconnect-reconnects.
>
> Sereunm fails in two ways, one is the invalid handle left behind, the
> second is indirectly related to the first.
>
> Serenum will reconnect to the device, and enumerate a new com port because
> someone still has a live handle to the old com port.
> On Sep 3, 2014 6:20 PM, wrote:
>
>> Wait… If you UNPLUG the device, the FDO will go away. So the filter
>> approach won’t work in that case.
>>
>> Hmmmm… How about using a root enumerated device then? Same approach
>> exactly as I previously described, just not a filter.
>>
>> If serusb would really work for you device, it seems ridiculous to write
>> a driver to try to duplicate its functions just for the purpose of managing
>> the open handle problem.
>>
>>
>> Peter
>> OSR
>> @OSRDrivers
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
> — NTDEV is sponsored by OSR Visit the list at:
> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Ignore serenum then it doesn’t make a difference for your scenario

d

Bent from my phone


From: Roscoe Casitamailto:xxxxx
Sent: ?9/?3/?2014 6:36 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE: [ntdev] USB-COM with persistent handle across disconnect-reconnects.

The apps rely upon “comN” to open, so the drive currently makes a symbolic link.

Sorry for some of my terminology, this is my first real foray into kernel mode.

On Sep 3, 2014 6:32 PM, “Doron Holan” > wrote:
Serenum does not enumerate com ports, it enumerates devices attached to com ports. Is the app relying on the device serenum enumerates or the COMn name of the port itself?

d

Bent from my phone
________________________________
From: Roscoe Casitamailto:xxxxx
Sent: ?9/?3/?2014 6:29 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] USB-COM with persistent handle across disconnect-reconnects.

Sereunm fails in two ways, one is the invalid handle left behind, the second is indirectly related to the first.

Serenum will reconnect to the device, and enumerate a new com port because someone still has a live handle to the old com port.

On Sep 3, 2014 6:20 PM, > wrote:
Wait… If you UNPLUG the device, the FDO will go away. So the filter approach won’t work in that case.

Hmmmm… How about using a root enumerated device then? Same approach exactly as I previously described, just not a filter.

If serusb would really work for you device, it seems ridiculous to write a driver to try to duplicate its functions just for the purpose of managing the open handle problem.

Peter
OSR
@OSRDrivers


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

You can go with one driver root enumerated N times or have one root enumerated driver that enumerates N PDOs that a second driver loads on.

d

Bent from my phone


From: Roscoe Casitamailto:xxxxx
Sent: ?9/?3/?2014 6:32 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: Re: [ntdev] USB-COM with persistent handle across disconnect-reconnects.

I believe this is how the current driver works, simple one to one root enumerated device that reconnects as needed.

The goal is to move this to wdf for maintainability.

I was curious about using the bus based approach to enum the device s as needed, so that we only have 1 root enumerated bus, with child fdo’s.

On Sep 3, 2014 6:28 PM, “Mark Roddy” > wrote:
If the driver is not allowing the USB enumerated PDO to complete removal (by for example blocking things at the FDO level) that might account for the bugcheck. Instead of hanging the serial PDOs off of a hot-pluggable FDO, instead a root enumerated FDO could be used for the bus functionality, allowing the related USB FDOs to come and go as needed and maintaining the state of the serial PDOs as per your handle based approach.

Mark Roddy

On Wed, Sep 3, 2014 at 7:41 PM, Roscoe Casita > wrote:

These are usually old point of sale terminals that open a com port at the start of the day, run until close if the store then shutdown.

The problem happens when you unplug or reset the USB scanner device.

Usbser.sys will reattach to the device, but the program still has a handle to the old com port open, which is not reconnected, and usbser enumerates a new com port.

The current driver will enumerate a serial port when the device attaches, and will keep it ‘alive’ as long as a program still has an open handle to the serial port. The driver will reconnect the serial port to the device if it was still active. If the device leaves while no handle is open, or the handle is closed while the device is not attached, then the serial port is removed from the system.

The idea was to use the bus driver to enumerate the serial port, maintain the persistence of the serial port side, facilitate the reconnection, and removal when appropriate.

Let me know any other questions and I will do my best to answer them.

On Sep 3, 2014 4:31 PM, > wrote:
Hmmmm… Which handle gets closed when who resets which the device, by doing what exactly?

Peter
OSR
@OSRDrivers


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>

Sorry for the red herring, its an almost example that we wish we could use.
On Sep 3, 2014 6:39 PM, “Doron Holan” wrote:

> Ignore serenum then it doesn’t make a difference for your scenario
>
> d
>
> Bent from my phone
> ------------------------------
> From: Roscoe Casita
> Sent: ‎9/‎3/‎2014 6:36 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] USB-COM with persistent handle across
> disconnect-reconnects.
>
> The apps rely upon “comN” to open, so the drive currently makes a
> symbolic link.
>
> Sorry for some of my terminology, this is my first real foray into kernel
> mode.
> On Sep 3, 2014 6:32 PM, “Doron Holan” wrote:
>
>> Serenum does not enumerate com ports, it enumerates devices attached to
>> com ports. Is the app relying on the device serenum enumerates or the COMn
>> name of the port itself?
>>
>> d
>>
>> Bent from my phone
>> ------------------------------
>> From: Roscoe Casita
>> Sent: ‎9/‎3/‎2014 6:29 PM
>> To: Windows System Software Devs Interest List
>> Subject: RE:[ntdev] USB-COM with persistent handle across
>> disconnect-reconnects.
>>
>> Sereunm fails in two ways, one is the invalid handle left behind, the
>> second is indirectly related to the first.
>>
>> Serenum will reconnect to the device, and enumerate a new com port
>> because someone still has a live handle to the old com port.
>> On Sep 3, 2014 6:20 PM, wrote:
>>
>>> Wait… If you UNPLUG the device, the FDO will go away. So the filter
>>> approach won’t work in that case.
>>>
>>> Hmmmm… How about using a root enumerated device then? Same approach
>>> exactly as I previously described, just not a filter.
>>>
>>> If serusb would really work for you device, it seems ridiculous to write
>>> a driver to try to duplicate its functions just for the purpose of managing
>>> the open handle problem.
>>>
>>>
>>> Peter
>>> OSR
>>> @OSRDrivers
>>>
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>>
>>> OSR is HIRING!! See http://www.osr.com/careers
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>> — NTDEV is sponsored by OSR Visit the list at:
>> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
>> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
>> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
>> the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
> — NTDEV is sponsored by OSR Visit the list at:
> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

What’s the advantages/disadvantages of the two approaches?
On Sep 3, 2014 6:41 PM, “Doron Holan” wrote:

> You can go with one driver root enumerated N times or have one root
> enumerated driver that enumerates N PDOs that a second driver loads on.
>
> d
>
> Bent from my phone
> ------------------------------
> From: Roscoe Casita
> Sent: ‎9/‎3/‎2014 6:32 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] USB-COM with persistent handle across
> disconnect-reconnects.
>
> I believe this is how the current driver works, simple one to one root
> enumerated device that reconnects as needed.
>
> The goal is to move this to wdf for maintainability.
>
> I was curious about using the bus based approach to enum the device s as
> needed, so that we only have 1 root enumerated bus, with child fdo’s.
> On Sep 3, 2014 6:28 PM, “Mark Roddy” wrote:
>
>> If the driver is not allowing the USB enumerated PDO to complete removal
>> (by for example blocking things at the FDO level) that might account for
>> the bugcheck. Instead of hanging the serial PDOs off of a hot-pluggable
>> FDO, instead a root enumerated FDO could be used for the bus functionality,
>> allowing the related USB FDOs to come and go as needed and maintaining the
>> state of the serial PDOs as per your handle based approach.
>>
>> Mark Roddy
>>
>>
>> On Wed, Sep 3, 2014 at 7:41 PM, Roscoe Casita
>> wrote:
>>
>>> These are usually old point of sale terminals that open a com port at
>>> the start of the day, run until close if the store then shutdown.
>>>
>>> The problem happens when you unplug or reset the USB scanner device.
>>>
>>> Usbser.sys will reattach to the device, but the program still has a
>>> handle to the old com port open, which is not reconnected, and usbser
>>> enumerates a new com port.
>>>
>>> The current driver will enumerate a serial port when the device
>>> attaches, and will keep it ‘alive’ as long as a program still has an open
>>> handle to the serial port. The driver will reconnect the serial port to the
>>> device if it was still active. If the device leaves while no handle is
>>> open, or the handle is closed while the device is not attached, then the
>>> serial port is removed from the system.
>>>
>>> The idea was to use the bus driver to enumerate the serial port,
>>> maintain the persistence of the serial port side, facilitate the
>>> reconnection, and removal when appropriate.
>>>
>>> Let me know any other questions and I will do my best to answer them.
>>> On Sep 3, 2014 4:31 PM, wrote:
>>>
>>>> Hmmmm… Which handle gets closed when who resets which the device, by
>>>> doing what exactly?
>>>>
>>>> Peter
>>>> OSR
>>>> @OSRDrivers
>>>>
>>>> —
>>>> NTDEV is sponsored by OSR
>>>>
>>>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>>>
>>>> OSR is HIRING!! See http://www.osr.com/careers
>>>>
>>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>>> http://www.osr.com/seminars
>>>>
>>>> To unsubscribe, visit the List Server section of OSR Online at
>>>> http://www.osronline.com/page.cfm?name=ListServer
>>>>
>>> — NTDEV is sponsored by OSR Visit the list at:
>>> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
>>> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
>>> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
>>> the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>
>> — NTDEV is sponsored by OSR Visit the list at:
>> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
>> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
>> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
>> the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
> — NTDEV is sponsored by OSR Visit the list at:
> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Thank you again for the advise! I will abandon looking at bus drivers until
further notice =)
On Sep 3, 2014 6:45 PM, “Roscoe Casita” wrote:

> What’s the advantages/disadvantages of the two approaches?
> On Sep 3, 2014 6:41 PM, “Doron Holan” wrote:
>
>> You can go with one driver root enumerated N times or have one root
>> enumerated driver that enumerates N PDOs that a second driver loads on.
>>
>> d
>>
>> Bent from my phone
>> ------------------------------
>> From: Roscoe Casita
>> Sent: ‎9/‎3/‎2014 6:32 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re: [ntdev] USB-COM with persistent handle across
>> disconnect-reconnects.
>>
>> I believe this is how the current driver works, simple one to one root
>> enumerated device that reconnects as needed.
>>
>> The goal is to move this to wdf for maintainability.
>>
>> I was curious about using the bus based approach to enum the device s as
>> needed, so that we only have 1 root enumerated bus, with child fdo’s.
>> On Sep 3, 2014 6:28 PM, “Mark Roddy” wrote:
>>
>>> If the driver is not allowing the USB enumerated PDO to complete removal
>>> (by for example blocking things at the FDO level) that might account for
>>> the bugcheck. Instead of hanging the serial PDOs off of a hot-pluggable
>>> FDO, instead a root enumerated FDO could be used for the bus functionality,
>>> allowing the related USB FDOs to come and go as needed and maintaining the
>>> state of the serial PDOs as per your handle based approach.
>>>
>>> Mark Roddy
>>>
>>>
>>> On Wed, Sep 3, 2014 at 7:41 PM, Roscoe Casita
>>> wrote:
>>>
>>>> These are usually old point of sale terminals that open a com port at
>>>> the start of the day, run until close if the store then shutdown.
>>>>
>>>> The problem happens when you unplug or reset the USB scanner device.
>>>>
>>>> Usbser.sys will reattach to the device, but the program still has a
>>>> handle to the old com port open, which is not reconnected, and usbser
>>>> enumerates a new com port.
>>>>
>>>> The current driver will enumerate a serial port when the device
>>>> attaches, and will keep it ‘alive’ as long as a program still has an open
>>>> handle to the serial port. The driver will reconnect the serial port to the
>>>> device if it was still active. If the device leaves while no handle is
>>>> open, or the handle is closed while the device is not attached, then the
>>>> serial port is removed from the system.
>>>>
>>>> The idea was to use the bus driver to enumerate the serial port,
>>>> maintain the persistence of the serial port side, facilitate the
>>>> reconnection, and removal when appropriate.
>>>>
>>>> Let me know any other questions and I will do my best to answer them.
>>>> On Sep 3, 2014 4:31 PM, wrote:
>>>>
>>>>> Hmmmm… Which handle gets closed when who resets which the device, by
>>>>> doing what exactly?
>>>>>
>>>>> Peter
>>>>> OSR
>>>>> @OSRDrivers
>>>>>
>>>>> —
>>>>> NTDEV is sponsored by OSR
>>>>>
>>>>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>>>>
>>>>> OSR is HIRING!! See http://www.osr.com/careers
>>>>>
>>>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>>>> http://www.osr.com/seminars
>>>>>
>>>>> To unsubscribe, visit the List Server section of OSR Online at
>>>>> http://www.osronline.com/page.cfm?name=ListServer
>>>>>
>>>> — NTDEV is sponsored by OSR Visit the list at:
>>>> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
>>>> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
>>>> other seminars visit: http://www.osr.com/seminars To unsubscribe,
>>>> visit the List Server section of OSR Online at
>>>> http://www.osronline.com/page.cfm?name=ListServer
>>>>
>>>
>>> — NTDEV is sponsored by OSR Visit the list at:
>>> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
>>> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
>>> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
>>> the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>
>> — NTDEV is sponsored by OSR Visit the list at:
>> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
>> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
>> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
>> the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>