none
Driver Verifier -- Force Pending I/O Requests RRS feed

  • Question

  • The write up of this test (https://msdn.microsoft.com/en-us/windows/hardware/drivers/devtest/force-pending-i-o-requests) is confusing to me.  As I read it, it implies that any driver which gets a STATUS_PENDING response from IoCallDriver() has to be rewritten to use IoBuildSynchronousFsdRequest.   On the surface this seems obviously incorrect.  For example, might not we have written the call to use …BuildAsyncRequest… and then received a STATUS_PENDING.  Further, there are many other valid ways the driver can deal with the follow up.  Completion routines for example. 

    The long list of problems with this writeup begins with that it forces use of FSD calls in non FSD environments,  even more odd is the call for the rewriting of async requests into sync requests.  (I assume this is a write up problem.) 

    For example, I assume no one is going to defend the following quote.

     

    <quote>

    How should drivers handle STATUS_PENDING?

    The higher-level driver that calls IoCallDriver must handle a STATUS_PENDING return value as follows:

    • Before calling IoCallDriver, the driver must call IoBuildSynchronousFsdRequest to arrange for synchronous processing of the IRP.
    • If IoCallDriver returns STATUS_PENDING, the driver must wait for the completion of the IRP by calling KeWaitForSingleObject on the specified event.
    • The driver must anticipate that the IRP might be freed before the I/O Manager signals the event.
    • After calling IoCallDriver, the caller cannot reference the IRP.

    </quote>

    The point of my question is that I am questioning the correctness of this test.  This test is killing our WHQL test so we have to deal with it.  Frankly, the write up of some aspects of the test, does not leave me confident about the test.

    Possibly we are running the test incorrectly?  Possibly this should only be run on top level FSDs which are issued synchronously?  If that is the case, the write up makes sense. However,  I did not see any documentation on this sort of test restriction.  

    OR NOT

    If some MS official can verify the correctness of this test and the write up, I can take another look. 

    Regards,


    Victor Webber

    Monday, April 3, 2017 11:56 PM