A new thread again… I get request from user mode, send it down synchronously. Everything is Ok, I complete the request with STATUS_SUCCESS (this is what returned from WdfRequestGetStatus). The problem is that user mode gets STATUS_PENDING and DeviceIoControl return 0 setting LastError to ERROR_IO_PENDING. Have no idea why it happens. I went through WdfCompleteRequest to IopCompleteRequest and then returned to ntdll!ZwDeviceIoControlFile. ntdll!ZwDeviceIoControlFile returns STATUS_PENDING, while IRP::UserIosb and IRP::IoStatus was set to zero (bot Status and Information). I don’t get how it happened that ntdll!ZwDeviceIoControlFile returns PENDING in this case. Any idea is appreciated.
Kmdf pends all io before presenting it to your driver
d
debt from my phone
From: xxxxx@yahoo.com
Sent: 4/10/2012 9:20 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF, WdfRequestComplete
Hello all.
A new thread again… I get request from user mode, send it down synchronously. Everything is Ok, I complete the request with STATUS_SUCCESS (this is what returned from WdfRequestGetStatus). The problem is that user mode gets STATUS_PENDING and DeviceIoControl return 0 setting LastError to ERROR_IO_PENDING. Have no idea why it happens. I went through WdfCompleteRequest to IopCompleteRequest and then returned to ntdll!ZwDeviceIoControlFile. ntdll!ZwDeviceIoControlFile returns STATUS_PENDING, while IRP::UserIosb and IRP::IoStatus was set to zero (bot Status and Information). I don’t get how it happened that ntdll!ZwDeviceIoControlFile returns PENDING in this case. Any idea is appreciated.
Well, I suspect that the problem is that DeviceIoControl was called with pointer to OVERLAPPED structure. It looks like that IopSynchronousServiceTail doesn’t wait on event in this case returning status that IoCallDriver returns. If my assumption is correct, is there a way to change this behavior without changing user mode application?
If you opened a handle as overlapped you must always provide an OVERLAPPED struct, even if the driver completes the io request synchronously. Not passing the struct for this type of handle leads to undefined behavior. So the fix is either do not open the handle overlapped or pass the struct and handle pending.
d
debt from my phone
From: xxxxx@yahoo.com
Sent: 4/10/2012 9:46 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KMDF, WdfRequestComplete
Well, I suspect that the problem is that DeviceIoControl was called with pointer to OVERLAPPED structure. It looks like that IopSynchronousServiceTail doesn’t wait on event in this case returning status that IoCallDriver returns. If my assumption is correct, is there a way to change this behavior without changing user mode application?
Doron, yeah, I’ve got it after rereading MSDN. Is there any way to force KMDF to return STATUS_SUCCESS from IoCallDriver? Changing user mode application may involve binary code patching, I would like to avoid it in production. I think that the client never got reports about the problem since previous version of driver always returned STATUS_SUCCESS from IoCallDriver when handling this specific IoCTL.
Is there any way to force KMDF to return STATUS_SUCCESS from IoCallDriver? Changing user mode application may involve binary code patching,
Use evt callback for IRP preview, and complete the ioctls there,
avoiding queues.
Otherwise… KMDF is not for you
Complete synchronously as the previous driver did.
Pavel, considering that correct WDM driver requires handling 300+ Pnp/Power states I would like to patch binary instead of writing fully correct WDM driver :).
Could you expand a bit about IRP preview and avoiding queues? Where I can read about it? Is there any example? Which Evt callback you meant? What should I do to avoid queues in KMDF? (I have feeling that avoiding queues is almost the same as writing WDM driver).
He means a wdm preprocess routine or evtioincallercontext callbacks.
d
debt from my phone
From: xxxxx@yahoo.com
Sent: 4/10/2012 10:25 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KMDF, WdfRequestComplete
Pavel, considering that correct WDM driver requires handling 300+ Pnp/Power states I would like to patch binary instead of writing fully correct WDM driver :).
Could you expand a bit about IRP preview and avoiding queues? Where I can read about it? Is there any example? Which Evt callback you meant? What should I do to avoid queues in KMDF? (I have feeling that avoiding queues is almost the same as writing WDM driver).
I set up the callback, it is called before the request is queued. In the callback I check if this is MJ_DEVICE_CONTROL with code I care about then I immediately send the request synchronously to the IO target and complete it after getting result. Else everything goes as usual. Correct me if I wrong please.
Hm. One more question. Using this callback I loose all the benefits of power management queue. Power or PnP state may not allow accepting the request or sending it to the lower driver. So I need to handle it somehow. Is there a way in KMDF to say to the queue that ‘I’m performing an operation, please do not accept any state changes until I finish it’? Not sure that this legit for PnP and power management ideology though… Well, it tends to be complicated.
Yes, you lose that. Think about it though. if you are powered off and the incoming io requires power, you have two options. Either synchronously block the calling thread for an undetermined amount of time or mark the request as pending and power up in a different context that doesn’t block the app. Kmdf takes the latter approach. If you want the former approach of synchronously blocking, register an EvtIoInCallerCallback, set a completion routine, copy the current irp stack location to next, give the request back to the framework and then wait on an event that you set when the completion routine runs. Once the event is set, make sure not to mark the irp as pending and return the right status. That will turn the async power up into sync power up. Note that the chance for deadlock increases here, esp in the case of failures or if there is another driver as a filter above you.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Wednesday, April 11, 2012 2:01 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KMDF, WdfRequestComplete
Hm. One more question. Using this callback I loose all the benefits of power management queue. Power or PnP state may not allow accepting the request or sending it to the lower driver. So I need to handle it somehow. Is there a way in KMDF to say to the queue that ‘I’m performing an operation, please do not accept any state changes until I finish it’? Not sure that this legit for PnP and power management ideology though… Well, it tends to be complicated.
Egidio offline corrected me :). Note that you should do this in EvtDeviceWdmIrpPreprocess, not in EvtIoInCallerCallback. when you register a preprocess callback KMDF will make sure there is an extra stack location for you to have, EvtIoInCallerCallback does not bump the stack count.
