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/
I ran SDV for my driver for the very first time and chose "All" option in "Rule sets" under "Rules" tab. I got a number of warnings for methods like WdfDeviceInitSetIoType and WdfDeviceInitSetExclusive (and a few others). Now, I can see that these methods require IRQL to satisfy <= DISPATCH_LEVEL, but, isn't that implied by the place from which these methods are called? Should I just ignore these warnings? If not, how do I fix this? I couldn't find answers to this in MS documentation or other posts here.
I feel it would be a waste to check IRQL just to satisfy SDV, if the APIs are called in the context that will never be at such IRQL level (I'm just a beginner, but can IRQL be bigger than DISPATCH_LEVEL when adding a device?).
|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!|
|Kernel Debugging||30 January 2023||Live, Online|
|Developing Minifilters||20 March 2023||Live, Online|
|Internals & Software Drivers||17 April 2023||Live, Online|
|Writing WDF Drivers||22 May 2023||Live, Online|
No. You must not simply ignore anything that SDV says.
You are correct, however, that EvtDriverDeviceAdd is always called at IrqlPassiveLevel and so calling WdfDeviceInitSetExclusive from this function should be fine. It's where we ALL call this function, after all.
So... the question becomes: What are you doing that might raise the IRQL at which you're running -- Are you holding a lock? Have you tried checking the actual IRQL, to see what it is?
In terms of tool use issues: Are you using proper role-type declarations (as in "EVT_WDF_DRIVER_DEVICE_ADD EvtWdfDriverDeviceAdd;" to declare your EvtDriverDevice add) so that SDV knows which functions in your driver have particular roles?
Thanks Peter. The function where these flagged actions are is directly called from a method flagged as EVT_WDF_DRIVER_DEVICE_ADD. It's just the way the code is structured when the driver code is initially generated from Visual Studio template. No locks, nothing, just straightforward setting up attributes before calling WdfDeviceCreate.
If SDV took into account that this function was called only from EVT_WDF_DRIVER_DEVICE_ADD event callback, then the passive level execution would automatically be derived, but it doesn't seem to be happening. It looks like that static analysis is done only on per function basis. I don't know if it's possible to expand it to cover the complete driver code.
PS. I've tried adding the following to the function (that is being called from EvtDriverDeviceAdd) declaration:
I read in detail MS documentation on using SDV, but I didn't get any new ideas. I thought that using _IRQL_requires_max_(PASSIVE_LEVEL) would fix things, by stating this function can only be called at PASSIVE_LEVEL IRQL, which would imply that any API calls made from this function will be done at the right IRQL - but SDV is not picking that up.
I guess I just have to accept the tool is not perfect. Maybe those SAL annotations are ignored by SDV and used by some other tool?
That's very odd... Hmmm... I don't know what to say at this point.
Given what you're saying is correct, I don't see any reason at all why this wouldn't work. OTOH, I've had SUCH a lot of trouble with SDV for the past several years, I'm honestly getting increasingly frustrated with it. It's a tool with a long and decidedly mixed history: For the first several years of its existence it sucked in the worst possible way. Then it got lots of love and attention, and it became a really terrific, super useful, tool. Then, with each subsequent release of VS/WDK, it just gets stranger, more annoying, more quirky, and definitely more fucked-up.
Maybe somebody reading this thread will be able to build a minimum repro case for this and report it? I'd love to do that, but I'm sorry to say I'm a bit "over subscribed" at work right now.