Controlling Driver Load Sequence

< BACK  NEXT >

[oR]

Sometimes, the order in which a driver loads is important. Perhaps one driver depends on another to complete its initialization. When such dependencies arise, the Service Control Manager can be informed with the Registry entries LoadOrderGroup and Dependencies. These values can also be specified in the [ServiceInstall] section of an INF file.

The LoadOrderGroup identifies by name a single group in which the specified driver is a member. The Dependencies value specifies which other groups must load prior to this driver loading successfully.

The need for such interdependencies is not common, nor should it be. In a truly device-centric environment (which Plug and Play purports), drivers should be in a position to load and unload with few strings attached. On the other hand, heavily layered driver implementations may have legitimate needs for such specifications.

Driver Stack Order

A related issue concerns the order in which drivers stack. In a layered driver environment, any number of drivers can stack on top of each other to distribute and reuse code. In a typical WDM model, driver stacks exist that contain a PDO (Physical Device Object) at the bus level, a possible bus filter object, an FDO (Functional Device Object), and surrounding upper and lower filter devices. (refer to chapters 1 and 15.)

In such environments, it is the Registry entries (once again) for each driver layer that determine the order in which drivers stack. Notice that the load order is independent of the stack order. When a driver invokes IoAttachDeviceToDeviceStack, it is the responsibility of the I/O Manager to link drivers appropriately, independently of their load order.

The Registry entries for a driver may contain values named UpperFilters and LowerFilters. These are REG_MULTI_SZ string arrays, each containing the names of drivers that stack above and below the given driver. The order of the string array determines the stack order for multiple upper or lower filters.

A segment of an INF file appears below to demonstrate the installation of a filter driver. Notice that the upper filter is installed as a demand start driver. Even though it has announced that it stacks on top of the functional device, the driver may not load and insert itself into the stack until it is manually loaded.

 ... [upperFilter_install]  ; DDInstall section CopyFiles = @upperFilter.SYS AddReg = upperFilter_addreg [upperFilter_addreg]   ; AddReg section ; append this filter to the list of filters HKR,,"UpperFilters",0x10008,"upperFilter" [upperFilter_install.Services]  ; DDInstall.Services AddService = Launcher,0x2,Launcher_Service AddService = upperFilter,,upperFilter_Service [upperFilter_Service] DisplayName = "Upper Filter Service for Launcher" ServiceType = 1   ; kernel-mode driver StartType = 3     ; demand start ErrorControl = 1 ServiceBinary = %12%\upperFilter.SYS 

< BACK  NEXT >