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 have asked opinions on this question on stack overflow, but unfortunately that "community" has become... poisoned. I'll leave it a that.
With that being said, I decided to come here, where the actual kernel experts are.
This question aims to get a bit of clarity and more information about Windows Kernel call-backs.
If you go the official documentation you will find the following:
From my own opinion, this defeats the purpose of having a call-back in the first place. If you can't validate a thread, image, process or even perform IPC... what's the point?
Based on MSDN you shouldn't even contact your service, or log information via IPC or registry, etc. So again, what's the point of having one?
Consider having an AV like product and you want to validate images on LOAD_IMAGE_NOTIFY_ROUTINE/OB_PRE_OPERATION_CALLBACK, you are not supposed to. So now what?
I've already seen countless drivers doing a lot of validations and operations in these call-backs, even though they do not follow "best practices". And yet, nothing "bad" happens.
Please share your thoughts as to:
|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||16-20 October 2023||Live, Online|
|Developing Minifilters||13-17 November 2023||Live, Online|
|Internals & Software Drivers||4-8 Dec 2023||Live, Online|
|Writing WDF Drivers||10-14 July 2023||Live, Online|