Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results


More Info on Driver Writing and Debugging

The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.

Check out The OSR Learning Library at:

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

Synchronization with "slow" devices

Shane_CorbinShane_Corbin Member Posts: 270

I've got a device that has a really slow bus for communicating with a specific piece of hardware. Communication over this bus happens at initialization, on a settings change (initiated through an IOCTL), and when the hardware generates an IRQ. The ISR queues a DPC to handle the IRQ. However, in the rare event that the user was in the middle of a settings change I need to synchronize access to the bus such that the IOCTL completes before the DPC handles the IRQ.

What's the recommended synchronization strategy for such a scenario? The EvtIoDeviceControl callback is configured as WdfIoQueueDispatchSequential.


  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,958

    That's ugly, because of the IRQL inversion. The DPC has a higher IRQL, so the passive ioctl handler would be blocked. Your only two choices are to use KeSynchronizeExecution in the ioctl handler, which will block the DPC, or have your DPC queue a work item (which runs at passive) and use another synchronization method, like a mutex. The latter seems like a friendlier plan.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,485

    I agree with Mr. Roberts, and have a suggestion with a slight twist: Why not have the ISR queue a (IRQL PASSIVE_LEVEL) WorkItemforIsr (as opposed to a DPC) and then use the mutex.

    Simple, clean, clear, and easy.


    Peter Viscarola

  • Shane_CorbinShane_Corbin Member Posts: 270

    Thanks for responding gentlemen. In the meantime I went with the DPC enqueuing a work item. Was happy to get confirmation that route was a top choice. I actually completely forgot WorkItemForIsr existed because I'm in such a habit of reading my IRQ event, disabling it, starting a DPC to finish it and reenable. Thanks for the suggestion Peter.

  • MBond2MBond2 Member Posts: 328

    yes - queue a work item

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Developing Minifilters 24 May 2021 Live, Online
Writing WDF Drivers 14 June 2021 Live, Online
Internals & Software Drivers 27 September 2021 Live, Online
Kernel Debugging 15 November 2021 Live, Online