Specifying Driver Load Order

For most devices, the physical hierarchy of the devices on a computer determines the order in which Windows and the PnP manager load drivers. Windows 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, BootFlags, LoadOrderGroup, and Dependencies entries.

Drivers should follow these rules for specifying StartType:

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

Driver for a device required to start the computer

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

Non-boot-start 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 Windows 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 when Windows configures a device that the driver services. Conversely, a driver should be able to be unloaded any time that 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 as follows:

The drivers for a child device can depend on the fact that the drivers for the parent device are loaded.

A driver in the device stack can depend on the fact that any drivers below it are loaded.

For example, the function driver can be certain that any lower-filter drivers are loaded.

However, be aware that a driver in the device stack cannot depend on being loaded sequentially after a device’s lower drivers, because the driver might are loaded previously when another device was configured.

Filter drivers in 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 Windows and the PnP manager use the StartType entries in INF files:

On system startup, 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.

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 device node (devnode) for the device but does not start the device yet.

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 (except when StartType is SERVICE_DISABLED) before proceeding to start the devices. Many of these drivers are SERVICE_DEMAND_START drivers.

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 the devices are configured, except devices that are not PnP-enumerable and the descendants of those devices. (The descendants might or might not be PnP-enumerable.)

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 because of INF Dependencies entries for these drivers.

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. Be aware 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 Microsoft Windows SDK documentation for more information about the service control manager.

Using BootFlags to Promote a Driver’s StartType at Boot Depending on Boot Scenario

The operating system can promote a driver’s StartType to be a boot start driver depending on the BootFlags value specified in the driver’s INF. You can specify one or more (ORed) of the following numeric values in the INF file, expressed as a hexadecimal value:

• If a driver should be promoted to be a boot start driver on network boot, specify 0x1 (CM_SERVICE_NETWORK_BOOT_LOAD).
• If a driver should be promoted on booting from a VHD, specify 0x2 (CM_SERVICE_VIRTUAL_DISK_BOOT_LOAD)
• If a driver should be promoted while booting from a USB disk, specify 0x4 (CM_SERVICE_USB_DISK_BOOT_LOAD).
• If a driver should be promoted while booting from SD storage, specify 0x8 (CM_SERVICE_SD_DISK_BOOT_LOAD)
• If a driver should be promoted while booting from a disk on a USB 3.0 controller, specify 0x10 (CM_SERVICE_USB3_DISK_BOOT_LOAD).
• If a driver should be promoted while booting with measured boot enabled, specify 0x20 (CM_SERVICE_MEASURED_BOOT_LOAD).
• If a driver should be promoted while booting with verifier boot enabled, specify 0x40 (CM_SERVICE_VERIFIER_BOOT_LOAD).
• If a driver should be promoted on WinPE boot, specify 0x80 (CM_SERVICE_WINPE_BOOT_LOAD).

For more information about promoting a driver’s StartType at boot, depending on the boot scenario, see INF AddService directive.

Enable Loading of Test Signed Drivers

By default, Windows does not load test-signed kernel-mode drivers. To change this behavior and enable test-signed drivers to load, use the boot configuration data editor, BCDEdit.exe, to enable or disable TESTSIGNING, a boot configuration option. You must have Administrator rights to enable this option.

For 64-bit versions of Windows Vista and later versions of Windows, the kernel-mode code signing policy requires that all kernel-mode code have a digital signature. However, in most cases, an unsigned driver can be installed and loaded on 32-bit versions of Windows Vista and later versions of Windows. For more information, see Driver Signing Policy.

Administrator rights required

To use BCDEdit, you must be a member of the Administrators group on the system and run the command from an elevated command prompt. To open an elevated Command Prompt window, type cmd into the search box in the Windows taskbar, select and hold (or right-click) Command Prompt in the search results, and then select Run as administrator.

Administrative rights are required to use BCDEdit to modify boot configuration data. Changing some boot entry options by using BCDEdit /set could render your computer inoperable. As an alternative, use System Configuration utility (MSConfig.exe) to change boot settings.

Enable or disable use of test-signed code

Run BCDEdit command lines to enable or disable the loading of test-signed code. For a change to take effect, whether enabling or disabling the option, you must restart the computer after changing the configuration.

To enable test-signed code, use the following BCDEdit command line:

To disable use of test-signed code, use the following BCDEdit command line:

The following figure shows the result of using the BCDEdit command line to enable test-signing.

Behavior of Windows when loading test-signed code is enabled

When loading test-signed code is enabled, Windows does the following:

Displays a watermark with the text «Test Mode» in all four corners of the desktop, to remind users the system has test-signing enabled. NoteВ В Starting with Windows 7, Windows displays this watermark only in the lower right-hand corner of the desktop.

Displays a watermark with the text «Test Mode» in the lower-left corner of the desktop to remind users that the system has test-signing enabled.

The operating system loader and the kernel load drivers that are signed by any certificate. The certificate validation is not required to chain up to a trusted root certification authority. However, each driver image file must have a digital signature.

Loading and Unloading

About Loading and Unloading

A minifilter driver can be loaded at any time while the system is running. If a minifilter driver’s INF file specifies a driver start type of SERVICE_BOOT_START, SERVICE_SYSTEM_START, or SERVICE_AUTO_START, the minifilter driver is loaded according to existing load order group definitions for file system filter drivers, to support interoperability with legacy filter drivers. While the system is running, a minifilter driver can be loaded through a service start request (sc start, net start, or the service APIs), or through an explicit load request (fltmc load, FltLoadFilter, or FilterLoad).

A minifilter driver’s DriverEntry routine is called when the minifilter driver is loaded, so the minifilter driver can perform initialization that will apply to all instances of the minifilter driver. Within its DriverEntry routine, the minifilter driver calls FltRegisterFilter to register callback routines with the filter manager and FltStartFiltering to notify the filter manager that the minifilter driver is ready to start attaching to volumes and filtering I/O requests.

Minifilter driver instances are defined in the INF file used to install the minifilter driver. A minifilter driver’s INF file must define a default instance, and it can define additional instances. These definitions apply across all volumes. Each instance definition includes the instance name, its altitude, and flags that indicate whether the instance can be attached automatically, manually, or both. The default instance is used to order minifilter drivers so that the filter manager calls the minifilter driver’s mount and instance setup callback routines in the correct order. The default instance is also used with explicit attachment requests when the caller doesn’t specify an instance name.

The filter manager automatically notifies a minifilter driver about an available volume by calling its InstanceSetupCallback routine on the first create operation after the volume is mounted. This can occur before FltStartFiltering returns, when the filter manager enumerates existing volumes at system startup. It can also occur during runtime, when a volume is mounted or as a result of an explicit attachment request (fltmc attach, FltAttachVolume, or FilterAttach).

A minifilter driver instance is torn down when the minifilter driver is unloaded, the volume the instance is attached to is being dismounted, or as a result of an explicit detach request (fltmc detach, FltDetachVolume, or FilterDetach). If the minifilter driver registers an InstanceQueryTeardownCallback routine, it can fail an explicit detach request by calling FilterDetach or FltDetachVolume. The teardown proceeds as follows:

If the minifilter driver registered an InstanceTeardownStartCallback callback routine, the filter manager calls it at the beginning of the teardown process. In this routine, the minifilter driver should complete all pending operations, cancel or complete other work such as I/O requests generated by the minifilter driver, and stop queuing new work items.

During instance teardown, any currently executing preoperation or postoperation callback routines continue normal processing, any I/O request that is waiting for a postoperation callback can be «drained» or canceled, and any I/O requests generated by the minifilter driver continue normal processing until they are complete.

If the minifilter driver registered an InstanceTeardownCompleteCallback routine, the filter manager calls this routine after all outstanding I/O operations have been completed. In this routine, the minifilter driver closes any files that are still open.

After all outstanding references to the instance are released, the filter manager deletes remaining contexts and the instance is completely torn down.

While the system is running, a minifilter driver can be unloaded through a service stop request (sc stop, net stop, or the service APIs), or through an explicit unload request (fltmc unload, FltUnloadFilter, or FilterUnload).

A minifilter driver’s FilterUnloadCallback routine is called when the minifilter driver is unloaded. This routine closes any open communication server ports, calls FltUnregisterFilter, and performs any needed cleanup. Registering this routine is optional. However, if the minifilter driver does not register a FilterUnloadCallback routine, the minifilter driver cannot be unloaded. For more information about this routine, see Writing a FilterUnloadCallback Routine.

Filter Manager Routines for Loading and Unloading Minifilter Drivers

The filter manager provides the following support routines for explicit load and unload requests, which can be issued from user mode or kernel mode:

The following routines are used to register and unregister callback routines for instance setup and teardown:

Minifilter Driver Callback Routines for Instance Setup, Teardown, and Unload

The following minifilter driver callback routines are stored as members of the FLT_REGISTRATION structure that is passed as a parameter to FltRegisterFilter: