Share via

Filter Manager Concepts: Part 1 – FLTP_FRAME

  • Article

  • Filter Manager's only purpose is to simplify writing file system filters and sometimes it does this by abstracting some of the things that a filter needs to deal with. However, in my experience a good understanding of the mechanisms behind any abstraction is worth having as there usually are some corner cases where abstractions are either broken or unnatural. Also, even though some of the FltMgr's internal structures are not accessible to developers, they might still show up in debugging. So, without further ado, let's go through them one by one:

  •  

  • The FLTP_FRAME structure

  • A FRAME is a structure that describes a range of altitudes in FltMgr, across all volumes. If there are no legacy filters present, there is only one frame, "Frame 0". If there are some legacy filters present on the system (attached on top of Frame 0), FltMgr might create more frames. They aren’t very interesting for the minifilter writer but still one can see them in the debugger (this is the output on one of my test machines):

  •  

  •  0: kd> !fltkd.frames

    Frame List: fffff88001ab7380

       FLTP_FRAME: fffff98020692ac0 "Frame 3" "361111111.1 to 421111111.1"

       FLTP_FRAME: fffff9801e04eac0 "Frame 2" "271111111.1 to 361111111.1"

       FLTP_FRAME: fffff9801f7acac0 "Frame 1" "41111111.1 to 271111111.1"

       FLTP_FRAME: fffff98001218ac0 "Frame 0" "0 to 41111111.1"

          FLT_FILTER: fffff980163fe7b0 "PassThrough" "370130"

             FLT_INSTANCE: fffff9801629a6b0 "PassThrough Instance" "370130"

          FLT_FILTER: fffff980082026a0 "luafv" "135000"

             FLT_INSTANCE: fffff980082f84c0 "luafv" "135000"

          FLT_FILTER: fffff980012d2b40 "FileInfo" "45000"

             FLT_INSTANCE: fffff980012e2bb0 "FileInfo" "45000"

             FLT_INSTANCE: fffff9801ec96bb0 "FileInfo" "45000"

  •  

  • One important thing to note is that the frame is a logical unit that has no references to any objects outside itself. Which means that a frame is not aware of the existence of other frames in the system and of any objects in those frames and as such some of the functions that enumerate objects will only show objects inside a certain frame (for example FltGetLowerInstance, FltGetTopInstance, FltGetVolumeInstanceFromName and so on; these functions usually get a parameter that references some other object from which the function can figure out which frame it should look at). This can get in the way when trying to use more than one minifilter for some particular application as it is possible that each minifilter is in a different frame and this might need to be dealt with.

  •  

  • Also, a frame attaches to ALL mounted volumes in the system, which can lead to pretty strange layering:

  •  

  •  

  • As you can see, on \Device\HarddiskVolume1 there is only Frame 2 on top of Frame 1 on top of Frame 0. However, on \Device\CdRom0 there is Frame 2 on top of Legacy Filter 2 on top of Frame 1 on top of Frame 0. Currently frames can be created only when a minifilter is registering so it is possible that there are two legacy filters directly on top of one another without a frame between them, but I can't think of any case where that would cause problems.

  •  

  • I guess that's it for tonight. Frames aren't particularly interesting but I had to start somewhere. I also needed some entries on the blog so I can play with formatting :).

Comments

  • Anonymous
    June 25, 2009
    Actually, frames are interesting, since the fact a frame attaches to ALL mounted volumes in the system has one irritating side effect. Even if you minifilter does not wish to attach to Mup volumes, the frame to which it belongs will attach to the volume, increasing the likelihood of dreaded NO_MORE_IRP_STACK_LOCATIONS bug check (NO_MORE_IRP_STACK_LOCATIONS)

  • Anonymous
    June 25, 2009
    Well, don't get me wrong, i like frames. Some of my best friends are frames. I'm just saying they're not very instersting to filter writers, at least not at first...About the NO_MORE_IRP_STACK_LOCATIONS bugcheck.. I haven't seen one in a while (though we do test with multiple frames). AFAIK in general this is the fault of some legacy driver messing things up. (http://www.osronline.com/article.cfm?article=337)Also, as i said in the post, frames only get created when legacy file system filters are present on a system, which is a good incentive to get rid of those (for both customers and developers).

  • Anonymous
    June 25, 2009
    The comment has been removed

  • Anonymous
    June 26, 2009
    I can't comment on MUP, except to say that i know a lot of work was done on it and i have yet to see an instance of this bugcheck on win7.. But on the other hand that might also mean that the triage teams are doing a good job :).In the AV space things are much better, most AVs have switched to the minifilter model already or at least are considering it (or so i hope :)).Anyway, I expect that with time the number of legacy filters in use will decrease and there will only be one frame on most systems.