Example PnP Device Installation

To illustrate the interaction of the components involved in device installation, this section steps through the installation of a hot-plug PnP device with an accompanying CD of supporting files.

The following figure shows the software components that participate in installing the PnP device. The shaded components are items that a device vendor might supply.

Example PnP Device Installation

The following notes correspond to the circled numbers in the figure:

1. The user plugs the device into the computer.

   If the device and the bus support hot-plug notification, the user can plug in a new device while the system is running.

2. The device is enumerated.

   The bus driver, with support from the bus, receives hot-plug notification of the new device. The bus driver notifies the kernel-mode PnP Manager that the list of devices on the bus has changed by calling IoInvalidateDeviceRelations. In this case, the change is a new device on the bus.

   The kernel-mode PnP Manager queries the bus driver for a list of devices present on the bus by sending an IRP_MJ_PNP with IRP_MN_QUERY_DEVICE_RELATIONS for BusRelations. The bus driver responds to the IRP with current list of devices on the bus. The kernel-mode PnP Manager compares the new list against the previous list and, in this case, determines that there is one new device on the bus.

   The kernel-mode PnP Manager sends IRPs to the bus driver to gather information about the new device, such as the device's hardware IDs, compatible IDs, and device capabilities. The IRPs include IRP_MN_QUERY_ID and IRP_MN_QUERY_CAPABILITIES. For more information on the enumeration activities of the kernel-mode PnP Manager, see Adding a PnP Device to a Running System.

3. The kernel-mode PnP Manager notifies the user-mode PnP Manager that there is a device to be installed.

   The user-mode PnP Manager tries to perform a trusted installation (a server-side installation), but it cannot in this example because it needs to display a UI to ask the user for an installation disk for the device.

4. The user-mode PnP Manager creates a new process using rundll32.exe and launches newdev.dll to install the device.
5. The New Device DLL calls device installation functions (Setup API)and PnP Configuration Manager functions (CfgMgr API) to carry out its installation tasks.

   The New Device DLL calls SetupDiBuildDriverInfoList to build the list of possible drivers for the device. In this example, none of the INFs on the system matches the new device, so the returned driver list is empty. The New Device DLL displays the Found New Device wizard. The user supplies the location of the drivers (floppy disk, CD, or Windows® Update). In this example, the driver files are on a CD, so the user loads the CD and clicks Next in the wizard. The New Device DLL calls SetupDiBuildDriverInfoList again with the new location and receives a list that contains the drivers from the CD.

   For more information on driver selection, see How Setup Selects Drivers.

   (Note that for this example, in which the device's drivers are not included with the operating system, the sequence described is valid only if the user plugs in the new device after the operating system has been installed. If a device without "in box" drivers is plugged in before the operating system is installed, the Device Manager will show the device as "unknown".)

6. The class installer and co-installers, if any, can participate in the installation by handling DIF requests.

   For example, the New Device DLL calls SetupDiCallClassInstaller to send the DIF_SELECTBESTCOMPATDRV installation request. SetupDiCallClassInstaller sends the DIF request to any class co-installers that are registered for the device and to the class installer for the device, if there is one.

   The New Device DLL sends a series of DIF codes, including DIF_SELECTBESTCOMPATDRV, DIF_ALLOW_INSTALL, DIF_INSTALLDEVICEFILES, DIF_REGISTER_COINSTALLERS, DIF_INSTALLINTERFACES, and DIF_INSTALLDEVICE. The class installer and co-installers can participate in servicing these DIF codes.

   Setup uses the Class and ClassGUID entries in the device's INF Version section to determine the device setup class. The setup class determines the class installer and the class co-installers for the device, if any. Device-specific co-installers are listed in the INF DDInstall.Coinstallers section. For more information on installers, see Writing a Co-installer and Writing a Class Installer.

7. Setup transfers control to kernel mode to load drivers and start the device.

   Once Setup has selected the best driver for the device, copied the appropriate driver files, registered any device-specific co-installers, registered any device interfaces, and so forth, it transfers control to kernel mode to load the drivers and start the device. The appropriate CfgMgr function sends a request to the user-mode PnP Manager, which passes it to the kernel-mode PnP Manager.

8. The PnP Manager loads the appropriate function driver and any optional filter drivers for the device.

   The PnP Manager calls the DriverEntry routine for any required driver that is not yet loaded. The PnP Manager then calls the AddDevice routine for each driver, starting with lower filter drivers, then the function driver, and, lastly, any upper filter drivers. The PnP Manager assigns resources to the device, if required, and sends an IRP_MN_START_DEVICE to the device's drivers.

9. Installers can supply wizard pages to change device settings.

   Setup sends a DIF_NEWDEVICEWIZARD_FINISHINSTALL request before it displays the standard Finish page. This is an opportunity for installers to add custom pages to change device settings, if necessary.