none
Application does not close when I/Os are pending in driver RRS feed

  • Question

  • I have a console application that sends some IOCTL calls to my wdf driver to trigger hardware do some tests.

    Now when the tests are in progress and if the driver has not completed those requests , if the user closes the application , the required reaction is that the application has to get closed and the I/O s have to get cleaned up or cancelled.

    But When the application is closed by pressing Ctlr+C or by clicking on x button , the application doesnot get closed immediately but waits till the I/O is complete .

    Details about driver: There is a device Queue created in which the framework queues IOCTL calls and dispatch requests parallely to the driver through a callback.

    Question 1 : Does the wdf framework give any kind of notification/callback anyfunction when application is being closed ?

    Question 2 : If the driver has to be notified of some situation , what kind of callbacks has to be registered  by the driver?

    Question 3 : when the driver receives requests in the callback ( that is invoked by the framework to dispatch requests), is the request still in queue or pulled out of the queue and given to the driver ? do the driver own the request now ? can the request be marked cancelable now by the driver ?

    Question 4 : I tried to mark the request cancelable in the callback and system crashed (with 

    ERROR_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.)

    what is the reason for this crash ?

    Question 5 : Most of the IOCTLs are not completed immediately but a status pending is sent and completed later when the hardware finishes its work .

    Any idea how to clean up the I/O s and make the application exit gracefully?

    Thanks

    RJ


    Friday, September 13, 2019 12:16 PM

Answers

  • Thank you very much Don.

    Below is what I understand from your explanation.

    I have to create 2 queues - first queue is where the framework queues and dispatches requests from.

    second is where driver queues requests that are not completed , which will be later dequeued by driver and completed .

    whatever requests are in these 2 queues at any point of time when application exits will be cancelled by framework itself.

    There is no need of using wdfrequestmarkcancelable and unmarkcancelable APIs.

    Please correct if I am wrong.


    If all the IOCTL's are the same that is correct.  If you have several types of IOCTL's you may want to have them each in their own queue, so the completion of one type of request is get an item from the queue of that type and complete it.   You do need to handle the case of your hardware gets the data to complete a request and the request has been canceled.


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    • Marked as answer by Jenitta Friday, September 13, 2019 6:38 PM
    Friday, September 13, 2019 4:40 PM

All replies

  • Question 1/2:  No there is no way to know this since the application is still active.

    Question 3:  If the driver actually sees the request it is out of the queue, and owned by the driver.   The common model here is if the request is going to take a long time to complete it is put in a manual queue (and the queue takes care of the cancel).   You can do the cancel code but why would you, it can be a pain to get right, and that is why the queues are there.

    Question 5:  How are you sending the status pending?   The framework does it for you, so is that what you mean or are you doing something else?  This could also answer #4 depending on what you are doing.


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Friday, September 13, 2019 3:10 PM
  • Thank you very much Don.

    Below is what I understand from your explanation.

    I have to create 2 queues - first queue is where the framework queues and dispatches requests from.

    second is where driver queues requests that are not completed , which will be later dequeued by driver and completed .

    whatever requests are in these 2 queues at any point of time when application exits will be cancelled by framework itself.

    There is no need of using wdfrequestmarkcancelable and unmarkcancelable APIs.

    Please correct if I am wrong.

    Friday, September 13, 2019 4:19 PM
  • Thank you very much Don.

    Below is what I understand from your explanation.

    I have to create 2 queues - first queue is where the framework queues and dispatches requests from.

    second is where driver queues requests that are not completed , which will be later dequeued by driver and completed .

    whatever requests are in these 2 queues at any point of time when application exits will be cancelled by framework itself.

    There is no need of using wdfrequestmarkcancelable and unmarkcancelable APIs.

    Please correct if I am wrong.


    If all the IOCTL's are the same that is correct.  If you have several types of IOCTL's you may want to have them each in their own queue, so the completion of one type of request is get an item from the queue of that type and complete it.   You do need to handle the case of your hardware gets the data to complete a request and the request has been canceled.


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    • Marked as answer by Jenitta Friday, September 13, 2019 6:38 PM
    Friday, September 13, 2019 4:40 PM
  • status = WdfRequestForwardToIoQueue(Request, pDevExt->pendingRequestsQueue);

    The above line crashes my system.

    This is called from IOCTL handler . 

    The crash details are the same I got for wdfrequestmarkcancelable.

    -------------------------------------------------------------------------------------

    ERROR_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.)

    kd> kc

     # Call Site
    00 nt!KeBugCheckEx
    01 nt!KiBugCheckDispatch
    02 nt!KiFastFailDispatch
    03 nt!KiRaiseSecurityCheckFailure
    04 Wdf01000!RtlFailFast
    05 Wdf01000!FatalListEntryError
    06 Wdf01000!InsertTailList
    07 Wdf01000!FxIrpQueue::InsertIrpInQueue
    08 Wdf01000!FxIrpQueue::InsertTailRequest
    09 Wdf01000!FxRequest::InsertTailIrpQueue
    0a Wdf01000!FxIoQueue::QueueRequestFromForward
    0b Wdf01000!FxIoQueue::ForwardRequestWorker
    0c Wdf01000!FxIoQueue::ForwardRequest
    0d Wdf01000!imp_WdfRequestForwardToIoQueue
    0e mydriver!WdfRequestForwardToIoQueue
    0f mydriver!myEvtIoDeviceControl
    10 Wdf01000!FxIoQueueIoDeviceControl::Invoke
    11 Wdf01000!FxIoQueue::DispatchRequestToDriver
    12 Wdf01000!FxIoQueue::DispatchEvents
    13 Wdf01000!FxIoQueue::QueueRequest
    14 Wdf01000!FxPkgIo::DispatchStep2
    15 Wdf01000!FxPkgIo::DispatchStep1
    16 Wdf01000!FxPkgIo::Dispatch
    17 Wdf01000!DispatchWorker
    18 Wdf01000!FxDevice::Dispatch
    19 Wdf01000!FxDevice::DispatchWithLock
    1a nt!IofCallDriver
    1b nt!IopSynchronousServiceTail
    1c nt!IopXxxControlFile
    1d nt!NtDeviceIoControlFile
    1e nt!KiSystemServiceCopyEnd
    1f 0x0

    what is the reason for this crash ?

    -----------------------------------------------------------


    Monday, September 16, 2019 8:20 AM