IoGetDeviceObjectPointer and WdfRequestGetFileObject

I am currently converting my WDM+DriverWorks drivers to KMDF.

I have two drivers. The master driver(DeviceA) uses WDM+DriverWorks.
The slave (DeviceB) has been converted to KMDF.

DeviceA uses KLowerDevice (which embedds an IoGetDeviceObjectPointer
call) to establish the connection between DeviceA and DeviceB.
IoGetDeviceObjectPointer succeeds. DeviceA then builds a
IRP_MJ_DEVICE_CONTROL itp to communicate with DeviceB. DeviceB receives
the control code but WdfRequestGetFileObject returns NULL.

If I use an user application to send the same control code to DeviceB,
WdfRequestGetFileObject returns a valid WDFILEOBJECT.

According to the KMDF documentation, WdfRequestGetFileObject will fail
if

a) Your driver has not called WdfDeviceInitSetFileObjectConfig and
specified a WDF_FILEOBJECT_CLASS value that causes the framework to
create file objects.

>> I do call WdfDeviceInitSetFileObjectConfig in my EvtDriverDeviceAdd
callback and the call does not fail when the user application runs.

b) Another driver sent a read, write, or I/O control request to your
driver without first sending a request type of WdfRequestTypeCreate.

>> I have a trace statement in EvtDeviceFileCreate and the event is firing so DeviceA is sending the WdfRequestTypeCreate.

Thanks for the help!
Chris Grove

Doron
Wed May 17 21:35:26 CDT 2006

I am betting that your KLower class is not manually setting the PFILE_OBJECT
value in nextStackLocation->FileObject before sending the irp to device B.
How is KLowerDevice formatting the irp? with IoBuildDeviceIoControlRequest?
If device A is going to be KMDF driver, you would create and open a
WDFIOTARGET and it would do the right thing.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Chris Grove" <chris_grove@agilent.com> wrote in message
news:1147898125.561560.46830@y43g2000cwc.googlegroups.com...
>I am currently converting my WDM+DriverWorks drivers to KMDF.
>
> I have two drivers. The master driver(DeviceA) uses WDM+DriverWorks.
> The slave (DeviceB) has been converted to KMDF.
>
> DeviceA uses KLowerDevice (which embedds an IoGetDeviceObjectPointer
> call) to establish the connection between DeviceA and DeviceB.
> IoGetDeviceObjectPointer succeeds. DeviceA then builds a
> IRP_MJ_DEVICE_CONTROL itp to communicate with DeviceB. DeviceB receives
> the control code but WdfRequestGetFileObject returns NULL.
>
> If I use an user application to send the same control code to DeviceB,
> WdfRequestGetFileObject returns a valid WDFILEOBJECT.
>
> According to the KMDF documentation, WdfRequestGetFileObject will fail
> if
>
> a) Your driver has not called WdfDeviceInitSetFileObjectConfig and
> specified a WDF_FILEOBJECT_CLASS value that causes the framework to
> create file objects.
>
> >> I do call WdfDeviceInitSetFileObjectConfig in my EvtDriverDeviceAdd
> callback and the call does not fail when the user application runs.
>
> b) Another driver sent a read, write, or I/O control request to your
> driver without first sending a request type of WdfRequestTypeCreate.
>
>>> I have a trace statement in EvtDeviceFileCreate and the event is firing
>>> so DeviceA is sending the WdfRequestTypeCreate.
>
> Thanks for the help!
> Chris Grove
>

Chris
Thu May 18 08:57:20 CDT 2006

Thanks Doron!

Neither the KLowerDevice class in its wrapper to IoCallDriver nor the
class that wraps the irp object set the FileObject member in the
nextStackLocation. Fortunately, the DriverWorks classes expose the WDM
objects and I was able to set the member myself.

The DriverWorks sample code (which I had copied) for sending a request
to another device also does not include copying the FileObject. The
sample code calls the KIrp::Allocate method which wraps an
IoAllocateIrp call. It then individually sets the members (major and
minor functions, ioctl, buffer, and buffer sizes) of the
nextStackLocation.

If Compuware hadn't discontinued SoftICE and DriverWorks, I'd report
it as a bug/documentation error :( ...

Thanks Again,
Chris Grove