minifilter-----instance

The next logical structure in the hierarchy is the FLT_INSTANCE. An instance represents an attachment of a filter on a volume. Please note that any given filter may have more than one instance on a given volume, at different altitudes. This is something pretty unusual but the system allows it. I’ve used it when I wanted to monitor something between each installed minifilter.

Another case when this might come in handy is when developing a minifilter: a really good way to test it is to have multiple instances of it one below the other. This is unbelievably useful at revealing strange errors and unfortunate design decisions. And for those design decisions you don’t want to wait until your product is ready to ship so better start early on with this… It might require some effort to do this at first (including instrumenting your minifilter) but you’ll probably find some issues that would otherwise remain hidden until you interop with some other minifilter at PlugFest or until a customer finds it for you.

One important point is that all the instances of a minifilter belong to the same frame (I already mentioned this while talking about FLT_FILTER but this question seems to come up again and again). Given that having multiple instances on the same volume doesn’t appear to be that useful this is not a problem in general, but I still got bitten by it a couple of times.

Let’s see if i can fit more stuff in the picture:

So, just looking at the picture, we can tell that in Frame 2 (the one on the top) all the instances belong to one filter. It’s hard to tell why there are 3 instances of the same minifilter on the FLT_VOLUME associated with \Device\Mup, but you know, it can potentially happen.

Now, in the debugger you’ll see this (which, BTW, is completely unrelated to the picture above):

0: kd> !fltkd.filters
Filter List: fffffa80022fa0c0 "Frame 0"
   FLT_FILTER: fffffa800340b310 "luafv" "135000"
      FLT_INSTANCE: fffffa800340c010 "luafv" "135000"
   FLT_FILTER: fffffa80023009c0 "FileInfo" "45000"
      FLT_INSTANCE: fffffa800249cbb0 "FileInfo" "45000"
      FLT_INSTANCE: fffffa80028fc680 "FileInfo" "45000"
      FLT_INSTANCE: fffffa8002d40100 "FileInfo" "45000"
      FLT_INSTANCE: fffffa8002d663f0 "FileInfo" "45000"
      FLT_INSTANCE: fffffa8002910bb0 "FileInfo" "45000"
      FLT_INSTANCE: fffffa8001ac4bb0 "FileInfo" "45000"
      FLT_INSTANCE: fffffa8001fd9010 "FileInfo" "45000"
0: kd> !fltkd.instance fffffa800249cbb0
FLT_INSTANCE: fffffa800249cbb0 "FileInfo" "45000"
   FLT_OBJECT: fffffa800249cbb0  [01000000] Instance
      RundownRef               : 0x0000000000000000 (0)
      PointerCount             : 0x00000002
      PrimaryLink              : [fffffa800249c108-fffffa800249c108]
   OperationRundownRef      : fffffa800249b2f0
      Number                   : 2
      PoolToFree               : fffffa800249c910
      OperationsRefs           : fffffa800249c980  (0)
         PerProcessor Ref[0]      : 0xfffffffffffffe08 (-252)
         PerProcessor Ref[1]      : 0x00000000000001f8 (252)
   Flags                    : [00000000]
   Volume                   : fffffa800249c010 "\Device\Mup"
   Filter                   : fffffa80023009c0 "FileInfo"
   TrackCompletionNodes     : fffffa800249dfe0
   ContextLock              : (fffffa800249cc20)
   Context                  : fffffa80029186b0
   CallbackNodes            : (fffffa800249cc40)
   VolumeLink               : [fffffa800249c108-fffffa800249c108]
   FilterLink               : [fffffa80028fc6e0-fffffa8002300a80]

There really isn’t a lot here, most of the fields are related to keeping track of references. There are also the obvious pointers to the volume and filter objects for this instance.