Retrieve WDFQUEUE or WDFDEVICE in KMDF

NTDEV
1

I am testing a KMDF filter driver from WDK6000. I have a WDM code that is running already as a filter driver. So I started to change some of it to KMDF. What I have faced was that this filter driver is calling the conventional Callback functions in the EvtIoDeviceControl, which is IOCTL in WDM. So I got the IRP with
PIRP Irp = WdfRequestWdmGetIrp(Request);
and was able to call the original WDM code.

So far it is OK. After this, my callback was called and its prototype is

typedef
NTSTATUS
(*PFNKSHANDLER)(
IN PIRP Irp,
IN PKSIDENTIFIER Request,
IN OUT PVOID Data
);

In this callback function I don’t know how to get retrieve the WDFDEVICE or WDFQUEUE. I know there must be a way to do it. Could you tell how to do it?

Thanks.

2

You cannot use KMDF when writing a KS/AVstream/portcls miniport. Both KMDF and ks will want to control the driver’s dispatch table. If you initialize KMDF as a miniport driver, KMDF will back off, but then you can’t use WDFQUEUEs. How are you resolving this problem?

d

3

Thank you Doron,

I didn’t know that we can’t use KMDF for KS/AVstream miniport. Thank you for your advice. Is that mean I can’t use KMDF as a filter driver of portcls minport ?

4

By filter, do you mean a KS filter? or a WDM filter? What it boils down to is … are you linking against a port driver and calling into it? or are you completing PIRP based? If it is a WDM filter driver that is entirely PIRP based, it can be converted to KMDF. If it is using a port driver like KS, then no, KMDF is not appropriate.

d

5

xxxxx@hotmail.com wrote:

I didn’t know that we can’t use KMDF for KS/AVstream miniport. Thank you for your advice. Is that mean I can’t use KMDF as a filter driver of portcls minport ?

No, there are plenty of ways to pass “context” information around. As
long as you can get a WDFREQUEST into the IRP, you can find the WDFQUEUE
and WDFDEVICE from that. That’s one of the nice things about KMDF; once
you have one piece of information, you can usually get whatever else you
need.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

6

Thank you Doron and Tim,

Also Sorry Doron for confusing you that I wasn’t sure how to explain in an easy word with an unknown KMDF stuff. Anyhow Tim got the right spot.

I am using the entirely PIRP based WDM code and tring to change it to support KMDF. In WDM, some of callback functions was called by the OS and in the IRP argument I can hide some of Device Extension information so I can retrieve some particular information using CONTRAIN_RECORD or Some other ways. I was worndering how to do this in KMDF. What is the easy and simple way to do it?

Thanks.

7

Are you looking for WdfWdmGetWdfDeviceHandle? It will give you the corresponding WDFDEVICE for a DEVICE_OBJECT (if there is one).

8

xxxxx@hotmail.com wrote:

Thank you Doron and Tim,

Also Sorry Doron for confusing you that I wasn’t sure how to explain in an easy word with an unknown KMDF stuff. Anyhow Tim got the right spot.

I am using the entirely PIRP based WDM code and tring to change it to support KMDF. In WDM, some of callback functions was called by the OS and in the IRP argument I can hide some of Device Extension information so I can retrieve some particular information using CONTRAIN_RECORD or Some other ways. I was worndering how to do this in KMDF. What is the easy and simple way to do it?

In many cases, there are KMDF equivalents for these functions that will
track it for you. But if not, instead of passing the device extension
information in the IRP argument, use the WDFREQUEST or WDFQUEUE object.
As I said, once you have the low-level object, you can get the
higher-level objects from them.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.