USB Storage - FAQ for Driver and Hardware Developers

This paper is for developers who are new to developing USB Mass Storage Class devices that work with the Windows family of operating systems.


Starting with Microsoft Windows 2000, Windows operating systems contain native support for devices that are compliant with the Universal Serial Bus (USB) Mass Storage Class Specification. If the USB bus driver enumerates a mass-storage-class-compliant device on a computer running Windows, it automatically loads the USB storage port driver (Usbstor.sys) for that device.

This article provides answers to frequently asked questions from driver developers about Usbstor.sys.

Additional documentation for Usbstor.sys and driver support for USB mass storage devices is available in the current version of the Windows Driver Kit (WDK), available through the MSDN Library and from the WDK website at

Windows Support and Usbstor.sys

Q. What versions of the Windows operating system support USB storage using Usbstor.sys as the storage port driver?

The following Windows operating systems provide native support for USB mass storage class devices:

  • Windows 7
  • Windows Server 2008
  • Windows Vista
  • Windows Server 2003
  • Windows XP
  • Windows 2000

USB mass storage class devices are supported by Usbstor.sys, which is loaded using Plug and Play (PnP) hardware identifier (HWID) or compatible identifier matching in Usbstor.inf.

Q. Can a USB storage device be the primary (and only) means of storage?

No. USB-based mass storage devices cannot be the primary hard disk storage solution on a regular system (Microsoft Windows Logo Program System and Device Requirements, B10.1.5.6). However, these devices might be expected to be a replacement for booting to load an operating system (for example using a CD-ROM drive over USB) on the primary boot drive or as a replacement for legacy floppy disk drives. Booting from an external USB CD-ROM or USB floppy disk drive requires BIOS support.

For more information and to review the latest WinHEC presentations for ideas see

Q. Can a host simultaneously have multiple, individual USB storage devices on a system?

Yes. A host can have multiple USB storage devices operational at the same time. Because the USB storage class uses bulk endpoints for transfers, having several storage devices operational at the same time might cause individual devices to scale back from peak throughput if there is bus congestion and if they are connected to the same host controller.

Q. Can a USB Mass Storage Interface have multiple alternative interfaces?

No. The USB Mass Storage Class Specification does not allow for alternate interfaces. If a device has an interface that complies with the USB Mass Storage Class Specification, it needs to be on the first interface setting (if the interface has more than one alternate interface setting) because (on current operating systems) Usbstor.sys only looks at the first interface setting.

Q. Can a device have multiple logical units per target device?

The code in Usbstor.sys does not make any assumptions about the number of logical units per target device. If it finds multiple logical units, the operating system enumerates each as a separate device.

Refer to the KB articles Q324953 and Q316857 to find the Quick Fix Engineering (QFE) support for multiple logical units on Windows 2000. This QFE is also available in Windows 2000 Service Pack 3 (SP3).

For more information about how multiple logical unit USB storage devices appear to the operating system, see the WDK.

Q. What problems and updates are known to affect storage solutions on earlier versions of the Windows operating system?

In Windows 2000, a problem exists in Usbhub.sys, when it is loaded as the composite parent driver for a multiple-interface device. In such cases, during a _URB_SELECT_CONFIGURATION request, the child devices are configured with a 4-KB transfer limit on endpoints. To work around this problem, drivers for the child devices can issue a URB_FUNCTION_SELECT_INTERFACE request after the _URB_SELECT_CONFIGURATION request to override the default 4-KB transfer limit.

A QFE is available to fix this issue in Windows 2000. Refer to KB article Q283787, titled “Multifunction USB Device Cannot Transfer 4 KB or Larger Files” for further information. This QFE is also available in Windows 2000 Service Pack 3 (SP3). Contact your Microsoft Technical Account Manager (TAM) for additional information.

Q. Do customers need a new USB storage driver now that USB 2.0 is available?

No. Microsoft has provided a new miniport (Usbehci.sys) driver and an updated Usbport.sys and Usbhub.sys driver to support USB 2.0 starting with Windows 2000. For more details see Client drivers (such as Usbstor.sys) will continue to function on this new USB 2.0 stack.

Q. Does Usbstor.sys need to be modified to support disks over 137 GB in size?

No. Support for disks that are larger than 137 GB is not an issue for the USB mass storage class driver. However, such support is an issue with the USB-ATA bridge chip in the external USB storage device.

USB-ATA bridge chip vendors are working on new devices that support the 48-bit ATA LBA mode, but they will not be in production until later in 2002. When these devices are available, the storage limit on a single device should be 2048 GB.

Q. Can Usbstor.sys fail a query remove?

No. Usbstor.sys never fails a query remove. The failure comes from a higher level driver, or a filter driver. If you see such a failure, verify that you are not running any storage filter drivers.

Q. Can a vendor use SCSI pass through to talk to a USB storage device and send it vendor-specific commands?

IOCTL_SCSI_PASS_THROUGH or IOCTL_SCSI_PASS_THROUGH_DIRECT allow applications to send almost any SCSI command to a target device, with some restrictions. For additional details on the command and the restrictions, see and in the latest Windows Driver Kit (WDK).

Usbstor.sys and Device Class Support

Q. Which device classes does Usbstor.sys understand? Starting with Microsoft Windows 2000, Usbstor.sys makes only one distinction:

bInterfaceSubClass == 06h

- Or -

bInterfaceSubClass != 06h

The value bInterfaceSubClass == 06h means that:

  • Command descriptor blocks (CDBs) should not be padded to 12 bytes.
  • Mode Sense / Mode Select commands should not be translated from 1AH / 15h to 5AH / 55h.
  • Subclass 0x06 should generally be used for flash memory devices.

The value bInterfaceSubClass != 06h means that:

  • CDBs should be padded to 12 bytes.
  • Mode Sense / Mode Select commands should be translated from 1AH / 15h to 5AH / 55h.

Q. Should IHVs use Bulk-Only or CBI for new USB storage devices?

Microsoft recommends the use of the Mass Storage Class Bulk-Only Transport (BOT) specification when developing new USB storage devices. A Bulk-Only Data Interface must include at least one bulk-in and one bulk-out endpoint. The Windows operating system chooses the first bulk-in and bulk-out endpoint for transactions. The reasons for the preference towards BOT are as follows:

  • Cheaper hardware: The Bulk-Only Transport specification requires fewer endpoints than the CBI specification. Fewer endpoints generally reduce overall hardware cost.
  • Compatible ID matching: Starting with Microsoft Windows 2000, the operating system has compatible ID support for ATAPI, FDD, and SCSI protocols over Bulk-Only Transport. Because of this, IHVs do not need to provide an information file (INF) containing their device’s hardware ID.

We highly recommend this scenario for flash storage devices.

Q. I am developing a new USB storage device but I want to load my OWN transport driver and NOT use Usbstor.sys. What should I do?

Usbstor.sys is loaded on any interface that provides a class ID, subclass ID, or protocol ID that matches with a hardware ID or compatible ID in Usbstor.inf.

To load a vendor-specific driver and NOT use Usbstor.sys, do the following:

  • Set the class ID, subclass ID, or protocol ID on the interface descriptor to be vendor-specific.
  • Write your own INF and driver for the device. Include your device's hardware ID in your vendor INF and ensure that the hardware ID is not listed in Usbstor.inf.

Q. Does Windows currently support USB storage devices that use RBC protocol (that is, USB Storage Specification SubClass 0x01)?

Windows does not provide support to handle USB storage devices that use the reduced block commands (RBC) (subclass 0x01) protocol. The issue with supporting RBC devices on Windows 2000 or Windows XP is that the Mode Sense commands are different, and the class drivers (DISK.SYS, CDROM.SYS, SFLOPPY.SYS, and CLASSPNP.SYS) do not understand the RBC version.

In addition, Usbstor.inf does not have a compatible ID match for a USB RBC class device. Consequently, your USB storage device will not load Usbstor.sys when you plug it in to a new Windows XP system. You will need to provide your own INF and drivers to support this device.

We do not recommend the use of RBC class devices for current Windows operating systems.

Q. What must I do to trigger AutoRun on my USB storage device?

The AutoRun capabilities are restricted to CD-ROM drives and fixed disk drives. If you need to make a USB storage device perform AutoRun, the device must not be marked as a removable media device and the device must contain an Autorun.inf file and a startup application.

The removable media device setting is a flag contained within the SCSI Inquiry Data response to the SCSI Inquiry command. Bit 7 of byte 1 (indexed from 0) is the Removable Media Bit (RMB). An RMB set to zero indicates that the device is not a removable media device. An RMB of one indicates that the device is a removable media device. Drivers obtain this information by using the StorageDeviceProperty request.

For more information about the SCSI Inquiry command, see

For more information about StorageDeviceProperty, see the STORAGE_DEVICE_DESCRIPTOR storage structure in the WDK documentation at

For more information on Autorun.inf files see "Creating an AutoRun-Enabled Application" at

Q. Can Windows show a special icon for a drive in My Computer?

Device manufacturers can create personalized, or custom, product icons and include them in their driver packages so that the end user sees an icon that resembles the actual device when using Windows XP, Windows Vista, or Windows 7. These personalized icons are visible in the Autoplay window and in My Computer under Windows XP.

For complete details, see “Personalized Icons for Devices on Windows XP” at

Usbstor.sys and Windows Logo Requirements

Q. Must a USB storage device contain a unique serial number?

Yes. To comply with the USB Mass Storage Class Bulk-Only Transport Specification, all USB storage devices must contain a unique (12 digits or longer) serial number, represented as a UNICODE string. Refer to section 4.1.1 of the USB Mass Storage Class (Bulk-Only Transport) specification and note that serial number characters must be 0x0030-0x0039 or 0x0041-0x0046.

A unique serial number on a USB device maintains the same device node (devnode) as a user moves the device from USB port to port. This unique devnode ensures that properties (icons, policies, driver letters, and so on) associated with the device are not reset when the device is moved to a new port or when a second device with the same VID/PID/REV is added to the system.

IHVs must ensure that a device’s serial number is unique in order for that device to comply with Windows operating systems. A Windows Logo Program requirement states that, if your device includes a serial number, the serial number must be unique for each instance of your device. For more information about the Windows Logo Kit (WLK) test for USB serial numbers, see ”USB Serial Number” on MSDN.

Q. Where can I get a list of requirements for Windows operating systems and storage devices?

The list of requirements that removable storage devices need to comply with is available at

Refer to the WDK documentation for additional details and requirements for USB storage devices in order to be compatible with Usbstor.sys.

Usbstor.sys and Power Management

Q. I want to embed a storage device inside a laptop, but still want to conserve power. What should I consider in this design?

Starting with Windows XP, the operating system supports selective suspension of USB devices, as described in "Selective Suspension of USB Devices" in the "USB Design Guide" section of the current WDK. The Selective Suspend feature allows a driver to turn off the USB device it controls when the device becomes idle, even while the system itself remains in a fully operational power state (S0). This feature is primarily intended to conserve battery power in laptops.

The Selective Suspend feature allows drivers to idle the host controller, any empty USB hubs including the Root Hub, and the full range of USB devices supported by the operating system. Windows XP does NOT natively support Selective Suspend in Usbstor.sys.

Alternatively, if you design your storage solution as a compound device and place the bridge chip behind a USB hub, you can then emulate device removal upon media removal. Windows XP, Windows Vista, and Windows 7 interpret the emulation to understand that the storage device has been removed from the USB hub. An empty hub will then be selectively suspended by the USB stack.

For your implementation of this solution to work properly, the compound device’s hub must not be more than one hub away from the root hub. Although this solution might reduce power consumption, it will also make the USB storage device disappear from Device Manager and My Computer.

Q. Should my USB device set the remote wake bit on the USB storage device’s configuration descriptor?

The Windows USB storage driver does not currently use the remote wake field of the device.

Q. Did the removal policies for USB storage devices change after Microsoft Windows 2000?

Customer feedback showed that consumers were unplugging USB storage devices from systems, without going to the “safely remove hardware” tab in the system tray on Windows 2000 systems. Such random removal sometimes left storage devices in a corrupted state.

To mitigate the likelihood of data loss in surprise removal scenarios, Windows XP refined the caching policy for removable storage. Starting with Windows XP, for consumer-oriented removable storage (USB, Flash, Zip, and so on), write caching is disabled by default.

Disabling write caching means that, instead of saving up changes for a file on a removable storage device and then doing a bulk write, Windows XP writes changes to the file as the changes are made. This keeps data on removable storage devices more current, mitigating the likelihood of data loss. However, disabling write caching also has a performance impact.

To view removable properties associated with a USB storage device, open Device Manager, select the storage device’s properties, and see the Policies tab.

Call to Action and Resources

Call to Action:

  • Device manufacturers for USB mass storage devices must review this entire FAQ list. If your question is unanswered, contact
  • Device manufacturers for USB mass storage devices must include a USB serial number in their USB Bulk-Only device.
  • Device manufacturers should arrange to send newer models of their USB bridge chips to the Windows team for testing.
  • For related information, please visit


Microsoft Hardware and Driver Developer Information

Windows Driver Kit (WDK)

Windows Logo Program

USB Serial Number



Send comments about this topic to Microsoft