Ok, I understand. I have already made the design changes to deal with the
Create more appropriately. At the point in the driver implementation below
it was not requesting the framework to create WDFFILEOBJECTs.
And to make me look like even a bigger idiot, I turned the knob on the
way-back-machine (source control), rebuilt the driver that I was convinced
was doing what I said (NULL FileObject), re-ran my test under controlled
conditions, and see that indeed FileObject != NULL, the stack pointer is
exactly as it should be (skipped), and nothing is wrong.
I hate computers.
Last night I did that same experiment three times to be sure I was seeing
what I was seeing before posting originally. I have no idea why now the
stack location seemed goofed. I wonder if I was looking after the IRP had
been completed (and the stack location partially zeroed).
Sigh. Sorry for bothering you (all).
I realize that Don’s issue is unrelated and more likely to do with using
WdfIoTargetFormatRequestXxxx() with the ‘default’ I/O target which does not
have a FileObject associated with it.
My issue is that evidently I should be knitting mittens with five thumbs
each and not writing drivers.
Thanks for your help.
-Dave
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, May 18, 2009 1:59 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] KMDF: Why does FileObject end up NULL when
forwarding IRP_MJ_CREATE through a filter driver?
Send and forget is the equivalent of
IoSkipCurrentIrpStackLocation+IoCallDriver. In the send and forget case we
do not touch any stack locations at all. Can you run !irp on the irp right
before the send and forget in your driver and then when the lower driver
gets the irp? They should be the same, down to the current irp stack
location
Note that send and forget for a create is a bit problematic. If the lower
driver completes the request with failure, your upper filter will never see
it and hang on to the WDFFILEOBJECT forever (at least until stack teardown).
I will get the docs updated if they are not clear here. Please use the send
feedback link in msdn to do the same to make sure it gets tracked.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Monday, May 18, 2009 10:45 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] KMDF: Why does FileObject end up NULL when
forwarding IRP_MJ_CREATE through a filter driver?
Doron,
What was going wrong was that when processed the Create request dispatched
to the queue with
…
WDF_REQUEST_SEND_OPTIONS options;
BOOLEAN success;
WDF_REQUEST_SEND_OPTIONS_INIT(&options,
WDF_REQUEST_SEND_OPTION_SEND_AND_FORGET);
success = WdfRequestSend(Request, WdfDeviceGetioTarget(device),
&options);
if (!success)
{
NTSTATUS requestStatus = WdfRequestGetStatus(Request);
WdfRequestComplete(Request, requestStatus);
}
when the request got to the next lower driver, the current stack location
FileObject field was NULL.
Is it possible then that my error was more simple? I did not call
WdfRequestFormatRequestUsingCurrentType() as I thought that with Send&Forget
that was optional.
If that is *not* optional then perhaps the entire IO_STACK_LOCATION was sent
as ‘zeros’. IRP_MJ_CREATE == 0, right?
What I interpreted as KMDF zeroing the FileObject might really have been
KMDF expecting me to have called WdfRequestFormatRequestUsingCurrentType().
A driver that sets the WDF_REQUEST_SEND_OPTION_SEND_AND_FORGET flag
typically does not format the I/O request before it calls WdfRequestSend to
send the request to an I/O target. In fact, a driver that sets this flag
must not call any of the WdfIoTargetFormatRequestForXxx methods before it
calls WdfRequestSend. The driver can use only the
WdfRequestFormatRequestUsingCurrentType or
WdfRequestWdmFormatUsingStackLocation method to format the request.
So, is this perhaps not quite true?
Thanks,
-dave
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, May 18, 2009 1:15 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] KMDF: Why does FileObject end up NULL when
forwarding IRP_MJ_CREATE through a filter driver?
I am a little lost as to what was going wrong for you. Formatting a
read/write/IOCTL follows the following logic for the next stack location
- if the target is not an in stack (default, usb device or pipe
essentially) target, use the target’s file object
- use the file object in the current stack location
FormatUsingCurrentType just does an IoCopyCurrentIrpStackLocationToNext and
that will copy the file object to the next stack location. The fact that
the create was async does not matter. If you created a top level queue to
handle the dispatching of requests, we alloc a WDFREQUEST and put it into
the queue. What you do with it once presented is the same as if you process
it via EvtDeviceFileCreate (e.g. you must eventually complete it 
). The
only thing you can really do with a create is fail it outright or
FormatUsingCurrentType() which we know does set the fileobject correctly.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Monday, May 18, 2009 8:39 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] KMDF: Why does FileObject end up NULL when
forwarding IRP_MJ_CREATE through a filter driver?
My faith is restored.
Using EvtDeviceFileCreate in the filter and forwarding the Create Request
synchronously to the default I/O target works just peachy.
Incidentally, I need to correct a misstatement I made earlier.
Calling WdfRequestFormatRequestUsingCurrentType() does indeed copy the
FileObject to the next stack location. The debugger shows me so.
Using the Create Request so formatted with WdfRequestSend(Request,
WdfDeviceGetIoTarget(Device), &options) where options have been setup with
WDF_REQUEST_SEND_OPTION_SYNCHRONOUS does correctly result in the I/O Stack
Location presented to the lower driver having the FileObject non-null and
correct.
I am still quite curious, however, as to why a Create Request when
dispatched to a queue and then forwarded asynchronously (albeit this is a
bad thing to do) results in a NULL FileObject in the next I/O Stack
Location. My concern is simply “does this happen because it was a Create
or does it happen for other requests too?”
Thanks,
-Dave
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
