Portable device installation_considerations

Portable Device Installation Considerations
App Note
Author: Windows Media Devices Group
Version: 1.1

1 TABLE OF CONTENTS
1 TABLE OF CONTENTS............................................................................................................................................2
2 INTRODUCTION.......................................................................................................................................................4
2.1 AUDIENCE AND DISCLAIMER...................................................................................................................................4
2.2 ACRONYMS.............................................................................................................................................................4
2.3 SCOPE.....................................................................................................................................................................4
2.3.1 Out of scope.....................................................................................................................................................4
Devices with proprietary communications stack.....................................................................................................................4
3 OS DESCRIPTOR ......................................................................................................................................................5
3.1 INTRODUCTION........................................................................................................................................................5
3.2 COMPATIBILITY WITH USB CLASS ID......................................................................................................................5
3.2.1 Supported OSs.................................................................................................................................................5
3.2.2 Non Supported OSs..........................................................................................................................................5
3.3 DEVICE REQUIREMENTS..........................................................................................................................................6
3.3.1 String Descriptor.............................................................................................................................................6
3.3.1.1 Structure of the OS String...........................................................................................................................................6
3.3.1.2 Retrieving the OS String Descriptor.............................................................................................................................6
3.3.1.3 Verifying the Integrity of the OS Descriptor.................................................................................................................7
3.3.1.4 Microsoft OS String Descriptor Constraints.................................................................................................................7
3.3.2 Feature Descriptor...........................................................................................................................................7
3.3.2.1 Retrieving an OS Feature Descriptor...........................................................................................................................8
3.3.2.2 Microsoft OS Feature Descriptor Constraints...............................................................................................................8
3.4 OS SUPPORT...........................................................................................................................................................9
3.5 STRUCTURE OF THE MTP FEATURE DESCRIPTOR...................................................................................................10
3.5.1 Header Section...............................................................................................................................................10
3.5.2 Function Section............................................................................................................................................10
3.6 EXTENDED DEVICE CLASS IDENTIFICATION...........................................................................................................11
3.6.1 Device Icons..................................................................................................................................................11
3.6.1.1 Custom vendor-provided icons..................................................................................................................................11
3.6.1.2 Device class icons....................................................................................................................................................11
3.6.1.3 Generic device icon..................................................................................................................................................11
3.6.2 Device Classes...............................................................................................................................................11
3.6.2.1 Subcomponent identifiers.........................................................................................................................................11
4 DOWN LEVEL SOLUTIONS..................................................................................................................................12
4.1 WMDM9 MTP SERVICE PROVIDER......................................................................................................................12
4.2 DUAL (MSC+MTP) MODE DEVICES.....................................................................................................................12
4.2.1 MSC Identifier (usbstor.sys)............................................................................................................................12
4.2.2 MTP Identifier (wpdusb.sys or similar component)..........................................................................................14
4.3 SAFE BOOT MODE.................................................................................................................................................14
4.4 DEVICE REQUIREMENTS........................................................................................................................................14
4.4.1 VID/PID Considerations................................................................................................................................14
5 END USER EXPERIENCE......................................................................................................................................15
5.1 DEVICE SUPPORT...................................................................................................................................................15
5.1.1 Device Type 1: MTP Device with Microsoft OS Descriptor ID (USBMS_COMP_MTP) and with backward-
compatible PTP class ID (Class_06&SubClass_01&Prot_01): ...............................................................................15
5.1.2 Device Type 2: MTP Device without Microsoft OS Descriptor ID and with backward-compatible PTP class ID:
..............................................................................................................................................................................15
5.1.3 Device Type 3: MTP Device without Microsoft OS Descriptor ID and without backward-compatible PTP class
ID: ........................................................................................................................................................................15
MICROSOFT CONFIDENTIAL

5.1.4 Device Type 4: Dual Mode MTP/MSC Device with Microsoft OS Descriptor ID and with backward-compatible
MSC class ID: .......................................................................................................................................................15
5.2 SUPPORTED OSS....................................................................................................................................................16
5.2.1 Windows Media Player 10 (WMP10) Installed................................................................................................16
5.2.1.1 Device Type 1..........................................................................................................................................................16
5.2.1.2 Device Type 2.........................................................................................................................................................16
5.2.1.3 Device Type 3..........................................................................................................................................................16
5.2.1.4 Device Type 4..........................................................................................................................................................16
5.2.2 WMP10 Not Installed.....................................................................................................................................17
5.2.2.1 Device Type 1..........................................................................................................................................................17
5.2.2.2 Device Type 2.........................................................................................................................................................17
5.2.2.3 Device Type 3..........................................................................................................................................................17
5.2.2.4 Device Type 4..........................................................................................................................................................18
5.3 NON-SUPPORTED OSS............................................................................................................................................18
5.3.1 WMP10 (or MTP Drivers) Installed................................................................................................................18
5.3.1.1 Device Type 1..........................................................................................................................................................18
5.3.1.2 Device Type 2.........................................................................................................................................................18
5.3.1.3 Device Type 3..........................................................................................................................................................19
5.3.1.4 Device Type 4..........................................................................................................................................................19
5.3.2 WMP10 (or MTP Drivers) Not Installed.........................................................................................................19
Existing products................................................................................................................................................................19
5.3.2.1 Device Type 1..........................................................................................................................................................19
5.3.2.2 Device Type 2.........................................................................................................................................................20
5.3.2.3 Device Type 3..........................................................................................................................................................20
5.3.2.4 Device Type 4..........................................................................................................................................................20
6 BUILDING A .INF FILE...........................................................................................................................................21
7 INSTALL PROCESS................................................................................................................................................23
7.1 SUPPORTED OSS....................................................................................................................................................23
7.2 NON-SUPPORTED OS.............................................................................................................................................26
8 REFERENCES..........................................................................................................................................................28
8.1 OS DESCRIPTOR INFORMATION.............................................................................................................................28
8.2 DEVICE INSTALLATION GUIDELINES.......................................................................................................................28
8.3 WINDOWS DDK....................................................................................................................................................28
8.4 USB MASS STORAGE CLASS BULK-ONLY TRANSPORT..........................................................................................28

2 INTRODUCTION
2.1 Audience and Disclaimer
This document contains information for review by Microsoft’s internal teams and partners working with
Microsoft’s MTP technology. This is a draft proposal that is subject to broader review. As such this
document does not reflect a booked plan. This document and the subject matter herein is strictly
confidential and is to be disclosed only to people who have agreed to the terms in the MTP PK EULA.
2.2 Acronyms
• ID – Identifier
• MSC – Mass Storage Class
• MTP – Media Transfer Protocol
• PTP – Picture Transfer Protocol
• SP – Service Provider
• USB – Universal Serial Bus
• WMP – Windows Media Player
• WIA – Windows Imaging and Acquisition
2.3 Scope
This document is intended as a guide for those working with Microsoft’s MTP technology. MTP is an
extension to the industry standard PTP, which was developed to provide richer communications between
PCs and digital still cameras. The MTP extensions to PTP provide for similar rich communications
between PCs a wider variety of digital media devices (e.g. portable media players and cell phones).
To support MTP devices, Microsoft has developed a class driver that will provide improved stability and
true plug and play for all MTP devices. The class driver initially shipped with Windows™ Media Player 10.
It will also ship in future versions of Windows™.
Microsoft is currently in the process of obtaining a USB class ID for MTP devices. However, at the time
the first MTP devices were scheduled to ship, a class ID was not available. Without this class ID, the PC
has no way of automatically detecting that an MTP device has been connected and thus no way of
automatically installing the MTP class driver. Until a class driver is obtained and supported in the OS,
Microsoft is recommending that MTP device manufacturers use Microsoft’s proprietary OS descriptor
technology. This document outlines the impact on portable device manufacturers and end users, of using
the OS descriptor technology as a (temporary) replacement for a USB class ID for MTP capable devices.
It also discusses installation requirement scenarios based on different device/OS configurations.
2.3.1 Out of scope
Devices with proprietary communications stack
Devices that have their own proprietary communications stack are not part of the scope of this document.

3 OS DESCRIPTOR
The following information was gathered from various OS descriptor documents. More
information can be found in the USB FAQ on the Microsoft Web site.
3.1 Introduction
The Microsoft OS Descriptor is a tool that enables hardware vendors to include additional information in
their devices, which can be retrieved by a Microsoft OS Descriptor, enabled operating system. The
information that needs to be stored in the device will have to comply with the format of the feature
descriptors designed by Microsoft. No Feature Descriptor can be Defined or implemented without
Microsoft’s consent.
The Microsoft OS Descriptor is a term used to describe the information embedded in the device that can
be retrieved by a Microsoft OS Descriptor Enabled operating system. The format of the data must be in
alliance with the Feature Descriptors defined by Microsoft.
The Microsoft OS Descriptor is broken up into the following segments:
• One Microsoft OS String Descriptor
• One or more Microsoft OS Feature Descriptors.
The Microsoft OS String Descriptor is a special string that is embedded at a fixed string index. The
purpose of this string is to inform the operating system of the presence of the Microsoft OS Descriptor
along with additional information.
The Feature Descriptors are fixed format descriptors that have been defined and allocated by Microsoft.
3.2 Compatibility with USB Class ID
A device can have both a USB Class ID and an OS Descriptor.
3.2.1 Supported OSs
When a device with both a MS OS descriptor and a USB class ID connects to a PC with an OS that
supports an MS OS descriptor, the OS will give priority to the OS descriptor. In Windows Vista, if the
device does not report to be USB 2.0 in their device descriptor the OS descriptor will not be read.
3.2.2 Non Supported OSs
When a device with both a MS OS descriptor and a USB class ID connects to a PC with an OS that does
not support an MS OS descriptor, the OS will use the USB class ID.

3.3 Device Requirements
To support the OS descriptor, the device must implement the following:
3.3.1 String Descriptor
The Microsoft OS String Descriptor is a string that is stored at string index 0xEE. The format of this string
is well defined.
The Microsoft OS String Descriptor is used to achieve the following objectives:
• The presence of the Microsoft OS String Descriptor indicates to the operating system that the
device has information embedded in it, in the form of Microsoft OS Feature Descriptors.
• The Microsoft OS String Descriptor has an embedded Signature Field that is used to differentiate
it from random strings that might happen to be on a device at string index 0xEE.
• The Microsoft OS String Descriptor also has an embedded version number that allows for future
revisions of the Microsoft OS Descriptor.
There will only be one Microsoft OS String Descriptor stored on the device. The following sections narrate
the structure of the Microsoft OS String Descriptor and its retrieval procedure.
3.3.1.1 Structure of the OS String
The structure of the string descriptor is specified below.
Field Length
(Bytes)
Value Description
bLength 1 0x12 Length of the descriptor
bDescriptorType 1 0x03 String Descriptor
qwSignature 14 ‘MSFT100’ Signature field
(4D00530046005400310030003000)
bMS_VendorCode 1 Vendor Code Vendor code to fetch other OS
Feature Descriptors
bPad 1 0x00 Pad field
Table 1: Structure of the Microsoft OS String Descriptor
The structure of the Microsoft OS String Descriptor is fixed for version 1.00 and has an overall length of
18 bytes. The version number of the Microsoft OS String Descriptor is listed in the qwSignature field.
The information stored in the bMS_VendorCode field must be a single byte value. It will be used to
retrieve Microsoft OS Feature Descriptors, and this byte value is used in the bmRequest field in section
3.1.
3.3.1.2 Retrieving the OS String Descriptor
To retrieve the information stored in the string, a standard GET_DESCRIPTOR request must be issued to
the device. The format of the request is specified below.
bmRequestType bRequest wValue wIndex wLength Data
1000 0000B GET_DESCRIPTOR 0x03EE 0x0000 0x12 Returns the
string.

Table 2: Standard Get_Descriptor String Request
The bmRequestType field is a bitmap composed of three parts – direction of data transfer, descriptor
type, and recipient. As per the Universal Serial Bus Specifications, the value of bmRequestType is set to
1000 0000b (0x80).
The bRequest field should be set to a standard GET_DESCRIPTOR request.
For a GET_DESCRIPTOR request, the wValue field is split into two parts. The high byte stores the
descriptor type and the low byte stores the descriptor index. To retrieve the Microsoft OS String
Descriptor, the high byte should be set to retrieve a string descriptor, hence 0x03. Since the Microsoft OS
String Descriptor is always stored at index 0xEE, this string index should be stored in the lower byte of the
wValue field.
The wIndex is used to store the Language ID, but it must be set to zero for a Microsoft OS String
Descriptor.
The wLength field is used to indicate the length of the string descriptor to be retrieved. The device should
respond to any valid range from 0x02-0xFF.
If a device does not have a valid descriptor at the corresponding address (0xEE), it will respond with a
Request Error/Stall. Devices that do NOT respond with a stall, a single-ended Zero reset will be issued to
the device (to recover it, if it should go into an unknown state).
3.3.1.3 Verifying the Integrity of the OS Descriptor
Since vendors are allowed to use any string ID to store information, the operating system must verify that
the string stored in index 0xEE is indeed the Microsoft OS String Descriptor. To verify this, the following
tests will be conducted. Failure of either will inhibit retrieval of the Microsoft OS Feature Descriptors.
• If a vendor stores a string in index location 0xEE, the operating system will retrieve the string and
query it to see if it is the Microsoft OS String. This can be verified by comparing the signature
field in the string to the signature field entry specified above. A mismatch would prevent further
parsing of the string.
• The second test will include a verification of the length of the string based on the version number
specified in the signature field. The version number specified (in the string “MSFT100”) is 1.00.
This corresponds to an 18-byte string descriptor.
3.3.1.4 Microsoft OS String Descriptor Constraints
The following constraints apply to Microsoft OS String Descriptors and its retrieval:
• To store information in compliance with the Microsoft OS Descriptor specification, the device
must have one and only on Microsoft OS String Descriptor that is in compliance with the
information outlined in .
• No Microsoft OS Feature Descriptors will be retrieved from the device if it fails to comply with
section 3.3.1.3.
• A device vendor is free to use any value in the bMS_VendorCode field in the Microsoft OS String
Descriptor.
3.3.2 Feature Descriptor
A Feature Descriptor is a fixed format descriptor that has been defined for a specific purpose.

3.3.2.1 Retrieving an OS Feature Descriptor
To retrieve a Microsoft OS Feature Descriptor, a special GET_MS_DESCRIPTOR request needs to be
issues to the device. The format of the request is specified below.
bmRequestType bRequest wValue wIndex wLength Data
1100 0000b GET_MS_DESCRIPTOR X Feature
Index
Length Returns
descriptor
Table 3: Standard Device Request format
The bmRequestType field is a bitmap composed of three parts – direction of data transfer, descriptor
type, and recipient – and is in accordance with the Universal Serial Bus Specification Document. The
Microsoft OS Feature Descriptor is a vendor specific descriptor and the direction of data transfer is from
the device to the host. Hence the value of bmRequestType is set to 1100 0000b (0xC0).
The bRequest Field is used to indicate the format of the request. In order to retrieve a Microsoft OS
Feature Descriptor, the bRequest field should be populated with a special GET_MS_DESCRIPTOR byte.
The value of this byte is indicated by the bMS_VendorCode, which is retrieved from the Microsoft String
Descriptor. Refer to section 3.3.1.2, which refers to the retrieval of the Microsoft OS String Descriptor.
The wValue field is put to special use and is broken up in to a high byte and a low byte. The high byte will
be used to store the interface number. This is essential for storing Feature Descriptors on a per interface
basis, especially for composite devices, or devices with multiple interfaces. In most cases, interface 0 will
be used. The low byte will be used to store a page number. This feature prevents descriptors from having
a size boundary of 64KB (a limit set by the size of the wLength field). A descriptor will be fetched with the
page value initially set to zero. If a full descriptor (size is 64KB) is received, the page value will be
incremented by one and the request for the descriptor will be sent again (this time with the incremented
page value). This process will repeat till a descriptor of size less than 64KB is received. Note that the
maximum number of pages is 255, placing a limit of 16MB on the descriptor size.
The wIndex field will store the Feature index number for the Microsoft OS Feature Descriptor being
retrieved. Microsoft will maintain this list of Microsoft OS Feature Descriptors and indexes. To learn more
about Microsoft OS Feature Descriptors refer to the supplementary document titled “Supported Microsoft
Feature Descriptors”.
The wLength field specifies the length of the descriptor to be fetched. If the descriptor is longer than the
number of bytes stated in the wLength field, only the initial bytes of the descriptor are returned. If it is
shorter than the value specified in the wLenght field, a short packet is returned.
If a particular OS descriptor is not present, the device will issue a Request Error or stall.
3.3.2.2 Microsoft OS Feature Descriptor Constraints
The following constraints apply to Microsoft OS Feature Descriptors and their retrieval:
• All Microsoft OS Feature Descriptor are defined and standardized. Vendors are not allowed to
modify/append/create Microsoft OS Feature Descriptors without direct consent from Microsoft.
• All Microsoft OS Feature Descriptors will have a size and version number embedded in them.
These values should always report correct information to the operating system.
• A device can have more than one Microsoft OS Feature Descriptor embedded in its firmware.
• Some Microsoft OS Feature Descriptors are stored on a per-interface level, while others are
unique for the device. Device level Microsoft OS Feature Descriptors should set the high byte of
the wValue field as zero.

3.4 OS Support
The OS descriptor technology is supported in Windows XP SP1, Windows Server 2003 and beyond.

3.5 Structure of the MTP Feature Descriptor
To identify itself as capable of supporting MTP, a device must also support the Extended Configuration
Descriptor which is one of the defined feature descriptors. The structure of this descriptor is as follows
3.5.1 Header Section
The Header Section stores information about the rest of the Extended Configuration Descriptor. The
dwLength field contains the total length of the entire Extended Configuration Descriptor. The Header
section also contains a version number, which will be initially set to 1.00 (0100H). Future revisions of this
descriptor may be released at a later stage. It must be noted that future versions of the Extended
Configuration Descriptor might also need to increase the number of entries in the Header section, so
please verify that this number is accurately stored in the device and read by the operating system.
Offset Field Size Value Description
0 dwLength 4 Unsigned
DWord
The length field describes the length of
the Extended Configuration Descriptor
in bytes.
4 bcdVersion 2 BCD Extended Configuration Descriptor
release number in Binary Coded
Decimal (i.e. version 1.00 is 0100H)
6 wIndex 2 Word Fixed = 0x0004
8 bCount 1 Byte Total number of Function Sections that
follow the Header Section = 0x01
9 RESERVED 7 RESERVED
Table 4: Extended Configuration Descriptor Header Section
3.5.2 Function Section
The Function Section provides two important pieces of information. It groups consecutive interfaces,
serving a similar purpose, into function groups, and provides Compatible and SubCompatible IDs for each
function. The format of the Function Section (including values that should be used by an MTP device) is
listed below.
Offset1
Field Size Value Description
0 bFirstInterfaceNumber 1 Byte Starting Interface Number for this
function = 0x00
1 bInterfaceCount 1 Byte Total number of Interfaces that
must be included to from this
function = 0x01
2 compatibleID 8 Bytes The Compatible ID for this
function as defined by Microsoft
= MTP
10 subCompatibleID 8 Bytes The Sub Compatible ID value as
defined by Microsoft = 0
18 RESERVED 6 RESERVED = 0
Table 5: Extended Configuration Descriptor Funciton Section
1
Offset of the Custom Property Section has been reset to zero. To calculate the offset of a field from the beginning of the
Extended Configuration Descriptor, add the length of the sections that precedes it.

3.6 Extended Device Class Identification
For computers running Windows Vista or Windows XP with Windows Media Player 11, the WPD driver
allows MTP devices to identify themselves as a device class so that Windows may associate the proper
generic icon with the device. This device class identification is a subcomponent of the MTP OS
Descriptor identifier.
3.6.1 Device Icons
Three types of icons can be displayed for a given device. Vendor-provided icons take highest priority,
followed by device class icons, with the generic icon being used in the absence of any icon information.
Vendor-provided icons are strongly recommended for the best user experience.
3.6.1.1 Custom vendor-provided icons
Vendor icons take the highest priority for device icons in Windows. Vendor icons allow device vendors to
attach branding and a device-specific icon to the MTP device. More information regarding vendor-
provided icons can be found in the “Vendor Provided Icons Speclet” found in the Media Transfer Protocol
Porting Kit.
3.6.1.2 Device class icons
Device class icons have been introduced for Windows Vista and Windows XP with Windows Media Player
11. Device class icons provide device vendors a chance to identify an MTP device as a particular class of
devices so that a more specific icon can be provided. For example, a device can now identify itself
specifically as a mobile phone and receive a generic mobile phone icon instead of the generic MTP icon.
Examples of three device class icons are located below:
camera.ico (72 KB) audioplayer.ico
(113 KB)
cellphone.ico (107
KB)
3.6.1.3 Generic device icon
Legacy devices that do not provide a vendor-specified icon or identify themselves as part of a device
class will be represented with a generic MTP icon. A minimum of device class identification is highly
recommended for an improved user experience.
3.6.2 Device Classes
Seven device classes exist, identified by various subcomponents. To identify as a device class, the
Microsoft OS Descriptor should be modified as shown in Table 6: MTP Subcomponent Identifiers.
3.6.2.1 Subcomponent identifiers
MTP subcomponent identifier Perceived Device Type
(MTP Device Property)
Device class
MS_COMP_MTP&MS_SUBCOMP_01 0x0 MTP generic
MS_COMP_MTP&MS_SUBCOMP_02 0x1 MTP digital still camera
MS_COMP_MTP&MS_SUBCOMP_03 0x2 MTP audio/video player
MS_COMP_MTP&MS_SUBCOMP_04 0x3 MTP mobile handset
MS_COMP_MTP&MS_SUBCOMP_05 0x5 MTP personal digital assistant
(PDA)
MS_COMP_MTP&MS_SUBCOMP_06 0x4 MTP digital video camera

MS_COMP_MTP&MS_SUBCOMP_07 0x6 MTP audio recorder
Table 6: MTP Subcomponent Identifiers
4 DOWN LEVEL SOLUTIONS
MTP drivers are currently shipping in Windows Media Player 10. However, Windows Media Player 10 can
only be installed on PCs running a version of the OS later than Windows XP.
In order to allow device manufacturers to develop devices that can still be used on PCs running earlier
versions of an operating system, Microsoft is proposing one of two solutions.
4.1 WMDM9 MTP Service Provider
Microsoft is in the process of developing a service provider that will allow applications that use the
WMDM9 API set to talk to MTP devices. Microsoft’s current plan is to make this service provider available
for device manufacturers to ship in box with their devices so that it can be installed on applicable PCs.
This service provider is currently scheduled to be available in Q4 2004.
4.2 Dual (MSC+MTP) Mode Devices
Other solution that device companies may choose to consider is a “dual-mode” device. Many devices
already support MSC today. Microsoft has developed a solution whereby a device can detect the
configuration of the PC to which it is connected and automatically switch to the appropriate mode of
communication.
At a high level, the solution works by taking advantage of the fact that dual mode devices will support both
an MSC USB class ID (0x08) and Microsoft’s proprietary OS descriptor (see section on OS Descriptor).
When a device is connected to the PC, the following installation steps take place:
1. Device provides USB descriptor indicating support for Control, Bulk and Interrupt end points
2. Device provides MSC class ID (0x08) indicating that it supports Mass Storage mode with the
Control and Bulk endpoints
3. Device provides OS descriptor indicating that it supports MTP mode
In versions of the OS that support the OS descriptor, presence of the OS descriptor (on a device) takes
precedence over a USB class ID. When the OS descriptor is detected during the install process, the PnP
system will attempt to find a matching driver. If the MTP communications stack has been installed, a
matching driver will be found and loaded (wpdusb.sys or similar component). If the MTP communications
stack has not been installed, no matching driver will be found and the PC will revert to the MSC class ID
and load the USB MSC driver (usbstor.sys)
Once a driver has been loaded it will initiate communications with the device. Microsoft is proposing that
by taking advantage of the unique nature of the communications initiated by each of these drivers, the
device can determine which communication mode needs to be supported.
4.2.1 MSC Identifier (usbstor.sys)
The USB Mass Storage Class Bulk-Only Transport spec requires that every MSC Command Block
Wrapper (CBW) start with a DWORD signature, 0x43425355. Microsoft’s MSC driver (usbstor.sys)

complies with this requirement. A MSC device could use this signature and/or other information (e.g. size
of the command) to differentiate a CBW/MSC driver from other protocols/drivers.
Refer to the official USB documentation for more details on the specifics of CBWs

4.2.2 MTP Identifier (wpdusb.sys or similar component)
As outlined in the MTP spec, GetDeviceInfo must be issued to the device prior to any other operation.
The Microsoft MTP class driver conforms to this requirement.
The bit pattern:
0000000C 0001 1001 xx xx xx xx
(where the last 4 bytes are indeterminate) corresponds to the structure of the generic USB container
packet for the GetDeviceInfo operation
Note: the above hex string is big-endian. Given that USB connections are always little-endian the pattern
to look for is actually: 0c 00 00 00 01 00 01 10 xx xx xx xx
4.3 Safe Boot Mode
There are certain scenarios where MSC offers advantages over MTP. One example of this is HDD
defragmentation. Once a dual mode device has been installed on a PC as an MTP device, it is not easy
to have it reconnect as a MSC device.
An optional addition to a dual mode device is a “Safe Boot Mode”. This mode would be manually
selectable by the user and set the device to present itself as a MSC device only. I.e. it would not respond
to the OS descriptor requests sent by the PC. A device supporting this optional “MSC only” mode should
ensure that it correctly configures it’s USB product IDs. See the following section for more information.
4.4 Device Requirements
In order to enable auto switching to the correct communications mode, the device must watch for the
unique pattern(s) described earlier. In doing so, it should be possible for devices to implement the
following switching logic:
If (foundMTPUniqueString()) {
loadMTPStack();
}
else {
loadMSCStack();
}
Note the above pseudo code is provided as a guide only and is not intended to represent real
code existing on the device.
4.4.1 VID/PID Considerations
When a device supports multiple configurations it is usually required that the device support a different
product ID (PID) for each consideration. In the case of a dual mode device, Microsoft recommends the
following:
1. For automatic switching between modes, the same PID must be used, because at the time when
the PID is communicated, the device is not aware whether it is connecting to an MTP capable
PC.
2. If the device supports an optional “Safe Boot Mode” (see above) it should use a different PID to
the one used when it connects in dual-boot mode.

5 END USER EXPERIENCE
5.1 Device Support
The following device configurations will be supported on the Windows platforms.
5.1.1 Device Type 1: MTP Device with Microsoft OS Descriptor ID
(USBMS_COMP_MTP) and with backward-compatible PTP class ID
(Class_06&SubClass_01&Prot_01):
1. Before WMP10 upgrade, PTP class driver installs due to compatibility match with entry in
ptpusb.inf.
2. After WMP10 upgrade, MTP device with OS descriptor ID matched with compatible with entry in
WpdMtp.inf file. MTP class driver is installed.
Note: Only devices that are truly backward compatible with PTP should also report support for
the PTP class ID.
5.1.2 Device Type 2: MTP Device without Microsoft OS Descriptor ID and
with backward-compatible PTP class ID:
1. Before WMP10 upgrade, PTP class driver installs.
2. After WMP10 upgrade, no compatible ID matches with generic MTP entry in WMP10 WpdMtp.inf
file. Device-specific VID&PID string must either appear in WpdMtp.inf or in an IHV-supplied .inf
file that refers to generic MTP install section in WpdMtp.inf.
5.1.3 Device Type 3: MTP Device without Microsoft OS Descriptor ID and
without backward-compatible PTP class ID:
1. Before WMP10 upgrade, device VID&PID appears in IHV-supplied .inf file (or in inbox ptpusb.inf)
and refers to the sti.inf generic PTP install section. PTP class driver installs.
2. After WMP10 upgrade, IHV-supplied .inf file (or inbox ptpusb.inf) must either be replaced, or
alternatively the user must choose from among the two compatible drivers, in order to install the
MTP class driver. New .inf file containing VID&PID entry refers to generic MTP install section in
WpdMtp.inf rather than STI.PTPUSBSection in sti.inf.
5.1.4 Device Type 4: Dual Mode MTP/MSC Device with Microsoft OS
Descriptor ID and with backward-compatible MSC class ID:
1. Before WMP10 upgrade, MSC class driver (usbstor.sys) installs due to compatibility match with
entry in usbstor.inf.
2. After WMP10 upgrade, MTP device with OS descriptor ID matched with compatible with entry in
WpdMtp.inf file. MTP class driver is installed.
.

5.2 Supported OSs
5.2.1 Windows Media Player 10 (WMP10) Installed
5.2.1.1 Device Type 1
When device type 1 is connected to an OS that supports the OS descriptor, the end user will be provided
with a true plug and play experience. I.e. no installation will be required.
When device type 2 is connected to an OS that supports the OS descriptor it will initially install as a
backward compatible PTP device and the PTP class driver is installed.
For the device to install as an MTP device, the IHV must provide the following a setup application either
on a CD supplied with the device or downloadable from the internet. This setup application copies an IHV-
specific .inf file containing a compatible VID&PID for the device and refers to the MTP install section in
WpdMtp.inf. The setup application runs either before or after the WMP10 upgrade. See section Building a
.INF file for more information.
When device type 3 is connected to an OS that supports the OS descriptor it will initially show as an
unknown device.
When device type 4 is connected to an OS that supports the OS descriptor, the end user will be provided
with a true plug and play experience. I.e. no installation will be required. The device will connect in MTP
mode and take advantage of all WMP10’s device enhancements.

5.2.2 WMP10 Not Installed
If WMP10 is not installed on the PC, then the following components will not be installed.
• New Media Player
• MTP driver
• WMDM service provider
• WMDM Format SDK
Without the above components installed, device type 1 will install as a PTP device.
After WMP10 has been installed, device class 1 will automatically be upgraded to an MTP device the next
time device enumeration occurs (e.g. reboot machine, device reconnection, etc.)
After WMP10 install, the device will still show as a PTP device because the PTP class ID takes
precedence over the device VID&PID. The user will therefore have to manually update the device driver
to use MTP.
Note: Because the device does not contain an OS descriptor, IHVs need to provide a setup application
either on a CD supplied with the device or downloadable from the internet. This setup application copies
an IHV-specific .inf file containing a compatible VID&PID for the device and refers to the MTP install
section in WpdMtp.inf. The setup application runs either before or after the WMP10 upgrade. See section
Building a .INF file for more information.
Without the above components installed, device type 3 will show up as an “unknown” device and the user
will be required to perform one of the potential installations steps:
1. Install the above components from the manufacturers CD
2. Install WMP10 from another location (e.g. online download)
Note: Because the device does not contain an OS descriptor, IHVs need to provide a setup application
either on a CD supplied with the device or downloadable from the internet. This setup application copies
an IHV-specific .inf file containing a compatible VID&PID for the device and refers to the MTP install
section in WpdMtp.inf. The setup application runs either before or after the WMP10 upgrade. See section
Building a .INF file for more information.

Without the above components installed, device type 4 will install as a MSC device, limiting the usage
scenarios to those of legacy devices.
To enjoy the enhanced device features provided by WMP10 a user will have to:
1. Install the above components from the manufacturers CD or
Note: At the time of install existing dev-nodes for the MTP devices will be removed and the USB
bus rescanned to allow connected device to be reinstalled as an MTP device.
5.3 Non-supported OSs
Note: XP Gold is included in this section
5.3.1 WMP10 (or MTP Drivers) Installed
When device type 1 is connected to an OS that doesn’t support the OS descriptor it will initially install as a
When device type 2 is connected to an OS that doesn’t support the OS descriptor it will initially install as a

When device type 3 is connected to an OS that doesn’t support the OS descriptor it will initially show as
an unknown device.
Because the OS descriptor is not supported, device type 4 will install as a MSC device, limiting the usage
5.3.2 WMP10 (or MTP Drivers) Not Installed
Existing products
If WMP10 is not installed on the PC, then the following components will not be installed.
• Latest Media Player
• MTP driver
• WMDM Format SDK
After WMP10 install, the device will still show as a PTP unless the following is done:

After WMP10 install, the device will still show as a PTP unless the following is done:
Without the above components installed, device type 3 will show up as an “unknown” device and the user
will be required to perform one of the potential installations steps:
After WMP10 install, the device will still show as an unknown device unless the following is done:
Without the above components installed, device type 4 will install as a MSC device, limiting the usage
To enjoy the enhanced device features provided by WMP10 a user will have to:
However, because the OS descriptor is not supported, device type 4 will still install as a MSC device.

6 BUILDING A .INF FILE
MTP devices are normally identified and installed by using the wpdmtp.inf file installed with
Windows Media Player 10. This provides a true Plug and Play user experience because no
drivers are needed to get the device running. However, in some cases, device manufacturers may
need to provide an additional proprietary INF file.
This document only describes the parts of an INF file that apply specifically to MTP device
installation. For full documentation on the INF file format, see the INF documentation on
MSDN.
The INF file supplied, wpdmtp.inf, relies on the MS_COMP_MTP USB OS descriptor to
identify MTP devices. Device installation by an OS descriptor has been supported in Windows
starting with Windows XP Service Pack 1 (SP1). If the correct OS descriptor cannot be exposed
by a device, a device manufacturer will need to provide a proprietary INF file relying on
VID&PID to identify the device. More information on OS descriptors can be found in the USB
FAQ on the Microsoft Web site.
The following sample INF file text installs a device and registers the standard Microsoft MTP
driver. If you use this, you will not need to provide your own driver. The INF file itself is the
only thing that you must provide. This INF file installs an MTP device the same way as
wpdmtp.inf, except it relies on VID&PID for device identification. Obtain a digital signature for
your INF file from Windows Hardware Quality Labs (WHQL), and supply a catalog file with the
signature and the INF file.
Be sure to replace the following placeholders (shown in boldface in the following code) before
using the INF file:
• Replace "ABC Inc." wherever it occurs with your actual company name.
• Provide correct VID and PID values instead of XXXX and YYYY.
• Replace the driver version given with the correct driver version.
[Version]
Signature="$WINDOWS NT$"
Class=WPD
ClassGUID={EEC5AD98-8080-425f-922A-DABF3DE3F69A}
Provider=%Provider%
DriverVer=01/01/2004,1.0.0.0
[Manufacturer]
%MfgName%=AbcInc
[AbcInc]
%AbcInc.DeviceDesc%=AbcInc_MTP, USBVID_XXXX&PID_YYYY
[AbcInc_MTP]
Include = wpdmtp.inf
Needs = WPD.MTP.CopyFiles

[AbcInc_MTP.hw]
Needs = WPD.MTP.Registration
[AbcInc_MTP.Services]
Needs = WPD.MTP.Services
[Strings]
AbcInc.DeviceDesc = "ABC Inc. MTP Device"
MfgName = "ABC Inc."
Provider = "ABC Inc."

7 INSTALL PROCESS
The following section was taken from the WPD Device Installation Specification (see references section)
7.1 Supported OSs
For a PC to talk to an MTP device, the following components need to be installed on the PC:
• MTP driver
• WMDM Format SDK
After the required components listed above have been successfully installed to the system, WPD device
driver installation may now begin. Using the WPD MTP driver as an example, the following diagram
illustrates the WPD device install sequence:
Figure 1: MTP Device Install Sequence

1) An MTP device is physically connected to the USB bus.
2) The USB bus driver detects this newly connected device, retrieves the advertised hardware ID
and propagates a PnP notification event that eventually reaches the user-mode PnP manager
service. As a result, the service spawns a process presenting the familiar “Hardware Update
Wizard” dialog box to the user.
3) The user progresses through the wizard until a list-box appears, with selections representing the
INF files whose device IDs match (or are compatible with) the USB device hardware ID
discovered by the kernel-mode USB bus driver. In the case of WMP10 and an MTP device, the ID
is “USBMS_COMP_MTP”. In accordance with the USB specification (see
http://www.usb.org/developers/docs ), this OS Descriptor ID takes precedence over the PTP
class ID (“USBClass_06&SubClass_01&Prot_01”) that is also returned from MTP devices so
they can also be used as a down-level compatible PTP device. The WMP10 update contains a
modified USB kernel-mode bus driver that recognizes this descriptor and is able to identify the
device as a true MTP device. This all results in the following behavior:
a. Pre- WMP10 update: the MTP device will install as either a MSC or PTP imaging device
(depending upon the class of device) Applications may communicate with it using legacy
API sets such as the WMDM (using the MSC SP) or WIA.
b. Post-WMP10 update with a device that does return the MS OS Descriptor ID: device
appears as a WPD MTP device. Applications may communicate it using the MTP
protocol. WMP10 contains an updated USB bus driver, wpdusb.sys. This driver
recognizes the OS Descriptor ID and consequently exposes the device with this ID using
the MTP compatible interface class.
c. Post-WMP10 update with a device that does not return the MS OS Descriptor ID: driver
install requires some additional help. As mentioned in preceding section End User
Experience, this can take the form of an IHV-supplied .inf file containing a device
compatible ID entry that refers to the generic MTP install section in WpdMtp.inf.
Alternatively the IHV can work with MS to provide the relevant device VID&PID entry in
WpdMtp.inf itself.
4) Following confirmation of the driver selection by the user, driver installation begins:
d. The WPD class installer receives new device install notification (DIF_INSTALL), starting
the umwdf service if it’s not already running. After this, the startup type for umwdf is
changed to auto-start. This ensures a running uWDF manager even after a system
reboot so that clients may bind to registered user-mode drivers. Any failure encountered
in the above aborts the install.
e. The directives contained in wpdmtp.inf are parsed and carried out. As a result: driver
files are copied to the system, registry entries to make the MTP driver endpoint visible to
uWDF are added, and the kernel-mode WpdUsb is AddService’d.
5) The device manufacturer and device name are queried from the MTP device and used to the set
the friendly name device property.
6) Driver installation is now complete and the MTP driver endpoint is ready for connection to a WPD
API client.

7.2 Non-supported OS
For a PC to talk to an MTP device, the following components need to be installed on the PC:
• MTP driver
• WMDM Format SDK
After the required components listed above have been successfully installed to the system, WPD device
driver installation may now begin. Using the WPD MTP driver as an example, the following diagram
illustrates the WPD device install sequence:
Figure 1: MTP Device Install Sequence

1. An MTP device is physically connected to the USB bus.
2. The USB bus driver detects this newly connected device, retrieves the advertised hardware ID
and propagates a PnP notification event that eventually reaches the user-mode PnP manager
service. As a result, the service spawns a process presenting the familiar “Hardware Update
Wizard” dialog box to the user.
3. The user progresses through the wizard until a list-box appears, with selections representing the
INF files whose device IDs match (or are compatible with) the USB device hardware ID
discovered by the kernel-mode USB bus driver. In the case of WMP10 and an MTP device, the ID
is “USBMS_COMP_MTP”. In accordance with the USB specification (see
http://www.usb.org/developers/docs ), this OS Descriptor ID takes precedence over the PTP
class ID (“USBClass_06&SubClass_01&Prot_01”) that is also returned from MTP devices so
they can also be used as a down-level compatible PTP device. The WMP10 update contains a
modified USB kernel-mode bus driver that recognizes this descriptor and is able to identify the
device as a true MTP device. This all results in the following behavior:
a. Pre- WMP10 update: depending upon the class of device (see section on End User
Experience) the MTP device appears as a generic MSC device or PTP imaging device.
Applications may communicate with it using the legacy communication stacks such as
the WMDM (using the MSC SP) or WIA (for PTP devices).
b. Because device does not return the MS OS Descriptor ID: driver install requires some
additional help. As mentioned in preceding section End User Experience, this can take
the form of an IHV-supplied .inf file containing a device compatible ID entry that refers to
the generic MTP install section in WpdMtp.inf. Alternatively the IHV can work with MS to
provide the relevant device VID&PID entry in WpdMtp.inf itself.
4. Following confirmation of the driver selection by the user, driver installation begins:
a. The WPD class installer receives new device install notification (DIF_INSTALL), starting
the umwdf service if it’s not already running. After this, the startup type for umwdf is
changed to auto-start. This ensures a running uWDF manager even after a system
reboot so that clients may bind to registered user-mode drivers. Any failure encountered
in the above aborts the install.
b. The directives contained in wpdmtp.inf are parsed and carried out. As a result: driver files
are copied to the system, registry entries to make the MTP driver endpoint visible to
uWDF are added, and the kernel-mode WpdUsb is AddService’d.
5. The device manufacturer and device name are queried from the MTP device and used to the set
the friendly name device property.
6. Driver installation is now complete and the MTP driver endpoint is ready for connection to a WPD
API client.

8 REFERENCES
8.1 OS Descriptor Information
USB FAQ on the Microsoft Web site.
8.2 Device Installation Guidelines
http://www.microsoft.com/whdc/driver/install/default.mspx
8.3 Windows DDK
http://www.microsoft.com/whdc/ddk/winddk.mspx
8.4 USB Mass Storage Class Bulk-Only Transport
http://www.usb.org/developers/devclass_docs

Portable device installation_considerations

More Related Content

What's hot (19)

Similar to Portable device installation_considerations (15)

Recently uploaded (20)

Portable device installation_considerations