IoGetDeviceObjectPointer and WdfRequestGetFileObject
in [Device Drivers]
|
Prev: IoGetDmaAdapter for a root-enumerated device in 64-bit Windows
Next: IOCTL_USB_GET_NODE_CONNECTION_INFORMATION not working on win2k+OHC
From: Chris Grove on 17 May 2006 16:35 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
From: Doron Holan [MS] on 17 May 2006 22:35 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(a)agilent.com> wrote in message news:1147898125.561560.46830(a)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 >
From: Chris Grove on 18 May 2006 09:57
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 |