Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
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: https://www.osr.com/osr-learning-library/
|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!|
|Internals & Software Drivers||19-23 June 2023||Live, Online|
|Writing WDF Drivers||10-14 July 2023||Live, Online|
|Kernel Debugging||16-20 October 2023||Live, Online|
|Developing Minifilters||13-17 November 2023||Live, Online|
But I am wondering if ExInterlockedPushEntryList is allowed at any IRQL then why StorPortInterlockedPushEntrySList is not?
Btw any hints for making the queuing work at DIRQL are welcome :-) Thanks in advance.
You don't want to compete for the acquisition of another spin lock while you are holding the interrupt lock. So you have to go with the interrupt lock.
Thats the classic way to do things.
You also need to use verifier at all times when developing your driver, it will catch potential page faults even if they don't actually fault.
I understand that it is documented to be used at <= DISPATCH_LEVEL, but I guess there are no 'side effects' of using it at HIGH_IRQL because you are basically running it in a single threaded mode.
I understand that it is documented to be used at <= DISPATCH_LEVEL, but I guess there would be no 'side effects' when used at HIGH_IRQL because you are basically running in a single threaded mode.
I understand that it is documented to be used at <= DISPATCH_LEVEL, but I guess
there would be no 'side effects' when used at HIGH_IRQL
This is very poor engineering.
Along with each API, you get a contract. That contract states the conditions under which the developer of the API will support using the API.
Your part of the contract is to only use the API under the circumstances that the contract states. That does NOT not include guessing at how the API is implemented and trying to therefore surmise when it might be OK to call the API outside of the circumstances stated in the documented contract.
Especially for something like maintaining an SLIST. Why would you even, for one minute, consider doing this? You want an SLIST that works at HIGH_LEVEL, write the code yourself. It's not that hard, and will probably take you less time that it took for you to consider using the function outside of the way its documented and posting your question here.
I'm sorry if that seems like a harsh assessment... but that's the essence of what I'd say to an engineer on my team here at OSR if they came to me with this same question.
Basically I am using interlocked functions at many places in the IO path in normal mode and was being lazy for having to check for dump mode at each of those places and use an alternative.
But I get your point.
Probably it is better to change all StorPortInterlockedxxx with MyStorPortInterlockedxxx and then check for dump mode inside MyStorPortInterlockedxxx.