How to troubleshoot error messages about Event ID 9 and Event ID 11

For a Microsoft Windows 2000 version of this article, see 154690 .


This article describes troubleshooting methods that you can use if information similar to the following examples is recorded in the system log.
Event ID: 9
Source: Aic78xx
Description: The device, \Device\ScsiPort0, did not respond within the timeout period.
Event ID: 11
Source: Aic78xx
Description: The driver detected a controller error on Device\ScsiPort0.
The name of the source can be the name of any controller, for example, Atdisk or ATAPI.

More Information

In almost all cases, these messages are posted because of hardware problems. The source may be the controller or (more probably) a device that is attached to the controller. The hardware problem can be poor cabling, incorrect termination or transfer rate settings, slow device relinquishment of the SCSI bus, a faulty device, or in rare cases, a poorly written device driver.

Locating the Source of the Problem

Here are some troubleshooting tips to help you diagnose and pinpoint the problem:
  • Read the technical manual for the SCSI controller to determine the termination requirements. Many modern SCSI controllers require active terminators (at least one of the devices on the bus must provide termination power). Proper termination involves both a terminator (resistor) and a device that supplies a signal to the bus for termination power. The SCSI-2 standard specifies that a controller (initiator) must supply termination power. Therefore, any controller that claims to be SCSI-2 compatible probably does supply termination power, but you should check to make sure.

    Also, many devices, especially drives, can provide termination power; if a drive has a jumper labeled Trmpwr, enable the jumper.
  • If both internal and external SCSI devices are attached, make sure that the last device on each SCSI chain is terminated, and make sure that intermediate devices are not terminated.
  • If there is only a single SCSI chain (either all internal or external), make sure that the last device of the SCSI chain is terminated and that the SCSI controller itself is terminated. This is usually a BIOS setting.
  • Look for loose or poor-quality SCSI cabling. A long chain of cables with mixed internal and external cabling can degrade the signal. A SCSI specification that allows for a long distance assumes that the cabling allows no leakage or interference. The allowable reality is generally a shorter distance. External cables that are six feet long or longer should be replaced with three-foot cables.
  • Look for removable rotating media such as removable hard drives. Removable rotating media takes longer to restart than other removal media and may generate an Event ID 11 upon resume from suspend or hibernation. After the device has initialized you can access the device.
  • Take note of when the event messages were recorded, and try to determine whether the messages coincide with certain processing schedules (such as backups) or heavy disk processing. This might pinpoint the device that is causing the errors.

    The tendency of drives to have these types of problems under heavy stress is often due to slow microprocessors. In a multitasking environment, the processor may not be fast enough to process all the input/output (I/O) commands that arrive almost simultaneously.
  • Slow down the transfer rate settings if timeouts are associated with tape drives; using a 5-mbs transfer rate usually cures the timeouts.
  • Simplify the SCSI/IDE chain by removing devices. If you suspect that a particular device is causing the problem, move that device to another controller. If the behavior follows the device, replace the device.
  • Check the revisions of the SCSI controller BIOS and of device firmware, and obtain the latest revisions from the manufacturer. (There is a procedure for checking the model number and firmware revision later in this article.)
  • Check the version of SCSI device driver. The SCSI driver is located in the %SystemRoot%\System32\Drivers folder. Look at the version in the properties for the driver file. If the driver is not up-to-date, see whether the manufacturer has a newer version.
  • Remove any other controllers that might create bus contention issues.
  • See whether a low-level format performed by the SCSI controller resolves the event messages.
  • Try substituting a different make or model of any suspect hardware.

Checking the Model Number and Firmware Revision of a Device

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
322756 How to back up and restore the registry in Windows

The model number of the device and its firmware revision are in the Windows registry. To view this information, follow these steps:
  1. Start Registry Editor (Regedit.exe).
  2. Locate the following key in the registry
    HKEY_LOCAL_MACHINE\Hardware\Devicemap\Scsi\ScsiPortx\ScsiBusx\ TargetIdx\LogicalUnitIdx
    where x varies according to the device number.
  3. Look at the REG_SZ identifier value to see the model number and firmware revision values. For example, if you see

    SEAGATE ST32430N 0510
    0510 is the firmware revision value.
  4. Record the device model number and firmware revisions, and check with the manufacturer to see whether there are any known issues for that model of the device.

Article ID: 314093 - Last Review: Oct 23, 2008 - Revision: 1