Consider the following scenario on a computer that is running Windows Vista or Windows Server 2008:

• You have an IEEE 1394 bus host controller installed on the computer.
• This IEEE 1394 bus host controller does not contain a physical layer (PHY) chip that complies with the IEEE 1394A (2000) specification.
• You attach a remote IEEE 1394 node that can function in the Isochronous Resource Manager (IRM) role. The node can be either of the following:
  • Another computer on which there is an IEEE 1394 bus host controller that contains a 1394A PHY chip.
  • Another IEEE 1394 device that supports the IRM role.

In this scenario, operations to support isochronous data transfers, such as querying for and allocating Isochronous Bandwidth and Channels, may fail. Additionally, isochronous data transfers may be impossible.

For example, when you issue a REQUEST_ISOCH_QUERY_RESOURCES request in an application, the request should be forwarded to the IRM on the remote node. Then, the request should return the channels and the bandwidth that are currently available according to the IRM’s registers. However, the request may be chained to the local IEEE 1394 host controller instead. Therefore, the request returns ‘0’s for all available channels and the bandwidth.

When performing Asynchronous transfers at a high rate to or from a device connected to an IEEE 1394 bus, if the Microsoft 1394 stack does not receive a response to a pending Asynchronous request, the expected behavior would be for the Asynchronous request that did not receive a valid response to time out and complete with a STATUS_IO_TIMEOUT status.

However, under these conditions, the Microsoft 1394 stack may incorrectly match Asynchronous Response packets to the wrong Asynchronous Request. This results in the incorrect status and/or data being returned for Asynchronous Requests. This incorrect matching of Asynchronous Responses to Asynchronous Requests may be repeated for a number of submitted Asynchronous Requests, while the high rate of Asynchronous transfers continues.

After the rate of Asynchronous transfers is reduced, an Asynchronous Request will eventually time out, since the Response that actually matched the Request was incorrectly matched to a previous Asynchronous Request. However, when this problem occurs, the Asynchronous Request that eventually times out is not the one for which a Response was not received. The original Asynchronous Request that did not receive a response was already completed with possibly erroneous status and/or data from a different Response.

On a computer that is running Windows Vista or Windows Server 2008, when you perform an isochronous data transfer to or from an IEEE 1394 device, the isochronous data transfer suddenly stops.

In this scenario, if you have enabled the Driver Verifier for the driver that the device uses to perform the isochronous data transfer, the operating system crashes. Additionally, you receive the following Stop error message on a blue screen:

STOP 0×000000D1 (parameter1, 00000002, 00000001, parameter4)
DRIVER_IRQL_NOT_LESS_OR_EQUAL ohci1394.sys

When you are transferring Isochronous data from a device connected to an IEEE 1394 bus, the transferred data may appear to be incorrect (corrupted) or be received later than it was sent by the IEEE 1394 device. The symptoms of this problem may appears as glitches in or repeated sections of audio or video streaming data.

This problem only occurs under the following conditions:

• The Isochronous data is received by a computer with at least 4GB of physical memory, or with physical memory located at physical addresses above 4GB.
• The computer is running a version of Windows that support more than 4GB of physical memory.

This problem does not occur on computers with physical memory located at physical addresses entirely below 4GB, or running a version of Windows that does not support more than 4GB of physical memory.

On a computer that is running Windows Vista or Windows Server 2008, you have two IEEE 1394a hard disks connected. If you repeatedly unplug and re-plug one of the 1394a hard disks, the other 1394a hard disk becomes inaccessible. Then, you receive a Stop error that resembles the following:

STOP: 0×0000009F (parameter1, parameter2, parameter3, parameter4)
DRIVER_POWER_STATE_FAILURE

Considering the following scenario:

• You have a computer that is running one of the following operating systems:
  • Windows XP
  • Windows Vista
  • Windows Server 2008
• This computer has a Texas Instruments (TI) IEEE 1394 host controller installed.
• On this computer, you install hotfix 952824 or hotfix 951410.
• On this computer, you connect one or more IEEE 1394 digital video cameras or other isochronous streaming devices.
• You use these streaming devices to stream some data.

In this scenario, the device performance decreases. For example, streaming speed may become very slow, or some frames may be dropped.

On a Windows-based computer, devices that stream data over more than two isochronous channels by using IEEE 1394 connections may have choppy or distorted output. Typically, the issue occurs when multiple instances of isochronous data, such as audio data and video data, are streamed over the IEEE 1394 connections.

Note: This problem may also occur on a single physical device that has multiple channels of isochronous data. For example, this problem may also occur on an audio mixing board that outputs multiple audio channels over separate isochronous channels.

For example, you may have multiple digital video cameras, audio input devices, or both, that are connected to the computer by using the IEEE 1394 connections. In this case, streaming video that is output from the digital video cameras may appear choppy and may not have a smooth and steady frame rate. Steaming audio from the audio devices may have distorted sound.

Consider the following scenario:

• You have a Windows Vista-based computer that uses an Open Host Controller Interface (OHCI) host controller. This OHCI host controller is Institute of Electrical and Electronics Engineers (IEEE) 1394-compliant.
• You have two IEEE 1394-compliant storage devices.

In this scenario, you may experience one of the following issues:

• When you start the computer and connect the first IEEE 1394-compliant storage device to the OHCI host controller, the device is loaded correctly. However, when you connect the second storage device, this device never appears in Device Manager. Additionally, the first device disappears from Device Manager.
• When you connect the two IEEE 1394-compliant storage devices before the computer is started, neither device appears in Device Manager after you start the computer.

When you use an IEEE 1394-based scanner and run a 32-bit scanning program on a computer that is running Microsoft Windows XP 64-bit, Microsoft Windows Server 2003, you receive an error message on a blue screen that resembles one of the following:

0×0000000A: IRQL_NOT_LESS_OR_EQUAL

0×000000BE: ATTEMPTED_WRITE_TO_READONLY_MEMORY

This problem occurs when the scanning program calls the DeviceIoControl function to send a IOCTL_SCSISCAN_CMD control code to the kernel mode driver.

In Windows Vista, you may not experience the blue screen. When your scanning program calls the DeviceIoControl function to send an IOCTL_SCSISCAN_CMD control code to the kernel mode driver in Windows Vista, this call may not be completed successfully, and your scanning program does not work as expected. The exact symptom that is observed in the user interface depends on how your scanning software works when the DeviceIoControl function fails.

Note: If your scanning program does not work correctly, it may be related to various causes．You have to contact the software vendor first to check whether you are encountering the exact problem that is described in this article.

Consider the following scenario:

• You connect an IEEE 1394 standard-based camera to an IEEE 1394 standard-based external hub.
• You connect the IEEE 1394 standard-based external hub to an IEEE 1394 standard-based port on a computer that is running Windows Vista.

In this scenario, Device Manager in Windows Vista displays the camera device as expected. However, when you unplug the camera cable, the camera device does not unload successfully in Device Manager.

Note: If you unplug the cable from the external 1394 hub that is connected to the IEEE 1394 standard-based port, the camera driver unloads successfully.