Device Interface Class Filter

Hi,
In Wlater Oney’s book (Chapter 6, Page 358) when discussing PnP
notifications it is mentioned that:

“One way to use these notifications is to implement a filter driver for an
entire class of device interfaces. (There is a standard way to implement
filter drivers, either for a single driver or for a class of devices, based
on setting entries in the registry. Here, I’m talking about filtering all
devices that register a particular interface, for which there’s no other
mechanism.)”

However, the DDK documentation mentions that:

“After the IRP_MN_START_DEVICE request completes, the PnP manager issues
device interface arrival notifications to any kernel-mode or user-mode
components that requested them.”

In a previous thread we had here we came to the conclusion that a driver
must not attach a device to a device stack that is already started.

How is it possible then to attach as a filter to a device stack in a
notification callback like Oney suggested if the documentation clearly
states that the notification callback will only be called after the
IRP_MN_START_DEVICE request completes (which to my best understanding means
that it is too late to attach since the device is already started) ?

Thanks,
Shahar

A class filter driver, like kbdclass or mouclass, are attached to the
stack before start device. Class filter drivers do not use the
interface registration as a way of being notified of a stack, rather,
they are instantiated on the stack by the pnp manager based on a
registry key for the class itself.

Look at this key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class{4D36E96B-E325
-11CE-BFC1-08002BE10318}

Under there, you will see an UpperFilters value. This works just like
the UpperFilters value in the device’s key except it is applied to all
devices of that setup class.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Sunday, October 10, 2004 8:42 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Device Interface Class Filter

Hi,
In Wlater Oney’s book (Chapter 6, Page 358) when discussing PnP
notifications it is mentioned that:

“One way to use these notifications is to implement a filter driver for
an
entire class of device interfaces. (There is a standard way to implement
filter drivers, either for a single driver or for a class of devices,
based
on setting entries in the registry. Here, I’m talking about filtering
all
devices that register a particular interface, for which there’s no other
mechanism.)”

However, the DDK documentation mentions that:

“After the IRP_MN_START_DEVICE request completes, the PnP manager issues
device interface arrival notifications to any kernel-mode or user-mode
components that requested them.”

In a previous thread we had here we came to the conclusion that a driver
must not attach a device to a device stack that is already started.

How is it possible then to attach as a filter to a device stack in a
notification callback like Oney suggested if the documentation clearly
states that the notification callback will only be called after the
IRP_MN_START_DEVICE request completes (which to my best understanding
means
that it is too late to attach since the device is already started) ?

Thanks,
Shahar


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

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Hi Doron,
I am familiar with class filter drivers, however I think that Walter Oney
described a different type of filter driver (note the parts I marked with
three stars).

“There is a standard way to implement filter drivers, ***either for a single
driver or for a class of devices***, based on setting entries in the
registry. Here, I’m talking about ***filtering all devices that register a
particular interface***, for which there’s no other mechanism.”

The filter driver Oney is describing is capable of filtering all device that
register a particular interface, even if they are installed in many kinds of
setup classes.
The quote I brought from the book implies it is possible to use pnp
notifications in order to implement this.
Yet, I wonder how can it be possible if the notifications are generated only
after the device starts.

Thanks,
Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Sunday, October 10, 2004 7:00 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

A class filter driver, like kbdclass or mouclass, are attached to the stack
before start device. Class filter drivers do not use the interface
registration as a way of being notified of a stack, rather, they are
instantiated on the stack by the pnp manager based on a registry key for the
class itself.

Look at this key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class{4D36E96B-E325
-11CE-BFC1-08002BE10318}

Under there, you will see an UpperFilters value. This works just like the
UpperFilters value in the device’s key except it is applied to all devices
of that setup class.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Sunday, October 10, 2004 8:42 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Device Interface Class Filter

Hi,
In Wlater Oney’s book (Chapter 6, Page 358) when discussing PnP
notifications it is mentioned that:

“One way to use these notifications is to implement a filter driver for an
entire class of device interfaces. (There is a standard way to implement
filter drivers, either for a single driver or for a class of devices, based
on setting entries in the registry. Here, I’m talking about filtering all
devices that register a particular interface, for which there’s no other
mechanism.)”

However, the DDK documentation mentions that:

“After the IRP_MN_START_DEVICE request completes, the PnP manager issues
device interface arrival notifications to any kernel-mode or user-mode
components that requested them.”

In a previous thread we had here we came to the conclusion that a driver
must not attach a device to a device stack that is already started.

How is it possible then to attach as a filter to a device stack in a
notification callback like Oney suggested if the documentation clearly
states that the notification callback will only be called after the
IRP_MN_START_DEVICE request completes (which to my best understanding means
that it is too late to attach since the device is already started) ?

Thanks,
Shahar


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

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

You can attach a filter after start device, however such a filter is not
guaranteed (by this mechanism alone) to be attached before other components
have opened the device in question. I don’t want to put words in Walter’s
mouth, but I think perhaps he is suggesting a possible solution path,
without providing the entire solution itself.

If you can solve the race condition with other components opening the device
then you can safely use this approach. Note that the ddk forbids opening the
device in the notification thread context as it claims there is a potential
deadlock.

If in fact your device interface is supported by a small number of classes,
then perhaps the class filter driver is a simpler approach.

=====================
Mark Roddy
Windows .NET/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Monday, October 11, 2004 4:22 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

Hi Doron,
I am familiar with class filter drivers, however I think that
Walter Oney described a different type of filter driver (note
the parts I marked with three stars).

“There is a standard way to implement filter drivers,
***either for a single driver or for a class of devices***,
based on setting entries in the registry. Here, I’m talking
about ***filtering all devices that register a particular
interface***, for which there’s no other mechanism.”

The filter driver Oney is describing is capable of filtering
all device that register a particular interface, even if they
are installed in many kinds of setup classes.
The quote I brought from the book implies it is possible to
use pnp notifications in order to implement this.
Yet, I wonder how can it be possible if the notifications are
generated only after the device starts.

Thanks,
Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Sunday, October 10, 2004 7:00 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

A class filter driver, like kbdclass or mouclass, are
attached to the stack before start device. Class filter
drivers do not use the interface registration as a way of
being notified of a stack, rather, they are instantiated on
the stack by the pnp manager based on a registry key for the
class itself.

Look at this key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class{4D3
6E96B-E325
-11CE-BFC1-08002BE10318}

Under there, you will see an UpperFilters value. This works
just like the UpperFilters value in the device’s key except
it is applied to all devices of that setup class.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Sunday, October 10, 2004 8:42 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Device Interface Class Filter

Hi,
In Wlater Oney’s book (Chapter 6, Page 358) when discussing
PnP notifications it is mentioned that:

“One way to use these notifications is to implement a filter
driver for an entire class of device interfaces. (There is a
standard way to implement filter drivers, either for a single
driver or for a class of devices, based on setting entries in
the registry. Here, I’m talking about filtering all devices
that register a particular interface, for which there’s no
other mechanism.)”

However, the DDK documentation mentions that:

“After the IRP_MN_START_DEVICE request completes, the PnP
manager issues device interface arrival notifications to any
kernel-mode or user-mode components that requested them.”

In a previous thread we had here we came to the conclusion
that a driver must not attach a device to a device stack that
is already started.

How is it possible then to attach as a filter to a device
stack in a notification callback like Oney suggested if the
documentation clearly states that the notification callback
will only be called after the IRP_MN_START_DEVICE request
completes (which to my best understanding means that it is
too late to attach since the device is already started) ?

Thanks,
Shahar


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

You are currently subscribed to ntdev as:
xxxxx@windows.microsoft.com To unsubscribe send a blank
email to xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as:
xxxxx@hollistech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com

Okay, thanks.
Can you suggest a way to solve this race condition or maybe point me to some
documentation or examples of such mechanisms ?

Thanks for your help,
Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, October 11, 2004 2:40 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

You can attach a filter after start device, however such a filter is not
guaranteed (by this mechanism alone) to be attached before other components
have opened the device in question. I don’t want to put words in Walter’s
mouth, but I think perhaps he is suggesting a possible solution path,
without providing the entire solution itself.

If you can solve the race condition with other components opening the device
then you can safely use this approach. Note that the ddk forbids opening the
device in the notification thread context as it claims there is a potential
deadlock.

If in fact your device interface is supported by a small number of classes,
then perhaps the class filter driver is a simpler approach.

=====================
Mark Roddy
Windows .NET/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032 www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Monday, October 11, 2004 4:22 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

Hi Doron,
I am familiar with class filter drivers, however I think that Walter
Oney described a different type of filter driver (note the parts I
marked with three stars).

“There is a standard way to implement filter drivers, ***either for a
single driver or for a class of devices***, based on setting entries
in the registry. Here, I’m talking about ***filtering all devices that
register a particular interface***, for which there’s no other
mechanism.”

The filter driver Oney is describing is capable of filtering all
device that register a particular interface, even if they are
installed in many kinds of setup classes.
The quote I brought from the book implies it is possible to use pnp
notifications in order to implement this.
Yet, I wonder how can it be possible if the notifications are
generated only after the device starts.

Thanks,
Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Sunday, October 10, 2004 7:00 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

A class filter driver, like kbdclass or mouclass, are attached to the
stack before start device. Class filter drivers do not use the
interface registration as a way of being notified of a stack, rather,
they are instantiated on the stack by the pnp manager based on a
registry key for the class itself.

Look at this key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class{4D3
6E96B-E325
-11CE-BFC1-08002BE10318}

Under there, you will see an UpperFilters value. This works just like
the UpperFilters value in the device’s key except it is applied to all
devices of that setup class.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Sunday, October 10, 2004 8:42 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Device Interface Class Filter

Hi,
In Wlater Oney’s book (Chapter 6, Page 358) when discussing PnP
notifications it is mentioned that:

“One way to use these notifications is to implement a filter driver
for an entire class of device interfaces. (There is a standard way to
implement filter drivers, either for a single driver or for a class of
devices, based on setting entries in the registry. Here, I’m talking
about filtering all devices that register a particular interface, for
which there’s no other mechanism.)”

However, the DDK documentation mentions that:

“After the IRP_MN_START_DEVICE request completes, the PnP manager
issues device interface arrival notifications to any kernel-mode or
user-mode components that requested them.”

In a previous thread we had here we came to the conclusion that a
driver must not attach a device to a device stack that is already
started.

How is it possible then to attach as a filter to a device stack in a
notification callback like Oney suggested if the documentation clearly
states that the notification callback will only be called after the
IRP_MN_START_DEVICE request completes (which to my best understanding
means that it is too late to attach since the device is already
started) ?

Thanks,
Shahar


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

You are currently subscribed to ntdev as:
xxxxx@windows.microsoft.com To unsubscribe send a blank email to
xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as:
xxxxx@hollistech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as: xxxxx@safend.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

> Okay, thanks.

Can you suggest a way to solve this race condition or maybe
point me to some documentation or examples of such mechanisms ?

No, you are going to have to figure this one out on your own. The solution
depends on your specific requirements, and there may very well be no
solution for whatever it is you are doing.

Thanks for your help,
Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, October 11, 2004 2:40 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

You can attach a filter after start device, however such a
filter is not guaranteed (by this mechanism alone) to be
attached before other components have opened the device in
question. I don’t want to put words in Walter’s mouth, but I
think perhaps he is suggesting a possible solution path,
without providing the entire solution itself.

If you can solve the race condition with other components
opening the device then you can safely use this approach.
Note that the ddk forbids opening the device in the
notification thread context as it claims there is a potential
deadlock.

If in fact your device interface is supported by a small
number of classes, then perhaps the class filter driver is a
simpler approach.

=====================
Mark Roddy
Windows .NET/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032 www.hollistech.com

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
> Sent: Monday, October 11, 2004 4:22 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Device Interface Class Filter
>
> Hi Doron,
> I am familiar with class filter drivers, however I think
that Walter
> Oney described a different type of filter driver (note the parts I
> marked with three stars).
>
> “There is a standard way to implement filter drivers,
***either for a
> single driver or for a class of devices***, based on
setting entries
> in the registry. Here, I’m talking about ***filtering all
devices that
> register a particular interface***, for which there’s no other
> mechanism.”
>
> The filter driver Oney is describing is capable of filtering all
> device that register a particular interface, even if they are
> installed in many kinds of setup classes.
> The quote I brought from the book implies it is possible to use pnp
> notifications in order to implement this.
> Yet, I wonder how can it be possible if the notifications are
> generated only after the device starts.
>
> Thanks,
> Shahar
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
> Sent: Sunday, October 10, 2004 7:00 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Device Interface Class Filter
>
> A class filter driver, like kbdclass or mouclass, are
attached to the
> stack before start device. Class filter drivers do not use the
> interface registration as a way of being notified of a
stack, rather,
> they are instantiated on the stack by the pnp manager based on a
> registry key for the class itself.
>
> Look at this key:
>
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class{4D3
> 6E96B-E325
> -11CE-BFC1-08002BE10318}
>
> Under there, you will see an UpperFilters value. This
works just like
> the UpperFilters value in the device’s key except it is
applied to all
> devices of that setup class.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
> Sent: Sunday, October 10, 2004 8:42 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Device Interface Class Filter
>
> Hi,
> In Wlater Oney’s book (Chapter 6, Page 358) when discussing PnP
> notifications it is mentioned that:
>
> “One way to use these notifications is to implement a filter driver
> for an entire class of device interfaces. (There is a
standard way to
> implement filter drivers, either for a single driver or for
a class of
> devices, based on setting entries in the registry. Here,
I’m talking
> about filtering all devices that register a particular
interface, for
> which there’s no other mechanism.)”
>
> However, the DDK documentation mentions that:
>
> “After the IRP_MN_START_DEVICE request completes, the PnP manager
> issues device interface arrival notifications to any kernel-mode or
> user-mode components that requested them.”
>
> In a previous thread we had here we came to the conclusion that a
> driver must not attach a device to a device stack that is already
> started.
>
> How is it possible then to attach as a filter to a device
stack in a
> notification callback like Oney suggested if the
documentation clearly
> states that the notification callback will only be called after the
> IRP_MN_START_DEVICE request completes (which to my best
understanding
> means that it is too late to attach since the device is already
> started) ?
>
> Thanks,
> Shahar
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@windows.microsoft.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
> argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@hollistech.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>


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

You are currently subscribed to ntdev as: xxxxx@safend.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as:
xxxxx@hollistech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com

Don’t you believe there is a generic solution for this problem ?
Say I would like to filter all devices that register a
GUID_DEVINTERFACE_USB_DEVICE device interface for example.
How would you suggest to attach to those devices after they start ?

Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, October 11, 2004 3:56 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

Okay, thanks.
Can you suggest a way to solve this race condition or maybe point me
to some documentation or examples of such mechanisms ?

No, you are going to have to figure this one out on your own. The solution
depends on your specific requirements, and there may very well be no
solution for whatever it is you are doing.

Thanks for your help,
Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, October 11, 2004 2:40 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

You can attach a filter after start device, however such a filter is
not guaranteed (by this mechanism alone) to be attached before other
components have opened the device in question. I don’t want to put
words in Walter’s mouth, but I think perhaps he is suggesting a
possible solution path, without providing the entire solution itself.

If you can solve the race condition with other components opening the
device then you can safely use this approach.
Note that the ddk forbids opening the device in the notification
thread context as it claims there is a potential deadlock.

If in fact your device interface is supported by a small number of
classes, then perhaps the class filter driver is a simpler approach.

=====================
Mark Roddy
Windows .NET/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032 www.hollistech.com

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
> Sent: Monday, October 11, 2004 4:22 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Device Interface Class Filter
>
> Hi Doron,
> I am familiar with class filter drivers, however I think
that Walter
> Oney described a different type of filter driver (note the parts I
> marked with three stars).
>
> “There is a standard way to implement filter drivers,
***either for a
> single driver or for a class of devices***, based on
setting entries
> in the registry. Here, I’m talking about ***filtering all
devices that
> register a particular interface***, for which there’s no other
> mechanism.”
>
> The filter driver Oney is describing is capable of filtering all
> device that register a particular interface, even if they are
> installed in many kinds of setup classes.
> The quote I brought from the book implies it is possible to use pnp
> notifications in order to implement this.
> Yet, I wonder how can it be possible if the notifications are
> generated only after the device starts.
>
> Thanks,
> Shahar
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
> Sent: Sunday, October 10, 2004 7:00 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Device Interface Class Filter
>
> A class filter driver, like kbdclass or mouclass, are
attached to the
> stack before start device. Class filter drivers do not use the
> interface registration as a way of being notified of a
stack, rather,
> they are instantiated on the stack by the pnp manager based on a
> registry key for the class itself.
>
> Look at this key:
>
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class{4D3
> 6E96B-E325
> -11CE-BFC1-08002BE10318}
>
> Under there, you will see an UpperFilters value. This
works just like
> the UpperFilters value in the device’s key except it is
applied to all
> devices of that setup class.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
> Sent: Sunday, October 10, 2004 8:42 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Device Interface Class Filter
>
> Hi,
> In Wlater Oney’s book (Chapter 6, Page 358) when discussing PnP
> notifications it is mentioned that:
>
> “One way to use these notifications is to implement a filter driver
> for an entire class of device interfaces. (There is a
standard way to
> implement filter drivers, either for a single driver or for
a class of
> devices, based on setting entries in the registry. Here,
I’m talking
> about filtering all devices that register a particular
interface, for
> which there’s no other mechanism.)”
>
> However, the DDK documentation mentions that:
>
> “After the IRP_MN_START_DEVICE request completes, the PnP manager
> issues device interface arrival notifications to any kernel-mode or
> user-mode components that requested them.”
>
> In a previous thread we had here we came to the conclusion that a
> driver must not attach a device to a device stack that is already
> started.
>
> How is it possible then to attach as a filter to a device
stack in a
> notification callback like Oney suggested if the
documentation clearly
> states that the notification callback will only be called after the
> IRP_MN_START_DEVICE request completes (which to my best
understanding
> means that it is too late to attach since the device is already
> started) ?
>
> Thanks,
> Shahar
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@windows.microsoft.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
> argument: ‘’
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@hollistech.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>


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

You are currently subscribed to ntdev as: xxxxx@safend.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as:
xxxxx@hollistech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as: xxxxx@safend.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

Since each USB device can potentially be in a different device class and
load a different FDO, there is no generic answer.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Monday, October 11, 2004 8:08 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

Don’t you believe there is a generic solution for this problem ?
Say I would like to filter all devices that register a
GUID_DEVINTERFACE_USB_DEVICE device interface for example.
How would you suggest to attach to those devices after they start ?

Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, October 11, 2004 3:56 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

Okay, thanks.
Can you suggest a way to solve this race condition or maybe point me
to some documentation or examples of such mechanisms ?

No, you are going to have to figure this one out on your own. The
solution
depends on your specific requirements, and there may very well be no
solution for whatever it is you are doing.

Thanks for your help,
Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, October 11, 2004 2:40 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

You can attach a filter after start device, however such a filter is
not guaranteed (by this mechanism alone) to be attached before other
components have opened the device in question. I don’t want to put
words in Walter’s mouth, but I think perhaps he is suggesting a
possible solution path, without providing the entire solution itself.

If you can solve the race condition with other components opening the
device then you can safely use this approach.
Note that the ddk forbids opening the device in the notification
thread context as it claims there is a potential deadlock.

If in fact your device interface is supported by a small number of
classes, then perhaps the class filter driver is a simpler approach.

=====================
Mark Roddy
Windows .NET/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032 www.hollistech.com

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
> Sent: Monday, October 11, 2004 4:22 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Device Interface Class Filter
>
> Hi Doron,
> I am familiar with class filter drivers, however I think
that Walter
> Oney described a different type of filter driver (note the parts I
> marked with three stars).
>
> “There is a standard way to implement filter drivers,
***either for a
> single driver or for a class of devices***, based on
setting entries
> in the registry. Here, I’m talking about ***filtering all
devices that
> register a particular interface***, for which there’s no other
> mechanism.”
>
> The filter driver Oney is describing is capable of filtering all
> device that register a particular interface, even if they are
> installed in many kinds of setup classes.
> The quote I brought from the book implies it is possible to use pnp
> notifications in order to implement this.
> Yet, I wonder how can it be possible if the notifications are
> generated only after the device starts.
>
> Thanks,
> Shahar
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
> Sent: Sunday, October 10, 2004 7:00 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Device Interface Class Filter
>
> A class filter driver, like kbdclass or mouclass, are
attached to the
> stack before start device. Class filter drivers do not use the
> interface registration as a way of being notified of a
stack, rather,
> they are instantiated on the stack by the pnp manager based on a
> registry key for the class itself.
>
> Look at this key:
>
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class{4D3
> 6E96B-E325
> -11CE-BFC1-08002BE10318}
>
> Under there, you will see an UpperFilters value. This
works just like
> the UpperFilters value in the device’s key except it is
applied to all
> devices of that setup class.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
> Sent: Sunday, October 10, 2004 8:42 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Device Interface Class Filter
>
> Hi,
> In Wlater Oney’s book (Chapter 6, Page 358) when discussing PnP
> notifications it is mentioned that:
>
> “One way to use these notifications is to implement a filter driver
> for an entire class of device interfaces. (There is a
standard way to
> implement filter drivers, either for a single driver or for
a class of
> devices, based on setting entries in the registry. Here,
I’m talking
> about filtering all devices that register a particular
interface, for
> which there’s no other mechanism.)”
>
> However, the DDK documentation mentions that:
>
> “After the IRP_MN_START_DEVICE request completes, the PnP manager
> issues device interface arrival notifications to any kernel-mode or
> user-mode components that requested them.”
>
> In a previous thread we had here we came to the conclusion that a
> driver must not attach a device to a device stack that is already
> started.
>
> How is it possible then to attach as a filter to a device
stack in a
> notification callback like Oney suggested if the
documentation clearly
> states that the notification callback will only be called after the
> IRP_MN_START_DEVICE request completes (which to my best
understanding
> means that it is too late to attach since the device is already
> started) ?
>
> Thanks,
> Shahar
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@windows.microsoft.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
> argument: ‘’
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@hollistech.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>


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

You are currently subscribed to ntdev as: xxxxx@safend.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as:
xxxxx@hollistech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as: xxxxx@safend.com To
unsubscribe
send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

No - there’s no generic way to safely attach a filter to a stack after
it’s been started, so there’s way to perform this specific feat.

Is that really what you’re interested in - filtering
GUID_DEVINTERFACE_USB_DEVICE? What would that accomplish?

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Monday, October 11, 2004 8:08 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

Don’t you believe there is a generic solution for this problem ?
Say I would like to filter all devices that register a
GUID_DEVINTERFACE_USB_DEVICE device interface for example.
How would you suggest to attach to those devices after they start ?

Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, October 11, 2004 3:56 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

Okay, thanks.
Can you suggest a way to solve this race condition or maybe point me
to some documentation or examples of such mechanisms ?

No, you are going to have to figure this one out on your own. The
solution depends on your specific requirements, and there may very well
be no solution for whatever it is you are doing.

Thanks for your help,
Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, October 11, 2004 2:40 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

You can attach a filter after start device, however such a filter is
not guaranteed (by this mechanism alone) to be attached before other
components have opened the device in question. I don’t want to put
words in Walter’s mouth, but I think perhaps he is suggesting a
possible solution path, without providing the entire solution itself.

If you can solve the race condition with other components opening the
device then you can safely use this approach.
Note that the ddk forbids opening the device in the notification
thread context as it claims there is a potential deadlock.

If in fact your device interface is supported by a small number of
classes, then perhaps the class filter driver is a simpler approach.

=====================
Mark Roddy
Windows .NET/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032 www.hollistech.com

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
> Sent: Monday, October 11, 2004 4:22 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Device Interface Class Filter
>
> Hi Doron,
> I am familiar with class filter drivers, however I think
that Walter
> Oney described a different type of filter driver (note the parts I
> marked with three stars).
>
> “There is a standard way to implement filter drivers,
***either for a
> single driver or for a class of devices***, based on
setting entries
> in the registry. Here, I’m talking about ***filtering all
devices that
> register a particular interface***, for which there’s no other
> mechanism.”
>
> The filter driver Oney is describing is capable of filtering all
> device that register a particular interface, even if they are
> installed in many kinds of setup classes.
> The quote I brought from the book implies it is possible to use pnp
> notifications in order to implement this.
> Yet, I wonder how can it be possible if the notifications are
> generated only after the device starts.
>
> Thanks,
> Shahar
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
> Sent: Sunday, October 10, 2004 7:00 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Device Interface Class Filter
>
> A class filter driver, like kbdclass or mouclass, are
attached to the
> stack before start device. Class filter drivers do not use the
> interface registration as a way of being notified of a
stack, rather,
> they are instantiated on the stack by the pnp manager based on a
> registry key for the class itself.
>
> Look at this key:
>
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class{4D3
> 6E96B-E325
> -11CE-BFC1-08002BE10318}
>
> Under there, you will see an UpperFilters value. This
works just like
> the UpperFilters value in the device’s key except it is
applied to all
> devices of that setup class.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
> Sent: Sunday, October 10, 2004 8:42 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Device Interface Class Filter
>
> Hi,
> In Wlater Oney’s book (Chapter 6, Page 358) when discussing PnP
> notifications it is mentioned that:
>
> “One way to use these notifications is to implement a filter driver
> for an entire class of device interfaces. (There is a
standard way to
> implement filter drivers, either for a single driver or for
a class of
> devices, based on setting entries in the registry. Here,
I’m talking
> about filtering all devices that register a particular
interface, for
> which there’s no other mechanism.)”
>
> However, the DDK documentation mentions that:
>
> “After the IRP_MN_START_DEVICE request completes, the PnP manager
> issues device interface arrival notifications to any kernel-mode or
> user-mode components that requested them.”
>
> In a previous thread we had here we came to the conclusion that a
> driver must not attach a device to a device stack that is already
> started.
>
> How is it possible then to attach as a filter to a device
stack in a
> notification callback like Oney suggested if the
documentation clearly
> states that the notification callback will only be called after the
> IRP_MN_START_DEVICE request completes (which to my best
understanding
> means that it is too late to attach since the device is already
> started) ?
>
> Thanks,
> Shahar
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@windows.microsoft.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
> argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@hollistech.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>


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

You are currently subscribed to ntdev as: xxxxx@safend.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as:
xxxxx@hollistech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as: xxxxx@safend.com To
unsubscribe
send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

What I am trying to accomplish is much more complicated than this,
GUID_DEVINTERFACE_USB_DEVICE was just a good example for a device interface
which is used by devices from many setup classes. It sounds pretty weird
that Walter Oney would mention an architecture which is so problematic to
implement…

Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, October 11, 2004 11:04 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

No - there’s no generic way to safely attach a filter to a stack after it’s
been started, so there’s way to perform this specific feat.

Is that really what you’re interested in - filtering
GUID_DEVINTERFACE_USB_DEVICE? What would that accomplish?

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Monday, October 11, 2004 8:08 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

Don’t you believe there is a generic solution for this problem ?
Say I would like to filter all devices that register a
GUID_DEVINTERFACE_USB_DEVICE device interface for example.
How would you suggest to attach to those devices after they start ?

Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, October 11, 2004 3:56 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

Okay, thanks.
Can you suggest a way to solve this race condition or maybe point me
to some documentation or examples of such mechanisms ?

No, you are going to have to figure this one out on your own. The solution
depends on your specific requirements, and there may very well be no
solution for whatever it is you are doing.

Thanks for your help,
Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, October 11, 2004 2:40 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

You can attach a filter after start device, however such a filter is
not guaranteed (by this mechanism alone) to be attached before other
components have opened the device in question. I don’t want to put
words in Walter’s mouth, but I think perhaps he is suggesting a
possible solution path, without providing the entire solution itself.

If you can solve the race condition with other components opening the
device then you can safely use this approach.
Note that the ddk forbids opening the device in the notification
thread context as it claims there is a potential deadlock.

If in fact your device interface is supported by a small number of
classes, then perhaps the class filter driver is a simpler approach.

=====================
Mark Roddy
Windows .NET/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032 www.hollistech.com

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
> Sent: Monday, October 11, 2004 4:22 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Device Interface Class Filter
>
> Hi Doron,
> I am familiar with class filter drivers, however I think
that Walter
> Oney described a different type of filter driver (note the parts I
> marked with three stars).
>
> “There is a standard way to implement filter drivers,
***either for a
> single driver or for a class of devices***, based on
setting entries
> in the registry. Here, I’m talking about ***filtering all
devices that
> register a particular interface***, for which there’s no other
> mechanism.”
>
> The filter driver Oney is describing is capable of filtering all
> device that register a particular interface, even if they are
> installed in many kinds of setup classes.
> The quote I brought from the book implies it is possible to use pnp
> notifications in order to implement this.
> Yet, I wonder how can it be possible if the notifications are
> generated only after the device starts.
>
> Thanks,
> Shahar
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
> Sent: Sunday, October 10, 2004 7:00 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Device Interface Class Filter
>
> A class filter driver, like kbdclass or mouclass, are
attached to the
> stack before start device. Class filter drivers do not use the
> interface registration as a way of being notified of a
stack, rather,
> they are instantiated on the stack by the pnp manager based on a
> registry key for the class itself.
>
> Look at this key:
>
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class{4D3
> 6E96B-E325
> -11CE-BFC1-08002BE10318}
>
> Under there, you will see an UpperFilters value. This
works just like
> the UpperFilters value in the device’s key except it is
applied to all
> devices of that setup class.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
> Sent: Sunday, October 10, 2004 8:42 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Device Interface Class Filter
>
> Hi,
> In Wlater Oney’s book (Chapter 6, Page 358) when discussing PnP
> notifications it is mentioned that:
>
> “One way to use these notifications is to implement a filter driver
> for an entire class of device interfaces. (There is a
standard way to
> implement filter drivers, either for a single driver or for
a class of
> devices, based on setting entries in the registry. Here,
I’m talking
> about filtering all devices that register a particular
interface, for
> which there’s no other mechanism.)”
>
> However, the DDK documentation mentions that:
>
> “After the IRP_MN_START_DEVICE request completes, the PnP manager
> issues device interface arrival notifications to any kernel-mode or
> user-mode components that requested them.”
>
> In a previous thread we had here we came to the conclusion that a
> driver must not attach a device to a device stack that is already
> started.
>
> How is it possible then to attach as a filter to a device
stack in a
> notification callback like Oney suggested if the
documentation clearly
> states that the notification callback will only be called after the
> IRP_MN_START_DEVICE request completes (which to my best
understanding
> means that it is too late to attach since the device is already
> started) ?
>
> Thanks,
> Shahar
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@windows.microsoft.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
> argument: ‘’
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@hollistech.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>


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

You are currently subscribed to ntdev as: xxxxx@safend.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as:
xxxxx@hollistech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as: xxxxx@safend.com To unsubscribe
send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

The point is that as this is outside of the PnP architecture, either by
accident or by design, there is no generic method to implement a device
interface based filter driver synchronized with PnP. We’ve told you that. We
are not hiding something from you. Each interface may have its own unique
problems and potential solutions.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Tuesday, October 12, 2004 6:38 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

What I am trying to accomplish is much more complicated than
this, GUID_DEVINTERFACE_USB_DEVICE was just a good example
for a device interface which is used by devices from many
setup classes. It sounds pretty weird that Walter Oney would
mention an architecture which is so problematic to implement…

Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, October 11, 2004 11:04 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

No - there’s no generic way to safely attach a filter to a
stack after it’s been started, so there’s way to perform this
specific feat.

Is that really what you’re interested in - filtering
GUID_DEVINTERFACE_USB_DEVICE? What would that accomplish?

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Monday, October 11, 2004 8:08 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

Don’t you believe there is a generic solution for this problem ?
Say I would like to filter all devices that register a
GUID_DEVINTERFACE_USB_DEVICE device interface for example.
How would you suggest to attach to those devices after they start ?

Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, October 11, 2004 3:56 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

> Okay, thanks.
> Can you suggest a way to solve this race condition or maybe
point me
> to some documentation or examples of such mechanisms ?
>

No, you are going to have to figure this one out on your own.
The solution depends on your specific requirements, and there
may very well be no solution for whatever it is you are doing.

> Thanks for your help,
> Shahar
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
> Sent: Monday, October 11, 2004 2:40 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Device Interface Class Filter
>
> You can attach a filter after start device, however such a
filter is
> not guaranteed (by this mechanism alone) to be attached
before other
> components have opened the device in question. I don’t want to put
> words in Walter’s mouth, but I think perhaps he is suggesting a
> possible solution path, without providing the entire
solution itself.
>
> If you can solve the race condition with other components
opening the
> device then you can safely use this approach.
> Note that the ddk forbids opening the device in the notification
> thread context as it claims there is a potential deadlock.
>
> If in fact your device interface is supported by a small number of
> classes, then perhaps the class filter driver is a simpler approach.
>
> =====================
> Mark Roddy
> Windows .NET/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032 www.hollistech.com
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of
Shahar Talmi
> > Sent: Monday, October 11, 2004 4:22 AM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] Device Interface Class Filter
> >
> > Hi Doron,
> > I am familiar with class filter drivers, however I think
> that Walter
> > Oney described a different type of filter driver (note
the parts I
> > marked with three stars).
> >
> > “There is a standard way to implement filter drivers,
> ***either for a
> > single driver or for a class of devices***, based on
> setting entries
> > in the registry. Here, I’m talking about ***filtering all
> devices that
> > register a particular interface***, for which there’s no other
> > mechanism.”
> >
> > The filter driver Oney is describing is capable of filtering all
> > device that register a particular interface, even if they are
> > installed in many kinds of setup classes.
> > The quote I brought from the book implies it is possible
to use pnp
> > notifications in order to implement this.
> > Yet, I wonder how can it be possible if the notifications are
> > generated only after the device starts.
> >
> > Thanks,
> > Shahar
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of
Doron Holan
> > Sent: Sunday, October 10, 2004 7:00 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] Device Interface Class Filter
> >
> > A class filter driver, like kbdclass or mouclass, are
> attached to the
> > stack before start device. Class filter drivers do not use the
> > interface registration as a way of being notified of a
> stack, rather,
> > they are instantiated on the stack by the pnp manager based on a
> > registry key for the class itself.
> >
> > Look at this key:
> >
> > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class{4D3
> > 6E96B-E325
> > -11CE-BFC1-08002BE10318}
> >
> > Under there, you will see an UpperFilters value. This
> works just like
> > the UpperFilters value in the device’s key except it is
> applied to all
> > devices of that setup class.
> >
> > d
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of
Shahar Talmi
> > Sent: Sunday, October 10, 2004 8:42 AM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] Device Interface Class Filter
> >
> > Hi,
> > In Wlater Oney’s book (Chapter 6, Page 358) when discussing PnP
> > notifications it is mentioned that:
> >
> > “One way to use these notifications is to implement a
filter driver
> > for an entire class of device interfaces. (There is a
> standard way to
> > implement filter drivers, either for a single driver or for
> a class of
> > devices, based on setting entries in the registry. Here,
> I’m talking
> > about filtering all devices that register a particular
> interface, for
> > which there’s no other mechanism.)”
> >
> > However, the DDK documentation mentions that:
> >
> > “After the IRP_MN_START_DEVICE request completes, the PnP manager
> > issues device interface arrival notifications to any
kernel-mode or
> > user-mode components that requested them.”
> >
> > In a previous thread we had here we came to the conclusion that a
> > driver must not attach a device to a device stack that is already
> > started.
> >
> > How is it possible then to attach as a filter to a device
> stack in a
> > notification callback like Oney suggested if the
> documentation clearly
> > states that the notification callback will only be called
after the
> > IRP_MN_START_DEVICE request completes (which to my best
> understanding
> > means that it is too late to attach since the device is already
> > started) ?
> >
> > Thanks,
> > Shahar
> >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> > xxxxx@windows.microsoft.com To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: unknown lmsubst tag
> > argument: ‘’
> > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> > xxxxx@hollistech.com To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@safend.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@hollistech.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>


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

You are currently subscribed to ntdev as: xxxxx@safend.com
To unsubscribe
send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as:
xxxxx@windows.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as: xxxxx@hollistech.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

I didn’t think anyone was hiding anything. I’m sorry if I made this
impression.
Thanks for your help.

Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Tuesday, October 12, 2004 1:26 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

The point is that as this is outside of the PnP architecture, either by
accident or by design, there is no generic method to implement a device
interface based filter driver synchronized with PnP. We’ve told you that. We
are not hiding something from you. Each interface may have its own unique
problems and potential solutions.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Tuesday, October 12, 2004 6:38 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

What I am trying to accomplish is much more complicated than this,
GUID_DEVINTERFACE_USB_DEVICE was just a good example for a device
interface which is used by devices from many setup classes. It sounds
pretty weird that Walter Oney would mention an architecture which is
so problematic to implement…

Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, October 11, 2004 11:04 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

No - there’s no generic way to safely attach a filter to a stack after
it’s been started, so there’s way to perform this specific feat.

Is that really what you’re interested in - filtering
GUID_DEVINTERFACE_USB_DEVICE? What would that accomplish?

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Monday, October 11, 2004 8:08 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

Don’t you believe there is a generic solution for this problem ?
Say I would like to filter all devices that register a
GUID_DEVINTERFACE_USB_DEVICE device interface for example.
How would you suggest to attach to those devices after they start ?

Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, October 11, 2004 3:56 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Interface Class Filter

> Okay, thanks.
> Can you suggest a way to solve this race condition or maybe
point me
> to some documentation or examples of such mechanisms ?
>

No, you are going to have to figure this one out on your own.
The solution depends on your specific requirements, and there may very
well be no solution for whatever it is you are doing.

> Thanks for your help,
> Shahar
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
> Sent: Monday, October 11, 2004 2:40 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Device Interface Class Filter
>
> You can attach a filter after start device, however such a
filter is
> not guaranteed (by this mechanism alone) to be attached
before other
> components have opened the device in question. I don’t want to put
> words in Walter’s mouth, but I think perhaps he is suggesting a
> possible solution path, without providing the entire
solution itself.
>
> If you can solve the race condition with other components
opening the
> device then you can safely use this approach.
> Note that the ddk forbids opening the device in the notification
> thread context as it claims there is a potential deadlock.
>
> If in fact your device interface is supported by a small number of
> classes, then perhaps the class filter driver is a simpler approach.
>
> =====================
> Mark Roddy
> Windows .NET/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032 www.hollistech.com
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of
Shahar Talmi
> > Sent: Monday, October 11, 2004 4:22 AM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] Device Interface Class Filter
> >
> > Hi Doron,
> > I am familiar with class filter drivers, however I think
> that Walter
> > Oney described a different type of filter driver (note
the parts I
> > marked with three stars).
> >
> > “There is a standard way to implement filter drivers,
> ***either for a
> > single driver or for a class of devices***, based on
> setting entries
> > in the registry. Here, I’m talking about ***filtering all
> devices that
> > register a particular interface***, for which there’s no other
> > mechanism.”
> >
> > The filter driver Oney is describing is capable of filtering all
> > device that register a particular interface, even if they are
> > installed in many kinds of setup classes.
> > The quote I brought from the book implies it is possible
to use pnp
> > notifications in order to implement this.
> > Yet, I wonder how can it be possible if the notifications are
> > generated only after the device starts.
> >
> > Thanks,
> > Shahar
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of
Doron Holan
> > Sent: Sunday, October 10, 2004 7:00 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] Device Interface Class Filter
> >
> > A class filter driver, like kbdclass or mouclass, are
> attached to the
> > stack before start device. Class filter drivers do not use the
> > interface registration as a way of being notified of a
> stack, rather,
> > they are instantiated on the stack by the pnp manager based on a
> > registry key for the class itself.
> >
> > Look at this key:
> >
> > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class{4D3
> > 6E96B-E325
> > -11CE-BFC1-08002BE10318}
> >
> > Under there, you will see an UpperFilters value. This
> works just like
> > the UpperFilters value in the device’s key except it is
> applied to all
> > devices of that setup class.
> >
> > d
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of
Shahar Talmi
> > Sent: Sunday, October 10, 2004 8:42 AM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] Device Interface Class Filter
> >
> > Hi,
> > In Wlater Oney’s book (Chapter 6, Page 358) when discussing PnP
> > notifications it is mentioned that:
> >
> > “One way to use these notifications is to implement a
filter driver
> > for an entire class of device interfaces. (There is a
> standard way to
> > implement filter drivers, either for a single driver or for
> a class of
> > devices, based on setting entries in the registry. Here,
> I’m talking
> > about filtering all devices that register a particular
> interface, for
> > which there’s no other mechanism.)”
> >
> > However, the DDK documentation mentions that:
> >
> > “After the IRP_MN_START_DEVICE request completes, the PnP manager
> > issues device interface arrival notifications to any
kernel-mode or
> > user-mode components that requested them.”
> >
> > In a previous thread we had here we came to the conclusion that a
> > driver must not attach a device to a device stack that is already
> > started.
> >
> > How is it possible then to attach as a filter to a device
> stack in a
> > notification callback like Oney suggested if the
> documentation clearly
> > states that the notification callback will only be called
after the
> > IRP_MN_START_DEVICE request completes (which to my best
> understanding
> > means that it is too late to attach since the device is already
> > started) ?
> >
> > Thanks,
> > Shahar
> >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> > xxxxx@windows.microsoft.com To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: unknown lmsubst tag
> > argument: ‘’
> > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> > xxxxx@hollistech.com To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@safend.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@hollistech.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>


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

You are currently subscribed to ntdev as: xxxxx@safend.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as:
xxxxx@windows.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as: xxxxx@hollistech.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as: xxxxx@safend.com To unsubscribe
send a blank email to xxxxx@lists.osr.com