Comments

• Doron_Holan Member - All Emails Posts: 10,553

  November 2020

  You need to open the handle as OVERLAPPED. A handle without OVERLAPPED will serialize IO requests at IO manager dispatching layer before it is sent to the driver.

  d

  1 · Share on Facebook
• Jason_Stephenson Member Posts: 89

  November 2020

  I see. I've done some further tinkering and I'm struggling to understand something else.
  

  //On worker thread
  for(;;) 
  {
  h2 = CreateFileW(L"XXX",
              GENERIC_READ | GENERIC_WRITE,
              FILE_SHARE_WRITE | FILE_SHARE_READ,
              nullptr,
              OPEN_EXISTING,
              FILE_ATTRIBUTE_NORMAL,
              nullptr);
      DeviceIoControl(h2, IOCTL_INVERTED_CALL, ...); 
      PrintData(); 
  }
  
  //On Main
  h = CreateFileW(L"XXX",
              GENERIC_READ | GENERIC_WRITE,
              FILE_SHARE_WRITE | FILE_SHARE_READ,
              nullptr,
              OPEN_EXISTING,
              FILE_ATTRIBUTE_NORMAL,
              nullptr);
  
  switch(userInput)
  {
      CASE 1:
          DeviceIoControl(h, IOCTL_OTHER, ...); //No blocking occurs here, even when IOCTL_INVERTED_CALL is pending
  }
  

  Why does blocking NOT occur / Why does my IOCTL_OTHER handler get called in the example above?
  
  

  Since my handler for IOCTL_INVERTED_CALL will not call WdfRequestCompleteWithInformation, the queue is WdfIoQueueDispatchSequential and the docs state:

  The framework does not deliver the next request until a driver has called WdfRequestComplete.

  I would have assumed IOCTL_OTHER should block?
  
  

  This is obvliously related to the use of two different usermode file handles, but I don't understand how that would affect my drives IO queue?
  

  Thanks,
  Jason

  0 · Share on Facebook
• Jason_Stephenson Member Posts: 89

  November 2020 edited November 2020

  It's just dawned on me, perhaps this is because the WDFREQUEST has been forwarded to my pending request queue? (WdfRequestForwardToIoQueue?)

  If the source queue's dispatching method is sequential or parallel, the framework can deliver another request to one of the source queue's request handlers.

  0 · Share on Facebook
• Peter_Viscarola_(OSR) Administrator Posts: 8,240

  November 2020 edited November 2020

  Nope. Both should block until the IOCTL is complete... and I/O done on different handles is considered separately.

  In general, blocking in your app has no relationship to Queuing in your driver.

  Later ETA: While how your driver receives and processes I/O Requests can affect when an asynchronous I/O operation returns to your app, this isn’t related to the Queue type or dispatch method.

  You need to check the return status of the calls to DeviceIoControl... if the second one is returning without waiting, I suspect that’s because it’s failing.

  Peter

  Peter Viscarola
  OSR
  @OSRDrivers

  0 · Share on Facebook
• Jason_Stephenson Member Posts: 89

  November 2020

  I/O done on different handles is considered separately.
  In general, blocking in your app has no relationship to Queuing in your driver.
  A handle without OVERLAPPED will serialize IO requests at IO manager dispatching layer before it is sent to the driver

  Thanks, the quotes above have helped tremendously.
  
  

  I was working under the misconception that if CreateFile was called to create a synchronous handle I could use this handle for IOCTL_INVERTED_CALL on ThreadA and IOCTL_OTHER on ThreadB if my DriverIO queue was WdfIoQueueDispatchParallel.
  
  

  I now understand that in order for this to be possible I need to either use OverlappedIO on the single handle, or open multiple handles.
  
  

  Thanks,
  Jason

  0 · Share on Facebook
• Peter_Viscarola_(OSR) Administrator Posts: 8,240

  November 2020

  this to be possible I need to either use OverlappedIO on the single handle, or open multiple handles.

  Yes! Exactly correct.

  Peter

  Peter Viscarola
  OSR
  @OSRDrivers

  0 · Share on Facebook