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.


Thanking In Advance,
Mikae.

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.


Thanking In Advance,
Mikae.


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

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?


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

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.

On 11-Apr-2012 08:10, xxxxx@yahoo.com wrote:

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 :frowning:
Complete synchronously as the previous driver did.

– pa

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).

Thank you.

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).

Thank you.


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

Ah, think I’ve got it.

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.


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

>EvtIoInCallerCallback, set a completion routine, copy the current irp stack location to next, give the

request back to the framework

Great hack! I did not know this was allowed.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

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.

d