How to install an upper filter over USBHUB.SYS

NTDEV
21

No.

I’m filtering the USBHUB FDO, specifically handling
IRP_MN_QUERY_DEVICE_RELATIONS: dynamically attaching to new PDOs and
detaching from known PDOs I don’t find anymore.

Despite what Doron said, I believe I’m handling all the cases correctly.

Guy

xxxxx@yahoo.ca wrote:

To Guy Corem: Can you explain something on how you implement dynamically attaching to usbhub PDOs? That is what I am trying to implement. Do you use the SetupDiXXXX APIs? Thanks

22

To Guy Corem: Do you mean that in your IRP_MN_QUERY_DEVICE_RELATIONS you manually attach to each of the PDOs returned?

23

[QUOTE] You need to do this above each client driver, by the time usbhub sees the i/o request, you could very well be in the wrong thread context, you certainly will not see IRP_MJ_CREATEs at that level. Furthermore, you would have to be a bus filter and dynamically attach to enumerated PDOs as well as PDOs enumerated by usbccgp to be 100% effective in event attempting to see all i/o.

d

Doron, how to “dynamically attach to enumerated PDOs as well as PDOs enumerated by usbccgp”? How can I put my filter below usbccgp? Can I manually create my FiDO and attach it to each PDOs enumerated by usbhub and usbccgp in the IRP_MN_QUERY_DEVICE_RELATION? Thanks.

24

Hi Doron, I installed my filter as USB bus filter. And in my IRP_MN_QUERY_DEVICE_RELATION I can see all the PDOs created by usbhub and usbccgp. Can I manually attach to the PDOs at that point?

Thanks.

Michael

25

Sorry but writing a bus filter driver is not supported and I cannot give
you any advice on how to proceed.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.ca
Sent: Thursday, August 02, 2007 1:35 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to install an upper filter over USBHUB.SYS

[QUOTE] You need to do this above each client driver, by the time usbhub
sees the i/o request, you could very well be in the wrong thread
context, you certainly will not see IRP_MJ_CREATEs at that level.
Furthermore, you would have to be a bus filter and dynamically attach to
enumerated PDOs as well as PDOs enumerated by usbccgp to be 100%
effective in event attempting to see all i/o.

d

Doron, how to “dynamically attach to enumerated PDOs as well as PDOs
enumerated by usbccgp”? How can I put my filter below usbccgp? Can I
manually create my FiDO and attach it to each PDOs enumerated by usbhub
and usbccgp in the IRP_MN_QUERY_DEVICE_RELATION? Thanks.

NTDEV is sponsored by OSR

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

26

Hmm, can you clarify “writing a bus filter driver is not supported”?

This assumes then that one cannot WHQL a bus filter and then the question
is: Why is there a bus filter example in the DDK? (toaster)

Can you point to which documents are available which state that a bus filter
is not supported? (I’m really going to need this documented.)

~kenny

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Sorry but writing a bus filter driver is not supported and I cannot give
you any advice on how to proceed.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.ca
Sent: Thursday, August 02, 2007 1:35 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to install an upper filter over USBHUB.SYS

[QUOTE] You need to do this above each client driver, by the time usbhub
sees the i/o request, you could very well be in the wrong thread
context, you certainly will not see IRP_MJ_CREATEs at that level.
Furthermore, you would have to be a bus filter and dynamically attach to
enumerated PDOs as well as PDOs enumerated by usbccgp to be 100%
effective in event attempting to see all i/o.

d

Doron, how to “dynamically attach to enumerated PDOs as well as PDOs
enumerated by usbccgp”? How can I put my filter below usbccgp? Can I
manually create my FiDO and attach it to each PDOs enumerated by usbhub
and usbccgp in the IRP_MN_QUERY_DEVICE_RELATION? Thanks.

—
NTDEV is sponsored by OSR

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

27

Hi Doron, like what Kenny talked about, why writing a bus filter driver is not supported?

28

I’d like to chime in here too.

There are a fair number of totally legitimate needs for USB bus filters. For me, the requirement was in the area of developing one-of test software to be used in bulk testing of USB-Ethernet devices. I know of similar needs in other areas as well.

When Microsoft says “XYZ is not supported…” it means (to me at least) that I must tell a potential customer:

"Microsoft says that they will not support the software that you need on Windows.

You must abandon Windows as a test or process management platform and switch to an alternative OS to meet your requirements.

You will have to acquire dedicated machines running other OS to be able to perform this work. You will have to re-train your worldwide testers to use this alternative OS."

As a Windows driver developer I don’t like to say this. Not good for business.

Thomas F. Divine

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-296299-
xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.ca
Sent: Friday, August 03, 2007 10:33 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to install an upper filter over USBHUB.SYS

Hi Doron, like what Kenny talked about, why writing a bus filter driver
is not supported?

NTDEV is sponsored by OSR

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

29

First, there is confusion over the term “filter”. There are 3 types of
filters in the OS and I think folks are thinking one type of filter is
another type. The 3 types are

  1. device filters
  2. class filters
  3. bus filters

I covered some of this in my blog,
http://blogs.msdn.com/doronh/archive/2006/09/18/761325.aspx, talking
about device and class filters. Device filters filter a specific device
based on an INF installation of the filter. It can filter above or
below the service driver. Class filters filter devices based on the
class of device they are installed under. This is done by updating the
registry value for the specific class. The scope here is limited by the
class of device. In both of these cases, there is a well known
interface/io type that the filter is modifying. For a device filter, it
could be the specific URBs for a specific device. For a class filter it
could be the incoming I/O for the device as defined by the device
interface. The toaster filter is a device or class filter.

Bus filter drivers are an entire different story. The root device
starts out as an upper device filter, but then becomes something else.
It attaches to each PDO enumerated by the bus driver below it and then
proceeds to do the same for any further PDOs enumerated by the children
it attached to (etc etc). A driver here has no idea about the i/o on
the devices on the bus b/c it is attaching to all of them, so unless it
is modifying generic transactions, the benefit here for what most of you
have said you want to do is zero. For instance, a bus filter is the
wrong technique to create read only personal storage devices (mp3, mass
storage, wpd). The right place is many levels higher at the device
level or the children enumerated by the device you want to filter (for
instance filtering the specific disk stack for a mass storage device
might make more sense than filtering the mass storage FDO).

Thomas, IIRC, you needed to give your devices serial numbers otherwise
you would have had a long install right?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.ca
Sent: Friday, August 03, 2007 7:33 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to install an upper filter over USBHUB.SYS

Hi Doron, like what Kenny talked about, why writing a bus filter driver
is not supported?

NTDEV is sponsored by OSR

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

30

> -----Original Message-----

From: xxxxx@lists.osr.com [mailto:bounce-296313-
xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Friday, August 03, 2007 12:12 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to install an upper filter over USBHUB.SYS

First, there is confusion over the term “filter”. There are 3 types
of
filters in the OS and I think folks are thinking one type of filter is
another type. The 3 types are

  1. device filters
  2. class filters
  3. bus filters

I covered some of this in my blog,
http://blogs.msdn.com/doronh/archive/2006/09/18/761325.aspx, talking
about device and class filters. Device filters filter a specific
device
based on an INF installation of the filter. It can filter above or
below the service driver. Class filters filter devices based on the
class of device they are installed under. This is done by updating the
registry value for the specific class. The scope here is limited by
the
class of device. In both of these cases, there is a well known
interface/io type that the filter is modifying. For a device filter,
it
could be the specific URBs for a specific device. For a class filter
it
could be the incoming I/O for the device as defined by the device
interface. The toaster filter is a device or class filter.

Bus filter drivers are an entire different story. The root device
starts out as an upper device filter, but then becomes something else.
It attaches to each PDO enumerated by the bus driver below it and then
proceeds to do the same for any further PDOs enumerated by the children
it attached to (etc etc). A driver here has no idea about the i/o on
the devices on the bus b/c it is attaching to all of them, so unless it
is modifying generic transactions, the benefit here for what most of
you
have said you want to do is zero. For instance, a bus filter is the
wrong technique to create read only personal storage devices (mp3, mass
storage, wpd). The right place is many levels higher at the device
level or the children enumerated by the device you want to filter (for
instance filtering the specific disk stack for a mass storage device
might make more sense than filtering the mass storage FDO).

Thomas, IIRC, you needed to give your devices serial numbers otherwise
you would have had a long install right?
[PCAUSA] There are several different aspects of testing USB devices for
manufacturing.

First understand that in some cases a wide variety of vendors produce
functionally similar devices (say “USB-Ethernet DSL Modems”). The testing
facility has no design control over the devices.

Devices are to be tested in bulk with as many devices as possible tested
concurrently. The test machine may have several USB host adapters, and for
each test 8 to 16 devices may be tested at one time. (Imagine a boxcar-load
of devices to be tested…). Even better would be to use external powered
USB-hubs (quicker physical connect/disconnect).

Understand that 1.) some devices have unique serial numbers, 2.) some claim
to have unique serial numbers but actually use the same for all and 3.) some
devices have no serial number at all.

There are several issues, and issues may vary depending on the way the
particular lot of devices behaves.

One issue is to provide an clear way for the test technician (first job
after graduating from Burger King…) to relate test software failure
indications with a PHYSICAL USB port. Instructions to tech: “Put RED
sticker on the device connected to port No. 5”.

Second issue is that after several hours of use there are so many registry
entries for new incarnations of devices that the time to bring all 16
devices online becomes intolerable. Must rollback the system.

Third issue is simply the time it takes for the system to detect and load 16
(or more) “identical” USB devices.

The general problem is to deal with multiple concurrent identical USB
devices - not just Ethernet (Multiple USB audio devices come to mind). One
does not have the luxury of specifying only “sane” devices. Customer has
bought a load of “whatever” and that must be used today, something “the same
only different” tomorrow.

Thomas F. Divine

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.ca
Sent: Friday, August 03, 2007 7:33 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to install an upper filter over USBHUB.SYS

Hi Doron, like what Kenny talked about, why writing a bus filter driver
is not supported?

NTDEV is sponsored by OSR

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

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

31

Yes

xxxxx@yahoo.ca wrote:

To Guy Corem: Do you mean that in your IRP_MN_QUERY_DEVICE_RELATIONS you manually attach to each of the PDOs returned?

32

You’ll need to be careful. You’ll find that IRP_MN_QUERY_DEVICE_RELATIONS
is sent more than once, esentially each time the bus is enumerated. it will
also be sent to each to device you attach to, although it’s probably not
supported. You’ll need to track which PDOs you’ve already attached to, else
you’ll attach twice (second time will be higher in the stack). You may also
need to distinguish between a PDO and a bus FDO since your driver is
attaching to both.

~kenny

“Guy Corem” wrote in message news:xxxxx@ntdev…
> Yes
>
> xxxxx@yahoo.ca wrote:
>> To Guy Corem: Do you mean that in your IRP_MN_QUERY_DEVICE_RELATIONS you
>> manually attach to each of the PDOs returned?
>>
>

33

I’m doing all…

Kenny Speer wrote:

You’ll need to be careful. You’ll find that
IRP_MN_QUERY_DEVICE_RELATIONS is sent more than once, esentially each
time the bus is enumerated. it will also be sent to each to device you
attach to, although it’s probably not supported. You’ll need to track
which PDOs you’ve already attached to, else you’ll attach twice (second
time will be higher in the stack). You may also need to distinguish
between a PDO and a bus FDO since your driver is attaching to both.

~kenny

“Guy Corem” wrote in message news:xxxxx@ntdev…
>> Yes
>>
>> xxxxx@yahoo.ca wrote:
>>> To Guy Corem: Do you mean that in your IRP_MN_QUERY_DEVICE_RELATIONS
>>> you manually attach to each of the PDOs returned?
>>>
>>
>
>