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: https://www.osr.com/osr-learning-library/
Best Of
Re: Just Trying To Help
If it is not for OSR and a few of you experts I can't imagine where I can get the help I need!
You guys here are SUPER expert, SUPER kind, SUPER patient and SUPER cool. OSR is irreplaceable.
I can imagine how many hours a day you spend helping others like me whom sometimes seem to even refuse to understand(talking to myself)! despite how much busy you are. And I can't ever imagine myself doing so.
Thanks for your kindness.
Re: Synchronization for WDF inverted call
IDK = I don't know.
This case is closed to me now. But since you are so kind to post some advice I am giving a short explanation.
The purpose here was not a business goal I was training mostly. However I made a library and I am using it currently. It was a bit hard for me as a learner. But not that much hard you mentioned.
Of course we don't know if my library is perfect enough and optimized. But it is working for me.
A real general purpose library should be written by experienced experts to be completely optimized and consider low performance, high performance and low recourse conditions and probably more considerations I'm not aware of yet.
I think it's better to not drag this discussion anymore since the case is solved and I kind of feel it is against the community guidelines to post more
Re: How does one define #pragma alloc_text(X,Y)
Leave them all non-pageable. It's not worth the trouble.
Re: FltGetFileContext cause bsod in filter pre operation callback (IRP_MJ_READ)
FltGetFileContext requires IRQL < DISPATCH_LEVEL but your PostRead can run at IRQL <= DISPATCH_LEVEL. If you need your file context in Post you need to get it in Pre and pass it via your completion context.
Re: FltGetFileContext cause bsod in filter pre operation callback (IRP_MJ_READ)
The documentation does a poor job clarifying IRQL rules around Pre/Post operation callbacks. Documenting this is on my prioritized list of things to do (which is around here someplace...I think the last time I saw it was March 
).
FltMgr guarantees that PostCreate will be called at PASSIVE_LEVEL and in the same context as PreCreate. The documentation confirms that here:
Post-create callback routines are called at IRQL = PASSIVE_LEVEL, in the context of the thread that originated the IRP_MJ_CREATE operation.
No such guarantee is made for PostRead/PostWrite (which are the ones most likely to execute at IRQL DISPATCH_LEVEL).
Re: Driver Signing options for an independent developer
Sounds interesting. Based on your description, I think your driver
will attract some users and someone may get interested to help you.
Wish you all the best for your driver development journey.
Windows driver development is a niche. Open Source Windows driver
development by independent developers is even more of a niche. So I
think you should be encouraged rather than getting discouraged.
On Wed, Sep 9, 2020 at 5:41 AM rumble06
[email protected] wrote:
>
I'm not sure if people would use it or find it as interesting as I find it, but I hope so. Pretty much the driver and the app(or api, if someone wants to build a better app than mine but with the same driver) would allow to setup per-keyboard macros. I tried to do something similar using windows api without going to kernel, but that's not really possible in windows (with raw input you can't cancel or modify inputs but you can see from which keyboard it comes and with the WH_KEYBOARD_LL event you can cancel the key press but you can't see from which keyboard it comes, and the WH_KEYBOARD_LL event comes before the raw input so I can't use both of them to achieve a solution without using kernel). There is already a similar driver on the market (called Interception), but the driver is closed-source and once you have 10 devices plug into computer it would forcefully fail the connection of every device plugged after (my keyboard creates 3 devices alone inside device manager) so that is not an option. My idea is to launch it as open-source as if anyone is interested in it and more experienced than me, can improve it or take advantage of it. Found out about Interception from Taran (a linustechtips employee), he has like 2-3 videos in Linus's channel talking about this problem and how he didn't find a GOOD solution yet and I'm trying to fill this gap and help the community. So I hope it'll be interesting enough that I can get someone to build the project from the source and sign it with their own certificate.
>
Re: Dose WDF have any concept like minifilter communication ports?
There is no case where (given properly written code and the continued existence of global concepts like gravity) you can call ReadFile, get back status pending, and not get notification of the I/O Request completing.
It HAS to be this way, right? You can’t call ReadFile synchronously and sometimes just never return. It’s exactly the same... it’s just a matter of where the wait for the I/O to complete takes place. For synchronous notification, your thread waits in the I/O Manager before returning for the call to ReadFile. For asynchronous notification, the I/O Manager returns without waiting and you wait (or otherwise get the notification) when you decide you want to.
But in no case can I/Os just “go missing.”
Peter
Re: my Volume access control minifilter causes USB mass storage eject to fail
If your policy is for write access denied are you handling the queries on whether the volume is write protected and indicating it is read only? You cannot just blindly stop all writes to the volume, unless you have done this.
I am assuming that this is a system wide block of the writes.
Don_Burn
Re: С++ in kernel
@mm About your example - C++ language exceptions are very different from "asynchronous" exceptions, aka signals. The latter generally may occur when the program state is corrupted (like memory overwrite) so should not be recovered by a language exception handler. So it's not a good example here.
-- pa
Pavel_A
Re: С++ in kernel
There are implementations of STL that do not throw exceptions, and rumor has it they can be used in the kernel. I've always been a little wary of those; STL tends to be pretty free with memory, and memory churn in a driver is undesirable.