|
|
|
[DDInstall.Services]
AddService=ServiceName,[flags],service-install-section[,
event-log-install-section[,[EventLogType][,EventName]]]
...
An AddService directive is used within an INF DDInstall.Services section or INF DefaultInstall.Services section. It specifies characteristics of the services associated with Windows 2000 or later drivers, such as how and when the services are loaded, and any dependencies on other underlying legacy drivers or services. Optionally, this directive also sets up event-logging services for the device.
This directive is not used in exclusively Windows 9x/Me INF files. It also is not used in INF files that install devices that do not require any drivers, such as modems or display monitors..
The system-defined and case-insensitive extensions can be inserted into a DDInstall.Services section containing an AddService directive in cross-OS and/or cross-platform INF files to specify platform-specific or OS-specific installations. For information about how to use the system-defined .nt, .ntx86, and .ntia64 extensions, see Creating INF Files for Multiple Platforms and Operating Systems.
Each INF-writer-created section name must be unique within the INF and must follow the general rules for defining section names. These rules are described in General Syntax Rules for INF Files.
An AddService directive must reference a named service-install-section elsewhere in the INF file. Each such section has the following form:
[service-install-section]
[DisplayName=name]
[Description=description-string]
ServiceType=type-code
StartType=start-code
ErrorControl=error-control-level
ServiceBinary=path-to-service
[StartName=driver-object-name]
[AddReg=add-registry-section[, add-registry-section] ...]
[DelReg=del-registry-section[, del-registry-section] ...]
[BitReg=bit-registry-section[,bit-registry-section] ...]
[LoadOrderGroup=load-order-group-name]
[Dependencies=depend-on-item-name[,depend-on-item-name]
[Security="security-descriptor-string"]...]
Each service-install-section must have at least the ServiceType, StartType, ErrorControl, and ServiceBinary entries as shown here, but the remaining entries are optional.
This string gives the user more information about the service than the DisplayName. For example, the DisplayName might be something like "DHCP Client" and the Description might be something like "Manages network configuration by registering and updating IP addresses and DNS names".
The description-string should be long enough to be descriptive but not so long as to be awkward. If a description-string contains any %strkey% tokens, each token can represent a maximum of 511 characters. The total string, after any string token substitutions, should be no longer than 1024 characters. Most strings will be shorter.
A device-dedicated application supplied when installing the device would be classified as either of SERVICE_WIN32_OWN_PROCESS (specified as 10 or 0x00000010 in the INF) or SERVICE_WIN32_SHARE_PROCESS (specified as 20 or 0x00000020 in the INF).
A highest level network driver, such as a redirector, or a file system would be classified as SERVICE_FILE_SYSTEM_DRIVER by specifying 2 or 0x00000002 in its INF.
The SERVICE_xxxx constants are defined in wdm.h and ntddk.h.
This value must be used for drivers of devices required for loading the operating system.
This value should be used by PnP drivers that do device detection during initialization but are not required to load the system.
For example, a PnP driver that also can detect a legacy device should specify this value in its INF so that its DriverEntry routine will be called to find the legacy device, even if that device cannot be enumerated by the PnP Manager.
This value should never be used in the INF files for WDM or PnP device drivers.
This value should be used in the INF files for all WDM drivers of devices that are not required to load the system and for all PnP device drivers that are neither required to load the system nor engaged in device detection.
This value can be used to temporarily disable the driver services for a device, but a device/driver cannot be installed if this value is specified in the service-install section of its INF file.
For additional information about StartType, see Specifying Driver Load Order.
The dirid number is either a custom directory identifier or one of the system-defined directory identifiers described in Using Dirids. The given filename specifies a file already transferred (see the INF CopyFiles directive) from the source distribution media to that directory on the target machine.
In general, this entry is unnecessary for devices with WDM drivers or for exclusively PnP devices, unless there are legacy dependencies on such a group. However, this entry can be useful if device detection is supported by loading a group of drivers in a particular order.
For additional information about LoadOrderGroup, see Specifying Driver Load Order.
If the depend-on-item-name specifies a service, the service that must be running before this driver is started. For example, the INF for the system-supplied Win32 TCP/IP print services depends on the support of the underlying (kernel-mode) TCP/IP transport stack. Consequently, the INF for the TCP/IP print services specifies this entry as Dependencies =TCPIP.
A depend-on-item-name can specify a load order group on which this device/driver depends. Such a driver is started only if at least one member of the specified group has been started. Precede the group name with a plus sign (+). For example, the system RAS services INF might have an entry like Dependencies = +NetBIOSGroup,RpcSS, which lists both a load-order group and a service.
For more information about specifying security descriptors, see Creating Secure Device Installations.
The operating system loads drivers according to the service-install-section StartType value, as follows:
For additional information about Dependencies, see Specifying Driver Load Order.
An AddService directive also can reference an event-log-install-section elsewhere in the INF file. Each such section has the following form:
[event-log-install-section]
AddReg=add-registry-section[, add-registry-section]...
[DelReg=del-registry-section[, del-registry-section]...]
[BitReg=bit-registry-section[,bit-registry-section]...]
...
For a typical device/driver INF file, the event-log-install-section uses only the AddReg directive to set up an event-logging message file for the driver. An HKR specification in an add-registry-section designates the HKLM\System\CurrentControlSet\Services\
EventLog\EventLogType\EventName registry key. This event-logging add-registry-section has the following general form:
[drivername_EventLog_AddReg]
HKR,,EventMessageFile,0x00020000,"path\IoLogMsg.dll;path\driver.sys"
HKR,,TypesSupported,0x00010001,7
In particular, the section adds two value entries in the registry subkey created for the device/driver, as follows:
%%SystemRoot%%\System32\IoLogMsg.dll, and %%SystemRoot%%\System32\drivers\driver.sys, unless the driver binary was copied into another subdirectory on the target machine, as specified in the INF DestinationDirs section or in a section referenced by an INF CopyFiles directive.
An event-log-install-section also can use the DelReg directive to remove a previously installed event-log message file, by explicitly deleting the existing EventMessageFile and TypesSupported value entries, if a driver binary is being superseded by a newly installed driver. (See also INF DelService directive.)
While a BitReg directive also is valid within an INF-writer-defined event-log-install-section, it is almost never used, because the standard value entries for device driver event logging are not bitmasks.
This example shows the service-install and event-log-install sections referenced by the AddService directive as already shown earlier in the example for DDInstall.Services.
[sermouse_Service_Inst]
DisplayName = %sermouse.SvcDesc%
ServiceType = 1 ; = SERVICE_KERNEL_DRIVER
StartType = 3 ; = SERVICE_DEMAND_START
ErrorControl = 1 ; = SERVICE_ERROR_NORMAL
ServiceBinary = %12%\sermouse.sys
LoadOrderGroup = Pointer Port
[sermouse_EventLog_Inst]
AddReg = sermouse_EventLog_AddReg
[sermouse_EventLog_AddReg]
HKR,,EventMessageFile,0x00020000,"%%SystemRoot%%\System32\IoLogMsg.dll;
%%SystemRoot%%\System32\drivers\sermouse.sys"
;
; Preceding entry on single line in INF file. Enclosing quotation marks
; prevent the semicolon from being interpreted as a comment.
;
HKR,,TypesSupported,0x00010001,7
[mouclass_Service_Inst]
DisplayName = %mouclass.SvcDesc%
ServiceType = 1 ; = SERVICE_KERNEL_DRIVER
StartType = 1 ; = SERVICE_SYSTEM_START
ErrorControl = 1 ; = SERVICE_ERROR_NORMAL
ServiceBinary = %12%\mouclass.sys
LoadOrderGroup = Pointer Class
[mouclass_EventLog_Inst]
AddReg = mouclass_EventLog_AddReg
[mouclass_EventLog_AddReg]
HKR,,EventMessageFile,0x0002000,"%%SystemRoot%%\System32\IoLogMsg.dll;
%%SystemRoot%%\System32\drivers\mouclass.sys"
HKR,,TypesSupported,0x00010001,7
; ...
[Strings]
; ...
sermouse.SvcDesc = "Serial Mouse Driver"
mouclass.SvcDesc = "Mouse Class Driver"
The example in the reference for the DDInstall.HW section, described earlier, also shows some service-install sections referenced by the AddService directive to set up PnP upper-filter drivers.
AddReg, BitReg, CopyFiles, DDInstall.HW, DDInstall.Services, DelReg, DelService, DestinationDirs, Strings