Hello,
I’m completely new to developing drivers, but I have been developing user-mode applications for quite a long time. While learning the concepts of developing minifilters, I learned that I can communicate with user-mode applications through the communication ports. At the same time, here , it says “A file system driver (FSD), which executes in the context of a user-mode thread that calls an I/O system service”. These two statements made me anxious - what about race conditions in the driver? I mean, race conditions are quite feared in user-mode - so it seems like God only knows what terrible things they can cause in kernel mode.
Le’s be a little more specific - let’s say I have MessageNotifyCallback registered through FltCreateCommunicationPort, and at the same time I have a post-op-callback registered for IRP_MJ_CREATE. Can these things be executed concurrently? Do I need to use synchronization primitives while writing the file system minifilter driver, even if I’m not using any thread concepts directly in my code? And the other question is - where can I find the explanations for how and when?
I am amazed that there seems to be so little recently posted information on writing drivers these days, even though it seems to me that the entire framework of higher-level concepts is built upon these things. Maybe it’s just me not being able to find any. Regardless, I’ll be very grateful to anyone who helps and explains, and even more so to those who can give me the places to go for answers to.
Short answer:
Yes, these things can run in parallel. It would be terrible for perf if file system operations came to a halt every time a message was sent to a communication port.
Long answer/tangent:
The interface between the file systems and the I/O, Cache, and Memory Managers in Windows is complicated and poorly documented. Even worse, when you start to push at the edges it’s very subject to the specific implementation of the underlying file system.
File system filters insert themselves between the file system and the I/O, Cache, and Memory Managers. Now you’re responsible for understanding the vagaries of the interface AND the dealing with the implementation specific behaviors of the underlying file system. Then Filter Manager comes along and tries to abstract away this complicated interface into something more consumable, though it does NOT save you from understanding what’s going on behind the scenes.
So, I recommend for someone starting out to step waaaay back and try to understand where exactly you sit in the OS:
- Read the first few chapters of the NT File System Internals book. It’s so old but the initial architectural concepts hold: https://www.amazon.com/Windows-File-System-Internals-Developers/dp/1565922492
- Build your own copy of FAT32 (source on GitHub) and play with it on a test machine (breakpoints, DbgPrints, etc.). Ignore anything to do with the on disk format and just focus on the entry points (i.e. set some breakpoints in FatCommonWrite and step through some write operatiuons). FAT32 doesn’t have all the features of other file systems, but it’s what we have (and many of the other file systems started out with FAT as a template)
- I’m biased but I think our minifilter seminar is a great way to get started. It focuses a lot on the underlying architecture to help get you over the initial learning hump https://www.osr.com/seminars/minifilters/
-scott