WdfDeviceCreate STATUS_INVALID_DEVICE_REQUEST when SynchronizationScope = WdfSynchronizationScopeDev

Hello again OSR Community:

  • In my KMDF EvtDeviceAdd routine, my one and only WdfDeviceCreate fails with STATUS_INVALID_DEVICE_REQUEST when I set SynchronizationScope = WdfSynchronizationScopeDev. Leaving it default, which is InheritFromParent due to the WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE macro, the creation succeeds.

  • In the article “WDF File Object Callbacks and Properties Demystified”, https://osr.com/nt-insider/2014-issue1/wdf-file-object-callbacks-properties-demystified/, it states"…Lastly, WdfSynchronizationScopeDevice is a valid choice only if the parent WDF Device Object has a PASSIVE_LEVEL execution constraint, otherwise the Framework fails the attempt to create the device…"

  • In the article, “Understanding Sync Scope in WDF Drivers”, https://osr.com/nt-insider/2014-issue3/understanding-sync-scope-wdf-drivers/, which came out later that year, there is no mention of any such restriction.

  • The MS Documentation states that “The parent of each framework device object is the driver’s framework driver object.”. Which doesn’t really tell me much as I don’t know the synch scope setting, and if it’s not set to Device, then what?

  • I realize I am missing some fundamental understanding, and the articles + documentation, although quite good, haven’t been enough for me; I know, I am a bit thick headed, it takes me a while… :smile:

Thanks for any help.
Juan

Have you dumped the in flight recorder with !wdfkd.wdflogdump? There should be a message about the reason for the error. You can also just step into the source code:

https://github.com/Microsoft/Windows-Driver-Frameworks/wiki/Debugging-with-WDF-Source

Did you actually set ExecutionLevel to WdfExecutionLevelPassive, as the documentation you quoted suggests?

Please note that WDF makes it very easy to over-synchronize yourself and cause deadlocks. Is there some legitimate reason you want device sync scope, or did you just choose it because it seems easier? As a rule, it isn’t. Notice the following quotes from the page https://docs.microsoft.com/en-us/windows-hardware/drivers/wdf/using-automatic-synchronization:

In general, we do not recommend using device-level synchronization.

The default synchronization scope for driver objects is WdfSynchronizationScopeNone.
The default synchronization scope for device and queue objects is WdfSynchronizationScopeInheritFromParent.

And last, it certainly not least, and to emphasize what Mr. Roberts said: You almost certain don’t really want SyncScopeDevice. Almost always a bad idea for a real driver.

Peter

Good Afternoon Scott, Mr. Roberts and Peter:

Regarding the execution level; Since the article was about FileObjects and the same restrictions was not in the second article, I was slightly leaning on that restriction applying to just the FileObject.

Reason for SyncScopDevice: I wasn’t sure if the SyncScopeQueue on the request queue I am using would be enough. I wanted to test using the Device level sync to see how the drive would run vs only using the queue sync.

A few points:

  • HW sends data and then enqueues (on the HW) metadata. HW Interrupts tell the driver that the HW FIFO has metadata.
  • The driver will disable interrupts, and process all the metadata in the HW FIFO, until empty. Then re-enable interrupts.
  • SW File Reads can come at anytime, but request processing is serialized as the requests are enqueued in the WDFQUEUE, which is Sync’d.

I did some testing and queue sync + interrupt enable/disable seems to be enough - but I suppose you all already suspected that.

Thank you all for your patience and all the helpful information you have given freely. I really need to find a way to make it out to a seminar and learn the fundamentals; I can see a good foundation is important here.

Juan