KMDF handling of IRP_MN_QUERY_INTERFACE

NTDEV
1

Maybe what I want to do is a horrible offence against nature and PnP - but I
doubt it.

I have a driver stack with two Upper Filters above the FDO, call them Top,
Middle, and FDO.

The FDO exposes an interface via IRP_MN_QUERY_INTERFACE.

The Top consumes this interface.

However, the Middle wants to insert itself into the processing of this
interface - in effect, ‘hook’ it.

With WDM, I would handle this in the completion routine for the IRP on the
way back ‘up’ the stack by mucking with the interface data.

It is not apparent to me how I might handle this same situation (other than
to ‘escape to WDM pre-process mode’) in KMDF.

I suppose I can do it by making the FDO ‘aware’ that it might be going on
and have it detect that the interface is already provided by a ‘higher’
entity and just not muck with it in an
EvtDeviceProcessQueryInterfaceRequest() but this seems backwards to me.
The FDO does not really need to know that the Middle driver is going to
intercede.

Am I missing something? Does KMDF provide a means by which I can inspect
and adjust the interface data *after* the lower drivers have processed the
request?

Thanks,

Dave Cattley

2

>With WDM, I would handle this in the completion routine for the IRP on the >way back ‘up’ the stack by mucking with the interface data.

It is not apparent to me how I might handle this same situation (other than >to escape to WDM pre-process mode’) in KMDF.

You apparently could handle the same situation in KMDF.

In WDM, in your Dispatch IO, you have following sequence of calls

IoCopyCurrentIrpStackLocationToNext
IoSetCompletionRoutine
IoCallDriver

In KMDF in Dispatch routine you should have something like this

WdfRequestFormatRequestUsingCurrentType
WdfRequestSetCompletionRoutine // here you set your completion routine
//where you will handle completed
//request from FDO
WdfRequestSend

Is it what you want?

Igor Sharovar

3

The IRP preprocess callback is before WDF has even seen the IRP, so the WDFREQUEST has not been created. According to the docs on EvtDeviceWdmIrpPreprocess, you can set a completion routine here that will later be invoked. KMDF will allocate an additional stack location for your driver if a preprocess callback is registered so that both your client driver and KMDF will be invoked when the IRP is on the way back up the stack.

Your EvtDeviceWdmIrpPreprocess would look like:

IoSetCompletionRoutine
WdfDeviceWdmDispatchPreprocessedIrp

Is this what you are looking for?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Saturday, October 17, 2009 5:49 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KMDF handling of IRP_MN_QUERY_INTERFACE

With WDM, I would handle this in the completion routine for the IRP on the >way back ‘up’ the stack by mucking with the interface data.
It is not apparent to me how I might handle this same situation (other than >to escape to WDM pre-process mode’) in KMDF.

You apparently could handle the same situation in KMDF.

In WDM, in your Dispatch IO, you have following sequence of calls

IoCopyCurrentIrpStackLocationToNext
IoSetCompletionRoutine
IoCallDriver

In KMDF in Dispatch routine you should have something like this

WdfRequestFormatRequestUsingCurrentType
WdfRequestSetCompletionRoutine // here you set your completion routine
//where you will handle completed
//request from FDO
WdfRequestSend

Is it what you want?

Igor Sharovar

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

Brandon (& Igor),

Thanks for the replies. I am fully aware of the WDM Pre-process mechanism
and recognize that that is a way (and perhaps the only way) to
‘post-process’ the return of IRP_MN_QUERY_INTERFACE. Indeed, I did exactly
this to solve my immediate problem.

My question was more of (and sorry for not making it more clear) “Is this
the ‘correct’ (or only) way to post-process IPR_MN_QUERY_INTERFACE” and in
particular, handle the case where a filter driver wishes to publish a
‘revised’ instance of an interface occluding any lower driver’s version of
that interface.

KMDF seems to have introduced some asymmetry here in the processing model
exposed by EvtDeviceProcessQueryInterfaceRequest() since this structured
callback only occurs *prior* to forwarding the underlying request and no
callback exists (AFAIK) to post process in the completion phase.

Thanks,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brandon Wilson
Sent: Monday, October 19, 2009 11:55 AM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] KMDF handling of IRP_MN_QUERY_INTERFACE

The IRP preprocess callback is before WDF has even seen the IRP, so the
WDFREQUEST has not been created. According to the docs on
EvtDeviceWdmIrpPreprocess, you can set a completion routine here that will
later be invoked. KMDF will allocate an additional stack location for your
driver if a preprocess callback is registered so that both your client
driver and KMDF will be invoked when the IRP is on the way back up the
stack.

Your EvtDeviceWdmIrpPreprocess would look like:

IoSetCompletionRoutine
WdfDeviceWdmDispatchPreprocessedIrp

Is this what you are looking for?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Saturday, October 17, 2009 5:49 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KMDF handling of IRP_MN_QUERY_INTERFACE

With WDM, I would handle this in the completion routine for the IRP on the
way back ‘up’ the stack by mucking with the interface data.
It is not apparent to me how I might handle this same situation (other than
to escape to WDM pre-process mode’) in KMDF.

You apparently could handle the same situation in KMDF.

In WDM, in your Dispatch IO, you have following sequence of calls

IoCopyCurrentIrpStackLocationToNext
IoSetCompletionRoutine
IoCallDriver

In KMDF in Dispatch routine you should have something like this

WdfRequestFormatRequestUsingCurrentType
WdfRequestSetCompletionRoutine // here you set your completion routine
//where you will handle
completed
//request from FDO
WdfRequestSend

Is it what you want?

Igor Sharovar

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

5

Correct, there is no currently built in callback into KMDF to post process a QI on the way up the stack. I will file a bug and we can consider it for the next release.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Monday, October 19, 2009 9:43 AM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] KMDF handling of IRP_MN_QUERY_INTERFACE

Brandon (& Igor),

Thanks for the replies. I am fully aware of the WDM Pre-process mechanism
and recognize that that is a way (and perhaps the only way) to
‘post-process’ the return of IRP_MN_QUERY_INTERFACE. Indeed, I did exactly
this to solve my immediate problem.

My question was more of (and sorry for not making it more clear) “Is this
the ‘correct’ (or only) way to post-process IPR_MN_QUERY_INTERFACE” and in
particular, handle the case where a filter driver wishes to publish a
‘revised’ instance of an interface occluding any lower driver’s version of
that interface.

KMDF seems to have introduced some asymmetry here in the processing model
exposed by EvtDeviceProcessQueryInterfaceRequest() since this structured
callback only occurs *prior* to forwarding the underlying request and no
callback exists (AFAIK) to post process in the completion phase.

Thanks,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brandon Wilson
Sent: Monday, October 19, 2009 11:55 AM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] KMDF handling of IRP_MN_QUERY_INTERFACE

The IRP preprocess callback is before WDF has even seen the IRP, so the
WDFREQUEST has not been created. According to the docs on
EvtDeviceWdmIrpPreprocess, you can set a completion routine here that will
later be invoked. KMDF will allocate an additional stack location for your
driver if a preprocess callback is registered so that both your client
driver and KMDF will be invoked when the IRP is on the way back up the
stack.

Your EvtDeviceWdmIrpPreprocess would look like:

IoSetCompletionRoutine
WdfDeviceWdmDispatchPreprocessedIrp

Is this what you are looking for?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Saturday, October 17, 2009 5:49 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KMDF handling of IRP_MN_QUERY_INTERFACE

With WDM, I would handle this in the completion routine for the IRP on the
way back ‘up’ the stack by mucking with the interface data.
It is not apparent to me how I might handle this same situation (other than
to escape to WDM pre-process mode’) in KMDF.

You apparently could handle the same situation in KMDF.

In WDM, in your Dispatch IO, you have following sequence of calls

IoCopyCurrentIrpStackLocationToNext
IoSetCompletionRoutine
IoCallDriver

In KMDF in Dispatch routine you should have something like this

WdfRequestFormatRequestUsingCurrentType
WdfRequestSetCompletionRoutine // here you set your completion routine
//where you will handle
completed
//request from FDO
WdfRequestSend

Is it what you want?

Igor Sharovar

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

6

Thanks.
-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, October 19, 2009 1:30 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] KMDF handling of IRP_MN_QUERY_INTERFACE

Correct, there is no currently built in callback into KMDF to post process a
QI on the way up the stack. I will file a bug and we can consider it for
the next release.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Monday, October 19, 2009 9:43 AM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] KMDF handling of IRP_MN_QUERY_INTERFACE

Brandon (& Igor),

Thanks for the replies. I am fully aware of the WDM Pre-process mechanism
and recognize that that is a way (and perhaps the only way) to
‘post-process’ the return of IRP_MN_QUERY_INTERFACE. Indeed, I did exactly
this to solve my immediate problem.

My question was more of (and sorry for not making it more clear) “Is this
the ‘correct’ (or only) way to post-process IPR_MN_QUERY_INTERFACE” and in
particular, handle the case where a filter driver wishes to publish a
‘revised’ instance of an interface occluding any lower driver’s version of
that interface.

KMDF seems to have introduced some asymmetry here in the processing model
exposed by EvtDeviceProcessQueryInterfaceRequest() since this structured
callback only occurs *prior* to forwarding the underlying request and no
callback exists (AFAIK) to post process in the completion phase.

Thanks,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brandon Wilson
Sent: Monday, October 19, 2009 11:55 AM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] KMDF handling of IRP_MN_QUERY_INTERFACE

The IRP preprocess callback is before WDF has even seen the IRP, so the
WDFREQUEST has not been created. According to the docs on
EvtDeviceWdmIrpPreprocess, you can set a completion routine here that will
later be invoked. KMDF will allocate an additional stack location for your
driver if a preprocess callback is registered so that both your client
driver and KMDF will be invoked when the IRP is on the way back up the
stack.

Your EvtDeviceWdmIrpPreprocess would look like:

IoSetCompletionRoutine
WdfDeviceWdmDispatchPreprocessedIrp

Is this what you are looking for?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Saturday, October 17, 2009 5:49 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KMDF handling of IRP_MN_QUERY_INTERFACE

With WDM, I would handle this in the completion routine for the IRP on the
way back ‘up’ the stack by mucking with the interface data.
It is not apparent to me how I might handle this same situation (other than
to escape to WDM pre-process mode’) in KMDF.

You apparently could handle the same situation in KMDF.

In WDM, in your Dispatch IO, you have following sequence of calls

IoCopyCurrentIrpStackLocationToNext
IoSetCompletionRoutine
IoCallDriver

In KMDF in Dispatch routine you should have something like this

WdfRequestFormatRequestUsingCurrentType
WdfRequestSetCompletionRoutine // here you set your completion routine
//where you will handle
completed
//request from FDO
WdfRequestSend

Is it what you want?

Igor Sharovar

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

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