Bus filter driver in KMDF?

NTDEV
1

So I seem to be reading in messages a few months ago that you can’t use
KMDF for writing a bus filter driver (where I watch QDR and layer a filter
device over some of the bus PDO’s).

Is the issue you can’t generate a correct WDFDEVICE_INIT structure for a
filter device object, other than when the framework automatically generates
it when AddDevice is called?

While post-processing QDR/DeviceRelations, and a new device is detected,
could I just call the WDM DriverObject->AddDevice function, and process the
framework EvtDriverDeviceAdd as a filter device object? The two parameters
to DriverObject-AddDevice, a DriverObject and a parent PDO I certainly know.
I thought the IRP pre/post processing happened outside any KMDF locking, so
don’t offhand see why this would not work.

I suppose I can’t just call IoCreateDevice and hook it up as a child of the
PDO, as KMDF will not know what to do with a device it didn’t created that’s
owned by a KMDF driver?

Jan

2

While most of that would actually fool KMDF in to doing the right thing, there are special bus filter rules in handling pnp state changes that KMDF would not follow if it were in a bus filter role. There is no way to fool KMDF’s pnp WDFDEVICE to do the right thing here.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Tuesday, April 13, 2010 8:32 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Bus filter driver in KMDF?

So I seem to be reading in messages a few months ago that you can’t use KMDF for writing a bus filter driver (where I watch QDR and layer a filter device over some of the bus PDO’s).

Is the issue you can’t generate a correct WDFDEVICE_INIT structure for a filter device object, other than when the framework automatically generates it when AddDevice is called?

While post-processing QDR/DeviceRelations, and a new device is detected, could I just call the WDM DriverObject->AddDevice function, and process the framework EvtDriverDeviceAdd as a filter device object? The two parameters to DriverObject-AddDevice, a DriverObject and a parent PDO I certainly know. I thought the IRP pre/post processing happened outside any KMDF locking, so don’t offhand see why this would not work.

I suppose I can’t just call IoCreateDevice and hook it up as a child of the PDO, as KMDF will not know what to do with a device it didn’t created that’s owned by a KMDF driver?

Jan

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

3

Hi Doron,

Could you be a bit more specific about what PnP state changes will not be
correct. I suppose the filter has to track the QDR present on the bus state,
to know when to remove itself in response to a remove irp.

I basically want to filter a few of the PnP id query strings. I also was
hoping to have the filter live in the same binary as a root enumerated
function driver, as those are easier to get unclassified signatures on.
Since a filter driver on its own really has no .inf, they tend to be tougher
(like impossible perhaps) to feed though whql unclassified testing.

So could I just implement ALL the filter functionality using IRP
preprocessing? This way, the broken KMDF bus filter state machine will not
even see the irps.

Jan

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, April 13, 2010 8:39 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bus filter driver in KMDF?

While most of that would actually fool KMDF in to doing the right thing,
there are special bus filter rules in handling pnp state changes that KMDF
would not follow if it were in a bus filter role. There is no way to fool
KMDF’s pnp WDFDEVICE to do the right thing here.

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Tuesday, April 13, 2010 8:32 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Bus filter driver in KMDF?

So I seem to be reading in messages a few months ago that you can’t use
KMDF for writing a bus filter driver (where I watch QDR and layer a filter
device over some of the bus PDO’s).

Is the issue you can’t generate a correct WDFDEVICE_INIT structure for a
filter device object, other than when the framework automatically generates
it when AddDevice is called?

While post-processing QDR/DeviceRelations, and a new device is detected,
could I just call the WDM DriverObject->AddDevice function, and process the
framework EvtDriverDeviceAdd as a filter device object? The two parameters
to DriverObject-AddDevice, a DriverObject and a parent PDO I certainly know.
I thought the IRP pre/post processing happened outside any KMDF locking, so
don’t offhand see why this would not work.

I suppose I can’t just call IoCreateDevice and hook it up as a child of the
PDO, as KMDF will not know what to do with a device it didn’t created that’s
owned by a KMDF driver?

Jan

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

4

Could you be a bit more specific about what PnP state changes will not be correct. I suppose the filter has to track the QDR present on the bus state, to know when to remove itself in response to a remove irp.
Sorry, no. never tested it, don’t know what works and what doesn’t

So could I just implement ALL the filter functionality using IRP preprocessing? This way, the broken KMDF bus filter state machine will not even see the irps.
You could create a control WDFDEVICE and then preprocess all pnp, power, and wmi irps. Probably also ioctl and internal ioctl so that you can pass through the irps down the stack. You would have to track all state for pnp and power. Never tried this, probably a ton of work.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Tuesday, April 13, 2010 9:14 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bus filter driver in KMDF?

Hi Doron,

Could you be a bit more specific about what PnP state changes will not be correct. I suppose the filter has to track the QDR present on the bus state, to know when to remove itself in response to a remove irp.

I basically want to filter a few of the PnP id query strings. I also was hoping to have the filter live in the same binary as a root enumerated function driver, as those are easier to get unclassified signatures on. Since a filter driver on its own really has no .inf, they tend to be tougher (like impossible perhaps) to feed though whql unclassified testing.

So could I just implement ALL the filter functionality using IRP preprocessing? This way, the broken KMDF bus filter state machine will not even see the irps.

Jan

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, April 13, 2010 8:39 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Bus filter driver in KMDF?

While most of that would actually fool KMDF in to doing the right thing, there are special bus filter rules in handling pnp state changes that KMDF would not follow if it were in a bus filter role. There is no way to fool KMDF’s pnp WDFDEVICE to do the right thing here.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Tuesday, April 13, 2010 8:32 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Bus filter driver in KMDF?

So I seem to be reading in messages a few months ago that you can’t use KMDF for writing a bus filter driver (where I watch QDR and layer a filter device over some of the bus PDO’s).

Is the issue you can’t generate a correct WDFDEVICE_INIT structure for a filter device object, other than when the framework automatically generates it when AddDevice is called?

While post-processing QDR/DeviceRelations, and a new device is detected, could I just call the WDM DriverObject->AddDevice function, and process the framework EvtDriverDeviceAdd as a filter device object? The two parameters to DriverObject-AddDevice, a DriverObject and a parent PDO I certainly know. I thought the IRP pre/post processing happened outside any KMDF locking, so don’t offhand see why this would not work.

I suppose I can’t just call IoCreateDevice and hook it up as a child of the PDO, as KMDF will not know what to do with a device it didn’t created that’s owned by a KMDF driver?

Jan

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

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