Rally Vertical Pairing device drivers

Updated: July 29, 2013

After Windows has configured a Rally device's Wi-Fi settings and has paired with the device, Windows detects that the device is online and starts the Plug and Play process. This process installs and loads the appropriate device drivers for the device. Plug and Play determines which device driver is the most appropriate driver for the device by examining drivers that are included with Windows, drivers that were previously installed on the system, and drivers on Windows Update. A Rally device that uses drivers that are included with Windows or drivers that are available on Windows Update does not require the user to install software from a CD-ROM or software that was manually downloaded from the device manufacturer's web site.

This information applies for the following operating systems:

  • Windows Server 2008 R2
  • Windows 7

Default pass-through driver

Many PnP-X devices do not require the functionality that a device driver provides. For example, applications that communicate with a DLNA media library by using the UPnP protocol do not use a driver to communicate with the device. However, Rally Vertical Pairing devices require a driver to be loaded so that Windows can notify applications and services about the arrival of the device and any associated interfaces.

For devices that do not require the functionality that a device driver provides, Windows includes a passthrough driver, Umpass.sys. This driver has no functionality other than support for loading and unloading. It can be used with any device that just must provide notification to applications and services that it has arrived. If a Rally Vertical Pairing device does not require a device driver, it should use the Umpass.sys driver.

You can use the Umpass.sys passthrough driver for your device either by specifying a well-known compatible ID value for another device or class of device that uses Umpass.sys or by specifying a hardware ID and providing an INF file for your device that specifies the Umpass.sys driver as the driver to use for your device. If your device does not implement any functionality that is compatible with any of the well-known compatible ID values, it can specify a compatible ID of GenericUmPass. In this situation, Windows loads the passthrough driver without any additional support, such as defining interfaces. This is useful because it eliminates the requirement to provide a specialized INF file for a device that requires no special driver or software support. For more information about how to specify compatible ID values, see XML element details.

INF file

The code example that is shown later in this section shows a sample device driver INF file for a PnP-X device. It provides the driver installation information for a device with a hardware ID of VEN_999&DEV_22&SUBSYS_01.

If you modify this sample INF file for use with your device, you must prefix the device's hardware ID or compatible ID value with UMB\. This indicates to Windows that the ID is related to PnP-X. If an INF file does not include this prefix, PnP-X does not recognize the device and the device cannot be installed. The example INF file does this for the sample VEN_999&DEV_22&SUBSYS_01 device, but if you add hardware IDs or compatible IDs to the file for your device, you must ensure that you do this for every ID.

Many networked devices, such as DLNA media devices, use functionality that is built into Windows 7. For such a device, you simply must specify the compatible ID for the built-in functionality. For example, for a DLNA renderer device you can simply specify a compatible ID of MS_DigitalMediaDeviceClass_DMR_V001 in the device’s UPnP or DPWS metadata. This results in Plug and Play using the DLNA INF file that is included with Windows. In this situation, you are not required to provide an INF file for your device.

However, for devices that expose functionality that is not built into Windows, you must provide an INF file for the device. The INF file must specify a device driver to use for the device. If the device uses only the Umpass.sys passthrough driver that is included with Windows, no INF file is required. In this situation, the device should specify a compatible ID value of GenericUMPass in the device’s PnP-X metadata.

Modify the sample INF file

The sample INF file shows how an INF file for a PnP-X device might look. Note that this sample is incomplete as shown. The following items must be modified as appropriate for a particular device:

In the [Version] section:

  • Class: Specify the actual device class for your device, for example, WSDPrintDevice.
  • ClassGuid: Specify the GUID that represents the device class that was specified for the Class item, for example, {c30ecea0 11ef 4ef9 b02e 6af81e6e65c0}.
  • VersionStamp: Specify a date/version stamp for the INF file in the following format: mm/dd/yyyy,version. For example, 12/08/2006,

In each [Device.NTxxxx.6.y] section:

  • Specify any hardware ID and/or compatible ID values for your device.
  • Only specify compatible ID values in your INF file if you created them. Otherwise, other INF files define them.
  • Ensure that all hardware ID and compatible ID values are prefixed with UMB\ as previously discussed. For example, use UMB\VEN_999&DEV_22&SUBSYS_01 to specify VEN_999&DEV_22&SUBSYS_01 for a hardware ID.

In the [Device_Install_Win7.NT.HW.AddReg] and [Device_Install_Vista.NT.HW.AddReg] sections:

  • Replace the GUID value with a valid interface GUID value. For example, for an audio card kernel-streaming interface, you would specify the following GUID: {6994ad04 93ef 11d0 a3cc 00a0c9223196}. Multiple entries can be specified to associate a device with multiple interfaces. If no interfaces should be associated with the device, remove all lines in these sections.

In the [String] section:

  • Company: Specify the manufacturer of the device, for example, Microsoft.
  • ClassName: Specify a friendly name for the device class, for example, WSD Print Provider.
  • Device.DeviceDesc: Specify a friendly name that describes the device, for example, WSD Print Device.

In the Device Class Section:

This section is required only if you are creating a new device class. If you reference an existing device class (that is, you use a predefined compatible ID):

  • Remove the [ClassInstall32] section.
  • Remove the [Device_ClassReg] section.
  • Remove the ClassName entry in the [Strings] section.

If you define a new device class (that is, there is no known compatible ID value for your device class):

  • Uncomment the [ClassInstall32] section by removing the semicolon at the beginning of each line in the section.
  • Uncomment the [Device_ClassReg] section by removing the semicolon at the beginning of each line in the section.
  • Modify the ClassName item in the [Strings] section to specify a friendly name for the device class.
  • Modify the Class and ClassGuid values in the [Version] section to specify a unique class name and GUID for the device class.

Device Driver INF File

; Copyright (c) Microsoft Corporation.  All rights reserved.
; Description:
;    INF SAMPLE for PnP-X Devices

Signature = "$WINDOWS NT$"
Provider  = %Company%            ; Manufacturer of this device
Class     = "MyDeviceClass"      ; Provide a class for your device... 
                                 ;      ...predefined or new.
ClassGuid = {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}    
DriverVer = 02/05/2009,

; =====================  Device Class Section  =======================
; This section is required if you are defining a new Class.
; If the device class has not been defined then uncomment this
; section and modify the [Strings] section’s ClassName value.

; [ClassInstall32]
; Addreg=Device_ClassReg

; [Device_ClassReg]
; HKR,,,,%ClassName%            ; Friendly name for this device class
; HKR,,SilentInstall,,1         ; Specify a silent installation
; HKR,,Icon,,"-52"              ; Icon: generic network device

; ========================  Device Section  ==========================

; Should list all device manufacturer/model combinations here
; Note: next line wraps but should be only one line
%Company%=Device, NTx86.6.0, NTamd64.6.0, NTia64.6.0, NTx86.6.1, NTamd64.6.1, NTia64.6.1 

; Model Device Description Install Section       HWIDs, Compatible IDs
; ------------------------ --------------------  ---------------------

; Model specific install section list for Windows Vista x86/amd64/ia64
%Device.DeviceDesc% = Device_Install_Vista, UMB\VEN_999&DEV_22&SUBSYS_01

%Device.DeviceDesc% = Device_Install_Vista, UMB\VEN_999&DEV_22&SUBSYS_01

%Device.DeviceDesc% = Device_Install_Vista, UMB\VEN_999&DEV_22&SUBSYS_01

; Model specific install section list for Windows 7 x86/amd64/ia64
%Device.DeviceDesc% = Device_Install_Win7, UMB\VEN_999&DEV_22&SUBSYS_01

%Device.DeviceDesc% = Device_Install_Win7, UMB\VEN_999&DEV_22&SUBSYS_01

%Device.DeviceDesc% = Device_Install_Win7, UMB\VEN_999&DEV_22&SUBSYS_01

; ===================  Install Sections: Windows 7 ===================


; Section to add device-specific information to the registry   
; and declare an AddReg section

;Add the registry entries                                               
HKR,,InterfaceGUIDs,0x10000, "{yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy}"  

; Set up the UMPass service for the device


; ====================  Install Sections: Windows Vista  =============

; Install section for Windows Vista compatible .Services 
; section, below.
; For Windows 7 and later, include all sections from Umpass.inf, 
; as above.

; Section to add device-specific information to the registry   
; and declare an AddReg section

;Add the registry entries                                               
HKR,,InterfaceGUIDs,0x10000, "{yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy}"  

; Services section compatible with installing Umpass.sys on 
; Windows Vista.
; For Windows 7 and later, include all sections from Umpass.inf, 
; as above.
AddService = UMPass, 0x00000002, UMPassService_Install

DisplayName    = "Microsoft UMPass Driver" ; Service Friendly Name 
ServiceType    = 1                         ; SERVICE_KERNEL_DRIVER
StartType      = 3                         ; SERVICE_DEMAND_START 
ErrorControl   = 1                         ; SERVICE_ERROR_NORMAL
ServiceBinary  = %12%\umpass.sys
LoadOrderGroup = Extended Base

; =======================  Strings Section  =========================
; Strings that are referenced throughout the INF
Company           = "Microsoft"
Device.DeviceDesc = "My Device Name"
ClassName         = "My Device Class Name"

For more information about INF files, see INF Files and INF File Sections and Directives.

For more information about device driver packages, see “Driver Packages” in the Windows Driver Kit (WDK). For more information about device driver installation, see Device and Driver Installation and ”Device and Driver Installation” in the WDK.

Driver and software configuration

For certain devices, it is important to configure the device when the device drivers for the device are installed. In this situation, the configuration of a device is typically performed by a device co-installer or by post-installation actions. This configuration step is optional and applies only if a device uses a device driver package that includes an INF file. This section discusses the different techniques that a driver package can use to install and/or configure software and device settings.


When Windows installs a device driver for a device, it can call a DLL that is included in the driver package. The DLL exposes a function that can run any code that is required to correctly set up the system. This DLL is known as a co-installer.

A co-installer can perform the work of registering COM classes, shell shortcut menu handlers, and AutoPlay handlers, or other similar tasks.

A co-installer is a way to extend device driver installation to include device and/or software setup. A co-installer is run before the installation of the device is completed. Therefore, the code is run before notification about the arrival of the device is sent to applications or services.

A co-installer runs in an administrative process with elevated credentials. Therefore, you must ensure that a co-installer for your device does not accidentally configure Windows incorrectly. As a security precaution, a co-installer should not use any network resources because it runs with elevated credentials.

A co-installer should not display a user interface. If the configuration of your device requires user interaction, use a finish-install action or an AutoPlay handler.

Note  Co-installers are not recommended for printers because they can interfere with Point and Print installations.

For more information about how to write a co-installer, see ”Writing a Co-installer” in the WDK.

Finish-install actions

Sometimes it is useful to run an application, such as a device setup and configuration application, immediately after a device is installed. For example, after successful installation of a scanner you might want to run an application that verifies the operation of the scanner by performing a test scan.

You can run applications after a device is installed by using a finish-install action. After Windows completes the device installation process, it runs a command to finish the installation if such a finish-install action is registered.

A finish-install action runs in an administrative process with elevated credentials. Therefore, you must ensure that a finish-install action for your device does not accidentally configure Windows incorrectly. As a security precaution, a finish-install action should not use any network resources because it runs with elevated credentials.

For more information about finish-install actions, see Finish-Install Actions and ”Finish-Install Actions” in the WDK.

AutoPlay handlers

The AutoPlay version 2 architecture binds software with a device interface. When Windows detects a device and loads a device driver for the device, any device interface that is bound to the device driver is enabled. Windows then sends notifications to any registered applications or services about the arrival of the device interface. AutoPlay receives these notifications and runs any software that is registered for the device interface. You can use this feature to have Windows automatically run software for your PnP-X–enabled device when it is detected.

For example, a PnP-X-enabled network picture frame can define a device interface in its INF file. After the user pairs Windows with the picture frame, Windows detects the device and then installs an appropriate driver from Windows Update. During the driver installation process, a co-installer installs the picture frame’s photo synchronization software and registers an AutoPlay handler. The driver is loaded after the co-installer process is complete. After the driver is loaded, Windows sends a notification to AutoPlay about the arrival of the device interface. AutoPlay receives this notification and runs the picture frame’s photo synchronization software that retrieves information from the device, such as its UUID and IP address, and then synchronizes photos.

AutoPlay handlers are run by using the credentials of the currently logged-on user. Therefore, it is safe for an AutoPlay handler to display a user interface and use network resources. However, because AutoPlay handlers do not run with elevated credentials, they have limited system configuration capabilities.

You can register an AutoPlay handler by using a co-installer that runs during device installation. Or, a user can register AutoPlay handlers at any time by using software on a CD-ROM, downloaded from the Internet, or from other sources.

For more information about how to create and register AutoPlay handlers, see AutoPlay in Windows XP: Automatically Detect and React to New Devices on a System.

Related topics

Using Windows Rally Vertical Pairing to automatically install Wi Fi devices



Send comments about this topic to Microsoft