Installing Drivers and Utilities without Rebooting
The Microsoft Windows 2000 and Windows XP operating system includes significant enhancements to ensure greater reliability and availability. Among these enhancements is a greatly reduced need to reboot the system to complete administrative tasks such as installation of new hardware, device drivers, and application software.
Avoiding unnecessary reboots benefits original equipment manufacturers (OEMs) that preinstall drivers and applications on systems in a factory environment, and it benefits system administrators who perform script-based installations of software over corporate networks. It also ensures a better experience for end users who add new functionality to their systems.
Hardware manufacturers and application software developers should design their installation applications as described in this article so that it is not necessary to reboot the system to complete the installation.
For related information about entries that are written to the log when the system prompts for reboot during device installation, review SetupAPILog.doc.
For related information about how Windows File Protection prevents shared system files from being replaced by application or driver installation, see "Windows File Protection and Windows."
Rebooting the system is rarely necessary when installing Plug and Play devices or software applications on systems running Windows 2000. This is true because of the following reasons:
- The Plug and Play Manager installs and configures drivers for Plug and Play devices while the operating system is running.
- Applications can use side-by-side components instead of replacing shared, in-use dynamic-link libraries (DLLs).
This section describes the few circumstances under which it is acceptable to reboot the system during installation. It also lists many operations that required rebooting in earlier versions of Windows operating systems, but do not require rebooting in Windows 2000.
When installing a new hardware component or application, it is acceptable to reboot the system only in the following circumstances:
- Installing files as part of an operating system service pack or hot fix.
- Adding a second CPU to a single-processor system, which requires manually changing the computer type in Device Manager and restarting the system to update the hardware abstraction layer (HAL). For information, see How to Add Support for Multiple Processors in Windows 2000.
- Adding or removing a legacy device such as non-Plug and Play ISA devices and legacy COM ports. This might require shutting down the system and restarting it so that hardware configuration changes, such as jumper settings, can take effect. Note, however, that the driver of such a device should not need to force a reboot after the power cycle finishes.
- Updating a driver for a boot device such as a mass storage device that contains the system paging file, hibernation path, or crash dump path. The operating system notifies the driver for such a device before it writes such a file to the device (IRP_MN_DEVICE_USAGE_NOTIFICATION). If the driver succeeds the notification IRP, the operating system expects it to fail a device-removal request (IRP_MN_QUERY_REMOVE_DEVICE) as long as its device contains one of these files. Failing a device-removal request causes the system to prompt for a reboot.
For information about how to support installation of a new display driver without reboot, see "Tips for Specific Device Classes" later in this topic.
- Installing a non-Plug and Play filter driver, such as a filter driver for a legacy device or a file-system filter driver. This includes most anti-virus products, which are implemented as file-system filter drivers.
A system must be shut down to add or remove RAM. However, after the system has been powered up again, it is not necessary to reboot after Windows identifies the system change.
Driver and application installation programs should not force reboots related to any of the following configuration changes:
- Adding a new page file or increasing the size of an existing page file
- Changing performance optimization between applications and background services
- Extending or mirroring a Windows NT file system (NTFS) volume
- Docking or undocking a laptop computer
Installing any of the following:
- Microsoft Driver Development Kits (DDKs) or Software Development Kits (SDKs).
- Internet Information Server
- Microsoft Connection Manager
- Microsoft Exchange Server 5.5 or later
- Microsoft SQL Server 7.0
- Microsoft Transaction Services
Installing or removing drivers for any of the following:
- PC Card or CardBus devices
- Hard disks and tape storage (with the exception of boot devices that contain the system paging file, hibernation path, or crash dump path as described earlier in this paper)
- Plug and Play modems
- Universal Serial Bus (USB) devices, including mice, joysticks, keyboards, video capture devices, and speakers
- IEEE 1394 devices
- Still image devices
Installing, enabling/disabling, and changing network components, including:
- Network adapters and Plug and Play network interface controllers - For information about how to support installation of a network adapter driver without requiring a reboot, see "Tips for Specific Device Classes" later in this topic.
- Printers using a current HP-JetDirect card that uses TCP/IP - However, when installing a printer using an older HP-JetDirect card that uses the data link control (DLC) protocol, the system must be rebooted before the DLC protocol option appears in the list of available protocols when adding a local printer.
- Network protocols, including TCP/IP, Internet Packet Exchange/Sequenced Packet Exchange (IPX/SPX), NetBEUI, DLC, and AppleTalk
- Protocol binding order
- IPX frame type
- Network services, such as Simple Network Management Protocol (SNMP), Windows Internet Name Service (WINS), Dynamic Host Configuration Protocol (DHCP), and Remote Access Service (RAS)
- Point-to-Point Tunneling Protocol (PPTP) ports
- Internet Locator Service
- Settings, including default gateway, subnet mask, DNS server address, and WINS server address
- IP address if there is more than one network interface controller
- Resolution of IP address conflicts
- Static and DHCP IP address switching
- Asynchronous Transfer Mode (ATM) address of the ATMARP server (ATMARP was third-party software on Windows NT 4.0)
- Dial-Up Server on a system with Dial-Up Client installed and RAS already running
- TAPI providers
- Changes to MacClient network adapters and view shared volumes
- Server name for AppleTalk workstations
- File and Print Services for NetWare
- Gateway Services for NetWare
This section provides guidelines for designing drivers, INFs, and custom installation applications to install drivers without rebooting the system.
Vendors should examine all installation routines to make sure they do not attempt to replace certain files with new files that have the same names, such as the following:
- Protected system files. System-file protection prevents system files from being copied over during installation of applications and drivers. Vendors should make sure they are appropriately addressing issues related to system-protected files under Windows 2000.
- Shared, in-use DLLs. Shared, in-use DLLs that cannot be halted will not be updated until after the next reboot. Vendors should not replace such DLLs, or should use side-by-side components wherever possible.
- Class installers and coinstallers. A class installer or coinstaller cannot be replaced with a file that has the same name. Vendors should use different file names when updating or replacing class installers or coinstallers, and should not update any system-supplied class installers.
Driver INF files should not include a Reboot= or Restart= directive and should avoid setting certain flags in CopyFiles= directives, as described in this section.
Reboot= or Restart= directive. A [DDInstall] section in an INF file for a Plug and Play device should not include a Reboot= or Restart= directive. These directives are provided for compatibility with Windows 95/98 and should not be used for Windows 2000, Windows XP, and later versions of the operating system. If one of these entries is present, the operating system is forced to reboot when the device is installed, whether the reboot is necessary. Let the Plug and Play Manager determine whether the system needs to be rebooted rather than specifying these directives.
CopyFiles= directive. A CopyFiles= directive can use hexadecimal flags to control how (or whether) a particular source file is copied to the destination. The following flags influence whether the system prompts for a reboot as a result of copying the file:
- 0x00000008 (COPYFLG_FORCE_FILE_IN_USE) - This flag prohibits copying over an existing file of the same name if it is currently open. Instead, it copies the given source file with a temporary name so that it can be renamed and used when the next reboot occurs. If this flag is set, the user is prompted to reboot if the file is in use.
- 0x00001000 (COPYFLG_REPLACE_BOOT_FILE) - This flag should be used only for files that are required by the system loader. The system will always prompt the user to reboot the system when replacing a boot file.
For information about these and other INF directives, see "INF File Sections and Directives" in the Windows DDK.
A custom device installation application should not use RunOnce registry entries to launch setup programs because processing of such entries can occur at any time, not necessarily after an intervening reboot. In contrast, RunOnce entries that are created by an INF during device installation are run immediately, without an intervening reboot.
A custom device installation application should call the
UpdateDriverForPlugAndPlayDevices function to install a new device or update the driver for an existing device. The optional bRebootRequired parameter of UpdateDriverForPlugAndPlayDevices indicates the need for a reboot:
- If bRebootRequired is NULL (the default) and the Plug and Play Manager determines that reboot is necessary, the system will prompt the user for a reboot after installing the related driver files.
- If bRebootRequired is a valid pointer, this function returns its reboot status through this parameter and it is the callers responsibility to prompt for a reboot if one is needed.
For information, see "Writing a Device Installation Application" in the Windows DDK.
This section provides tips for avoiding unnecessary reboots when installing devices of certain classes.
Display Drivers. The Windows DDK provides a tool that allows driver developers to dynamically reload a display driver without rebooting. This tool, called Newdisp.exe, accelerates display driver testing during development by making reboots less necessary when updating display driver code. Newdisp.exe does not currently cause a video miniport to be reloaded; if a video miniport is changed, the system must be rebooted to install and test it.
For information, see "NewDisp: Dynamic Reload of a Display Driver" in the Windows DDK.
Network Drivers. Use INetCfgPnpReconfigCallback, so that a user will not be required to reboot the operating system to cause configuration changes to take effect in the driver. A notify object can call SendPnpReconfig within its implementation of the INetCfgComponentControl::ApplyPnpChanges method to send configuration information to the driver of the network component that owns the object. SendPnpReconfig provides the notify object with a possible mechanism to send data to the driver. Calling SendPnpReconfig is optional for the notify object but recommended to avoid requiring a user to reboot the operating system before configuration changes take effect.
For information, see "Configuring the Components Driver" in the Windows DDK.
Microsoft DirectMusic Synths. Implement a software synth in user mode, rather than kernel mode, to avoid reboots and gain other benefits.
For information, see "User Mode versus Kernel Mode" in the Windows DDK.
See "Guidelines for Creating Side-by-Side Assemblies" in the Microsoft Platform SDK for information about how to install applications without rebooting.
To install utilities and other software that might accompany a device driver, use Windows Installer, as described in the Microsoft Platform SDK.
The Microsoft Windows Installer can determine when a reboot of the system is necessary and automatically prompt the user to reboot at the end of the installation. For example, the installer automatically prompts for a reboot if it needs to replace any files that are in use during the installation.
Installation package authors can suppress reboots by using the InstallValidate action in sequence tables. If the InstallValidate action detects the installation of a file that is in use, it displays the Files In Use dialog box, giving users the opportunity to shut down the process using the file and avoid rebooting the system.
The InstallValidate action also logs information about the file. The verbose logging option (MsiEnableLog with INSTALLLOGMODE_VERBOSE) logs additional information, such as the reason the file was in use.
For information about how to suppress reboots when using Windows Installer, see "System Reboots" in the Platform SDK.
To avoid unnecessary reboots when installing applications:
- Use side-by-side components whenever possible.
- Do not attempt to replace system-protected DLLs with different versions.
- Use the Microsoft Windows Installer with the InstallValidate action to suppress reboots that would otherwise occur when installing files in use by another application.
Hardware manufacturers and application software developers should design their products to avoid unnecessary reboots.
To avoid unnecessary reboots when installing a new hardware component:
- Do not include Reboot= or Restart= directives in INF [DDInstall] sections.
- Call UpdateDriverForPlugAndPlayDevices in a custom installation program to install a new device.
- Do not use RunOnce registry entries to spawn setup programs in custom installation programs.