Specifying Driver Load Order

For most devices, the physical hierarchy of the devices on a machine determines the order in which Setup and the PnP Manager load drivers. Setup and the PnP Manager configure devices starting with the system root device, and then they configure the child devices of the root device (for example, a PCI adapter), the children of those devices, and so on. The PnP Manager loads the drivers for each device as the device is configured, if the drivers were not previously loaded for another device.

Settings in the INF file can influence driver load order. This topic describes the relevant values that vendors should specify in the service-install-section referenced by a driver's INF AddService directive. Specifically, this topic discusses the StartType, LoadOrderGroup, and Dependencies entries.

Drivers should follow these rules for specifying StartType:

• PnP driver

  A PnP driver should have a start type of SERVICE_DEMAND_START (0x3), specifying that the PnP Manager can load the driver whenever the PnP Manager finds a device that the driver services.

• Driver for a device required to boot the machine

  If a device is required to boot the machine, the drivers for the device should have a start type of SERVICE_BOOT_START (0x0).

• Non-boot driver that detects device(s) that are not PnP-enumerable

  For a device that is not PnP-enumerable, a driver reports the device to the PnP Manager by calling IoReportDetectedDevice. Such a driver should have the start type SERVICE_SYSTEM_START (0x01) so Setup will load the driver during system initialization.

  Only drivers that report non-PnP hardware should set this start type. If a driver services both PnP and non-PnP devices, it should set this start type.

• Non-PnP driver that must be started by the Service Control Manager

  Such a driver should have the start type SERVICE_AUTO_START (0x02). PnP drivers must not set this start type.

A PnP driver should be written so that it can be loaded whenever Setup configures a device that the driver services. Conversely, a driver should be able to be unloaded any time the PnP Manager determines that there are no longer devices present that the driver services. The only driver load orderings that PnP drivers should depend on are the following:

1. The drivers for a child device can depend on the fact that the drivers for the parent device have been loaded.
2. A driver in the device stack can depend on the fact that any drivers below it have been loaded. For example, the function driver can be certain that any lower-filter drivers have been loaded.

   Note, however, that a driver in the device stack cannot depend on being loaded sequentially after a device's lower drivers, because the driver might have been loaded previously when another device was configured.

Filter drivers within a filter group cannot predict their load ordering. For example, if a device has three registered upper-filter drivers, those three drivers will all be loaded after the function driver but could be loaded in any order within their upper-filter group.

If a driver has an explicit load-order dependency on another driver, that dependency should be implemented through a parent/child relationship. A driver for a child device can depend on the drivers for the parent device being loaded before the child drivers are loaded.

To reinforce the importance of setting the correct StartType value, the following list describes how Setup and the PnP Manager use the StartType entries in INF files:

1. On system boot, the operating system loader loads drivers of type SERVICE_BOOT_START before it transfers control to the kernel. These drivers are in memory when the kernel gets control.

   Boot-start drivers can use INF LoadOrderGroup entries to order their loading. (Boot-start drivers are loaded before most of the devices are configured, so their load order cannot be determined by device hierarchy.) The operating system ignores INF Dependencies entries for boot-start drivers.

2. The PnP Manager calls the DriverEntry routines of the SERVICE_BOOT_START drivers so the drivers can service the boot devices.

   If a boot device has child devices, those devices are enumerated. The child devices are configured and started if their drivers are also boot-start drivers. If a device's drivers are not all boot-start drivers, the PnP Manager creates a devnode for the device but does not start the device yet.

3. After all the boot drivers have loaded and the boot devices are started, the PnP Manager configures the rest of the PnP devices and loads their drivers.

   The PnP Manager walks the device tree and loads the drivers for the devnodes that are not yet started (that is, any nonstarted devnodes from the previous step). As each device starts, the PnP Manager enumerates the children of the device, if any.

   As it configures these devices, the PnP Manager loads the drivers for the devices, regardless of the drivers' StartType values, and starts the devices. Many of these drivers are SERVICE_DEMAND_START drivers, but they can have any StartType.

   The PnP Manager ignores registry entries that were created as a result of INF Dependencies entries and LoadOrderGroup entries for drivers that it loads in this step. The load ordering is based on the physical device hierarchy.

   At the end of this step, all of the devices have been configured, except devices that are not PnP-enumerable and the descendants of those devices. (The descendants might or might not be PnP-enumerable.)

4. The PnP Manager loads drivers of StartType SERVICE_SYSTEM_START that are not yet loaded.

   These drivers detect and report their non-PnP devices. The PnP Manager processes registry entries that are the result of INF LoadOrderGroup entries for these drivers. It ignores registry entries that were created as a result of INF Dependencies entries for these drivers.

5. The Service Control Manager loads drivers of StartType SERVICE_AUTO_START that are not yet loaded.

   The Service Control Manager processes the service database information with respect to the services’ DependOnGroup and DependOnServices. This information is from Dependencies entries in INF AddService entries. Note that the Dependencies information is only processed for non-PnP drivers because any necessary PnP drivers were loaded in an earlier step of system startup. The Service Control Manager ignores INF LoadOrderGroup information.

   See the Platform SDK documentation for more information on the Service Control Manager.