It would be great to have an operation context be available when using notifications rather than callbacks. This would greatly simplify tracking things such as file open/close and allow easier correlation of all the other operations.
Alternative callback events that don't allocate byte's
Currently many of the callback events (e.g. OnReadFileC and OnWriteFileC) allocate new byte arrays and copy buffers before and after the handlers are invoked. In addition to placing extra load on the GC (and the LOH) it often results in wasted performance when the copying isn't required.
I propose that there should be overloads for these handlers that simply pass the IntPtr references supplied by the driver. Obviously this is for more advanced users, but if you can't work with IntPtrs you should probably not be playing around with filter drivers anyway :)
Currently, if I need to get access to a file from the callback, I have to track CbFltPostOpenFileC and CbFltPostCreateFileC, use OpenFile method in a proper moment of time, create context with refcounting, and store file handle there. And still I have to be very cautious, because some WinAPI functions called in improper moment of time will hang the system. This look too overcomplicated to me. What I suggest, is an alternative - use a "magic suffix" to access files from callbacks. So, when I append this suffix to the file path passed to WinAPI functions, the CallbackFilter will know to pass all operations on this path directly to the filesystem and don't call any callbacks on it. This will avoid deadlocks in much simpler way.