Not getting creates in KMDF

Jason_T · July 28, 2015, 12:40pm

I have a KMDF filter driver that I’m attaching as a lower filter to RFCOMM. I see the IOCTLs that I am interested in but I don’t get any creates. I have tried two different methods of getting creates - 1) using WDF_FILEOBJECT_CONFIG_INIT / WdfDeviceInitSetFileObjectConfig and 2) creating a non-default queue and using WdfDeviceConfigureRequestDispatching to send WdfRequestTypeCreate to it (it has a EvtIoDefault set to catch these).

With either of those two methods in place (and also with both in place) I don’t get a single call to my create handler(s), yet I get hundreds of IOCTLs coming through the default queue. Is this not something that KMDF is designed to be able to filter? Or do I likely just have a bug in my setup code? Basically I’d like to make some decisions based on the context (pid namely) but by the time the IOCTL comes along it’s only in the original context about 25% of the time (even in the caller context callback) and in SYSTEM the rest of the time.

-JT

Doron_Holan · July 28, 2015, 1:10pm

Rfcomm is probably not sending the create down the stack, nor should it since it is meant for rfcomm. You would need an upper filter to see the crate before rfcomm gets it.

Sent from Outlook Mailhttp: for Windows 10

From: xxxxx@gmail.com
Sent: Tuesday, July 28, 2015 9:40 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Not getting creates in KMDF

I have a KMDF filter driver that I’m attaching as a lower filter to RFCOMM. I see the IOCTLs that I am interested in but I don’t get any creates. I have tried two different methods of getting creates - 1) using WDF_FILEOBJECT_CONFIG_INIT / WdfDeviceInitSetFileObjectConfig and 2) creating a non-default queue and using WdfDeviceConfigureRequestDispatching to send WdfRequestTypeCreate to it (it has a EvtIoDefault set to catch these).

With either of those two methods in place (and also with both in place) I don’t get a single call to my create handler(s), yet I get hundreds of IOCTLs coming through the default queue. Is this not something that KMDF is designed to be able to filter? Or do I likely just have a bug in my setup code? Basically I’d like to make some decisions based on the context (pid namely) but by the time the IOCTL comes along it’s only in the original context about 25% of the time (even in the caller context callback) and in SYSTEM the rest of the time.

-JT

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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</http:>

Jason_T · July 28, 2015, 1:46pm

Thanks for the quick response. This makes me feel like I’m missing something much more fundamental here. How can IOCTLs (or reads or writes) venture down the stack to levels where a previous create has not gone? How could any lower level driver process those IOs if it was not exposed to the original open/create to know what the IO applies to in the first place?

-JT

Doron_Holan · July 28, 2015, 1:52pm

Because low drivers are typically not processing io on a per handle basis, the device interface for the lower level driver is a contact between the upper driver (which may have a create, may not) sending io down to the lower stack. The upper driver typically does not pass through unaltered io sent on the handle, rather it will take the io request, format the next stack location to be what the lower driver expects (like taking a write and turning it into an internal ioctl) and sending it down the stack. Think of the bluetooth HID driver, which is a peer of RFCOMM…you can’t open a handle to the hid miniport and yet it sends bluetooth specific io requests to the lower driver, just like rfcomm. You will see that a lot of the IO RFCOMM sends to your lower filter will not have a PFILE_OBJECT in the stack location.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, July 28, 2015 10:45 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Not getting creates in KMDF

Thanks for the quick response. This makes me feel like I’m missing something much more fundamental here. How can IOCTLs (or reads or writes) venture down the stack to levels where a previous create has not gone? How could any lower level driver process those IOs if it was not exposed to the original open/create to know what the IO applies to in the first place?

-JT

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

Jason_T · July 28, 2015, 4:05pm

Thanks for that explanation, that clears up a lot. What I’m seeing is that all the creates are coming in to RFCOMM’s named device object, \Device\BTHMS_RFCOMM, but my upper filter gets attached to RFCOMM’s second unnamed device object and thus I still see nothing. Is there a supported way for me to filter a named control device in KMDF?

Peter_Wieland · July 28, 2015, 4:24pm

Typically the function driver in the stack (in this case RFCOMM) doesn’t send CREATE IRPs down to the lower drivers. If you need the context from the create operation, you would then need to be above RFCOMM.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, July 28, 2015 9:39 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Not getting creates in KMDF

I have a KMDF filter driver that I’m attaching as a lower filter to RFCOMM. I see the IOCTLs that I am interested in but I don’t get any creates. I have tried two different methods of getting creates - 1) using WDF_FILEOBJECT_CONFIG_INIT / WdfDeviceInitSetFileObjectConfig and 2) creating a non-default queue and using WdfDeviceConfigureRequestDispatching to send WdfRequestTypeCreate to it (it has a EvtIoDefault set to catch these).

With either of those two methods in place (and also with both in place) I don’t get a single call to my create handler(s), yet I get hundreds of IOCTLs coming through the default queue. Is this not something that KMDF is designed to be able to filter? Or do I likely just have a bug in my setup code? Basically I’d like to make some decisions based on the context (pid namely) but by the time the IOCTL comes along it’s only in the original context about 25% of the time (even in the caller context callback) and in SYSTEM the rest of the time.

-JT

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

Doron_Holan · July 28, 2015, 4:26pm

Not in a controlled fashion where you know that zero creates have happened yet. You can manually open the device, attach to it and then close the handle to see subsequent io sent to the device

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, July 28, 2015 1:04 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Not getting creates in KMDF

Thanks for that explanation, that clears up a lot. What I’m seeing is that all the creates are coming in to RFCOMM’s named device object, \Device\BTHMS_RFCOMM, but my upper filter gets attached to RFCOMM’s second unnamed device object and thus I still see nothing. Is there a supported way for me to filter a named control device in KMDF?

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

Jason_T · July 28, 2015, 5:03pm

Thanks Doron. Just to be clear that would have to be done via WDM code, right? There’s no equivalent of IoAttachDevice supported in KMDF is there?

Doron_Holan · July 28, 2015, 5:09pm

You could call IoAttachDevice with a KMDF control WDFDEVICE, you would need to manage the detach on your own as well as io forwarding (Filter behavior), since the control WDFDEVICE has no idea it is attached to anything, by registering an io handler for each major type. You would create your own “Default” io target as well using the WDM device object you attached to.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, July 28, 2015 2:01 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Not getting creates in KMDF

Thanks Doron. Just to be clear that would have to be done via WDM code, right? There’s no equivalent of IoAttachDevice supported in KMDF is there?

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

Jason_T · July 28, 2015, 10:29pm

I have tried the following (error checking removed for clarity)

// BTW, what SDDL should be used here? Since I am not naming my device and don’t want it to be accessible directly, I first tried passing NULL but that bugchecks. I don’t want to limit or loosen whatever security RFCOMM is requesting…
deviceInit = WdfControlDeviceInitAllocate(MyDriver, &SDDL_DEVOBJ_KERNEL_ONLY);

ntStatus = WdfDeviceCreate(&deviceInit, WDF_NO_OBJECT_ATTRIBUTES, &MyControlDevice);

WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&ioQueueConfig, WdfIoQueueDispatchParallel);

// the docs indicate this will be set to WdfDefault which will only be WdfFalse in the case of a filter, which I am, however they also say I can’t call WdfFdoInitSetFilter on a control device so I figured I should manually override this. Correct?
ioQueueConfig.PowerManaged = WdfFalse;
ioQueueConfig.EvtIoDefault = MyFltrControlIoDefault;

ntStatus = WdfIoQueueCreate(MyControlDevice,
&ioQueueConfig,
WDF_NO_OBJECT_ATTRIBUTES,
&queue);

RtlInitUnicodeString(&uniTargetName, L"\Device\BTHMS_RFCOMM");

ntStatus = WdfIoTargetCreate(MyControlDevice, WDF_NO_OBJECT_ATTRIBUTES, &MyControlIoTarget);

WDF_IO_TARGET_OPEN_PARAMS_INIT_OPEN_BY_NAME(&openParams, &uniTargetName, STANDARD_RIGHTS_ALL);

ntStatus = WdfIoTargetOpen(MyControlIoTarget, &openParams);

WdfControlFinishInitializing(MyControlDevice);

MyCtrlDevObj = WdfDeviceWdmGetDeviceObject(MyControlDevice);

ntStatus = IoAttachDevice(MyCtrlDevObj, &uniTargetName, &BTBTHMS_RFCOMMDevObj);

I kick off a timer routine and once the RFCOMM device is created this all succeeds… the problem is, the WDF control device seems to be going away shortly thereafter. A second after all of these steps succeed the WDF control device is no longer valid, nor is the WDM device object that was associated with it. But the RFCOMM device is still valid and still showing our now invalid device object as being attached so the system crashes as soon as RFCOMM gets its first request. Am I missing some step to “reference” the control device and keep it from being disposed?

Prior to the call to IoAttachDevice:

4: kd> !wdfkd.wdfdevice 0x0000057f`ef1c02a8
Treating handle as a KMDF handle!

Dumping WDFDEVICE 0x0000057fef1c02a8

WDM PDEVICE_OBJECTs: self fffffa8010e3fb40

Control WDFDEVICE

4: kd> !devobj 0xfffffa80`10e3fb40
Device object (fffffa8010e3fb40) is for:
000000e4 \Driver\MyFltr DriverObject fffffa8010473060
Current Irp 00000000 RefCount 0 Type 00000022 Flags 00000044
Dacl fffff9a100ceac51 DevExt fffffa8010e40000 DevObjExt fffffa8010e3fcb8
ExtensionFlags (0000000000)
Characteristics (0x00000180) FILE_AUTOGENERATED_DEVICE_NAME, FILE_DEVICE_SECURE_OPEN
Device queue is not busy.

IoAttachDevice returns success and the returned PDEVICE_OBJECT does point to RFCOMM as expected. But then I hit F5 and break in about 1 second later and now I get this:

4: kd> !wdfkd.wdfdevice 0x0000057fef1c02a8 Treating handle as a KMDF handle! Not a valid WDFDEVICE handle 4: kd\> !devobj 0xfffffa8010e3fb40
fffffa8010e3fb40: is not a device object

Doron_Holan · July 28, 2015, 11:58pm

Are you doing this in a pnp driver? Are you creating a pnp WDFDEVICE in addition to the control WDFDEVICE below?

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, July 28, 2015 7:28 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Not getting creates in KMDF