Microsoft KB Archive Search

Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

  1. Home
  2. Stop D1 (DRIVER_IRQL_NOT_LESS_OR_EQUAL) bugcheck in USBPORT while transferring USB data and selecting USB interface

Stop D1 (DRIVER_IRQL_NOT_LESS_OR_EQUAL) bugcheck in USBPORT while transferring USB data and selecting USB interface

Symptoms

While initializing and communicating with a USB device attached to a computer running Windows 7 or Windows Server 2008 R2, the computer may crash, and you may receive a Stop error message that resembles the following:

STOP 0x000000D1 (0000000000000000, 0000000000000002, 0000000000000000, parameter4 )
DRIVER_IRQL_NOT_LESS_OR_EQUAL


↑ Back to the top

Cause

This problem is caused by a bug in the Microsoft USB 1.1 & 2.0 Host Controller Port driver (USBPORT.SYS). USBPORT fails to synchronize access to the pipe list for a USB device, which may result in an inconsistent (corrupted) pipe list under certain conditions.

This bug is only be likely to be exposed when the USB device is a Composite device, with multiple logical USB devices implemented as children of one physical (parent) USB device.

In this scenario, one function driver is selecting the Interface for its function, which removes the pipes associated with the previous Interface from the device's pipe list. This operation is not protected by a lock (is not atomic), and leaves the pipe list in an inconsistent state for a short period of time.

Meanwhile, another function driver is performing transfers to or from one of its pipes. While processing a new USB transfer, USBPORT walks the device's pipe list to validate the USB pipe that is the target of the transfer, encounters a pipe being removed from the list, dereferences the NULL link pointer from the pipe being removed, and causes the Stop D1 bugcheck.

↑ Back to the top

Resolution

To work around this problem, the developer of a USB Composite device driver (Usbccgp replacement) can synchronize Select Interface requests with I/O requests, as follows.

When a Select Interface request is received for one Function:
  1. Queue (pend) any new transfers for all functions of the Composite device, other than the function associated with the Select Interface request.
  2. After a short delay (to allow pending transfer requests to begin processing), forward the Select Interface request (to the Usbhub PDO [Physical Device Object] for the Composite device) and wait for the Select Interface request to complete.
  3. Upon completion of the Select Interface request, resume transfers for all functions, and forward any previously-queued transfers.
Note that the above workaround may not completely eliminate the bugcheck, depending on details of implementation and the exact reproduction scenario. However, this workaround is expected to significantly reduce the rate of occurrence of this problem.

In addition, this workaround may have consequences for the USB function drivers whose transfers are temporarily queued while the Select Interface request is processed. USB device or driver developers who encounter this issue are encouraged to engage the Microsoft Windows Driver Kit support for more specific guidance with implementing this workaround.

↑ Back to the top

More Information

A fix for this issue may be considered for a future version of Windows.

For more information on Windows Driver Kit support options, see the following links:
Support for Driver Kits and Tools
Windows Driver Kit 7.0 support

↑ Back to the top

Keywords: consumerwin7track, kb

↑ Back to the top

Article Info
Article ID : 2507083
Revision : 1
Created on : 1/7/2017
Published on : 8/16/2011
Exists online : False
Views : 69