Driver Altitudes

A key benefit of filter drivers in general is that any number of them can be active at the same time. To keep things organized, Windows maintains a separate stack of filter drivers for each applicable system component (filesystem, registry, and process manager), and ensures that each stack is sorted consistently based on the drivers' altitudes.

These altitudes, which are expressed as decimal numbers, essentially define each driver's absolute position in the stack. Drivers with higher altitudes are attached towards the top of the stack, closer to user mode; while drivers with lower altitudes are attached towards the bottom of the stack, closer to the applicable system component. Please refer to Microsoft's Load Order Groups and Altitudes for Minifilter Drivers article for more information about altitudes (much of the content there is specific to filesystem filter drivers; but the general concepts apply to all filter drivers).

When an operation is requested, that request "enters" the top of the filter driver stack and moves downwards, towards the applicable system component. Once the request has been handled (either by the system component, or by one of the filter drivers in the stack), a response travels back up the stack. So the process of choosing a suitable altitude depends primarily on the intended functionality of the filter application being developed. That said, there are also some factors specific to each type of filter driver; please refer to the sections below for more information.

Filesystem Minifilter Drivers

Of the three kinds of filter drivers mentioned above, filesystem filter drivers are by far the most complex, which is why much of Microsoft's altitude documentation is presented from a filesystem-centric context. Adding to this complexity is the fact that, of the two types of filesystem filter drivers (minifilter and legacy), only minifilter drivers use altitudes to determine their position in the driver stack, and only minifilter drivers can be loaded and attached to the driver stack on-demand. Legacy filter drivers are simply loaded onto the stack in order according to their load order group, as described in Microsoft's Load Order Groups for [Legacy] File System Filter Drivers article.

In order to maintain interoperability with legacy filesystem filter drivers, each load order group has a defined range of altitudes associated with it, as shown in the Load Order Groups and Altitudes for Minifilter Drivers article. To prevent collisions, Microsoft also manages all filesystem minifilter altitude assignments.

When developing an application that uses CBFilter and/or CBMonitor in minifilter mode, an altitude must be requested from Microsoft. Use the instructions described in their Minifilter Altitude Request article; and be sure to specify "FileSystem" (or "Both") for the "Filter type:" field when composing the request.

Once Microsoft has assigned an altitude for the application, it should be specified using the Altitude property and/or the Altitude parameter of the Install method, which are available in both CBFilter and CBMonitor.

Registry Filter Drivers

Registry filter drivers are not required to have an altitude (in which case they will be attached near the top of the driver stack), but it is recommended that one be requested anyway. Please refer to Microsoft's Supporting Layered Registry Filtering Drivers article for more information.

While not explicitly stated in the aforementioned article, registry filter driver altitudes can be requested from Microsoft in the same manner as they are for filesystem minifilter driver altitudes. Use the instructions described in their Minifilter Altitude Request article; and be sure to specify "Registry" (or "Both") for the "Filter type:" field when composing the request.

Once Microsoft has assigned an altitude for the application, it should be specified using CBRegistry's Altitude property.

Process Manager Filter Drivers

Microsoft is fairly vague about altitudes for process manager filter drivers; there is essentially no information about them beyond confirmation of their existence, as the documentation for the OB_CALLBACK_REGISTRATION structure shows. Notably, it is unclear whether there is a standard way to request an altitude for a process manager filter driver as there is for the other two kinds of filter drivers.

With that in mind, applications are free to set CBProcess's Altitude property as desired. CBProcess also provides an extra property, StrictAltitude, which specifies how the class should behave if the chosen altitude is already in use.