Section 6: Driver Loading and Initialization

The Big Picture: From a File on Disk to a Working Translator

A driver on disk is just a sleeping .sys file. To be useful it must be loaded into memory, started, and then attached to its device. This section follows that path. If you read Chapter 12 (services), you will see a lot of familiar ideas. Windows starts many drivers the same way it starts services: by reading entries in the registry.

Where those entries live:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<driver name>

Each driver has its own key here, such as ...\Services\disk or ...\Services\kbdclass. You can open it with regedit (view only; do not change anything).

Important values inside a driver's key:

6.1 DriverEntry Function

What it is: DriverEntry is the first function that runs when a kernel driver is loaded. It is the driver's equivalent of main() in an ordinary program. Windows calls it once, passing the new driver object (Section 4.3).

What DriverEntry does:

An important point: For a modern Plug and Play driver, DriverEntry does not touch the hardware. It only sets things up. The real device work waits until a device actually shows up (6.4). (Older, non-PnP drivers did create their devices right here.)

 Load .sys into kernel memory
        │
        ▼
 Windows creates the DRIVER OBJECT
        │
        ▼
 DriverEntry( driver object )     ◄── runs ONCE per driver
   · fill dispatch table
   · set AddDevice, Unload
   · return SUCCESS

If DriverEntry returns an error, the driver is unloaded and the device may show an error such as Code 10 ("This device cannot start") in Device Manager. Windows 10/11 Device Manager shows a code and a short message for each such problem.

WDF drivers have a DriverEntry too. It mainly calls the framework to say "here is how I handle devices."

6.2 Load Order Groups

What it is: Some drivers must start before others. A disk driver must be ready before the file system driver can use the disk. Windows uses groups and tags to order drivers that start at the same stage.

A driver's registry key has Group (a name such as Boot Bus Extender, System Bus Extender, SCSI Miniport, Filter, Boot File System, Base, Extended Base, Network, PNP_TDI...). Windows keeps the official order in a list:

HKLM\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder     (value: List)

Drivers in earlier groups are loaded first. Inside one group, the Tag number can give further order.

 earlier ───────────────────────────────────────────────► later
 [Boot Bus Extender] → [System Bus Extender] → [SCSI miniport] → [Filter] → [Boot File System] → ...
   bus drivers           more bus drivers        disk hardware      filters     NTFS

Group ordering is a hint for ordering, not a magic fix for all dependencies. For hard "A needs B" relationships, Windows has explicit dependency values (Section 13). Plug and Play also starts most drivers in tree order: bus first, children after (Section 7).

6.3 Boot-Start, System-Start, Auto-Start, Demand-Start Drivers

What it is: The Start value says when during boot (or later) a driver is loaded.

  Power on
     │
     ▼
 Firmware (UEFI) ──► Boot loader ──► loads Boot-start drivers (Start=0)
                                          │   (just enough to read the disk)
                                          ▼
                          Kernel starts ──► System-start drivers (Start=1)
                                          │
                                          ▼
                       Session Manager / services ──► Auto-start (Start=2)
                                          │
                                          ▼
                      Later, when a device is plugged in ──► Demand (Start=3)

Why does boot start matter so much? The boot loader can only read a disk if it has a driver for the disk. Before Windows is running, there is no one else to ask. If a boot-start driver is broken or missing, Windows cannot even finish starting. The result is a blue screen at boot, such as INACCESSIBLE_BOOT_DEVICE or CRITICAL_SERVICE_FAILED (Section 14).

Chapter link (12): a service has the same Start values (automatic, manual, disabled). A driver is simply a kind of "service" with Type = 1 or 2, run in the kernel. The same sc and registry ideas apply. For instance, sc query type= driver lists drivers as services.

What happens at shutdown or when a device is removed? If the driver supports it, Windows calls its Unload routine: free memory, stop timers, undo what DriverEntry set up. Many drivers cannot be unloaded while a device is still using them.

6.4 AddDevice Routine

What it is: AddDevice is the function that runs once for each device the driver is asked to manage. DriverEntry is called once per driver; AddDevice is called once per device. (This applies to WDM-style PnP drivers. WDF drivers use a similar callback named EvtDriverDeviceAdd.)

Why separate? One driver may run several identical devices: two network cards, or a USB hub with four keyboards. The driver is loaded once but AddDevice runs for each.

What AddDevice does:

Still no hardware is touched here. The device is only added to the stack, ready to be started by Plug and Play.

  Before AddDevice            After AddDevice
  ┌──────────────┐            ┌──────────────┐
  │              │            │ FDO (new)    │  ◄── created by AddDevice
  ├──────────────┤            ├──────────────┤
  │ PDO (bus)    │            │ PDO (bus)    │
  └──────────────┘            └──────────────┘

6.5 Device Initialization Sequence

What it is: The complete order of events between "driver is found" and "device is working." Here are the steps for a typical Plug and Play device:

 DriverEntry ─► AddDevice ─► (resources assigned) ─► START_DEVICE ─► WORKING
   once          per device       by PnP Manager        hardware       requests flow
   per driver                                           initialized

Stopping is the reverse. When a device is removed or disabled, Windows sends a stop/remove message. The driver shuts the hardware down, frees resources and detaches its device object.

Why a start message is needed: The device might be a card that was only just plugged in. The OS needs to give it its resources first. Only then can it be touched. This design lets Windows start, stop and move devices on the fly without a reboot.

Summary