Hello my name is Bob Golding and I would like to share with you a new event that you may see in the system event log. Event ID 153 is an error associated with the storage subsystem. This event was new in Windows 8 and Windows Server 2012 and was added to Windows 7 and Windows Server 2008 R2 starting with hot fix KB2819485.
An event 153 is similar to an event 129. An event 129 is logged when the storport driver times out a request to the disk; I described event 129 messages in a previous article. The difference between a 153 and a 129 is that a 129 is logged when storport times out a request, a 153 is logged when the storport miniport driver times out a request. The miniport driver may also be referred to as an adapter driver or HBA driver, this driver is typically written the hardware vendor.
Because the miniport driver has a better knowledge of the request execution environment, some miniport drivers time the request themselves instead of letting storport handle request timing. This is because the miniport driver can abort the individual request and return an error rather than storport resetting the drive after a timeout. Resetting the drive is disruptive to the I/O subsystem and may not be necessary if only one request has timed out. The error returned from the miniport driver is bubbled up to the class driver who can log an event 153 and retry the request.
Below is an example event 153:
This error means that a request failed and was retried by the class driver. In the past no message would be logged in this situation because storport did not timeout the request. The lack of messages resulted in confusion when troubleshooting disk errors because timeouts would occur but there would be no evidence of the error.
The details section of the event the log record will present what error caused the retry and whether the request was a read or write. Below is the details output:
In the example above at byte offset 29 is the SCSI status, at offset 30 is the SRB status that caused the retry, and at offset 31 is the SCSI command that is being retried. In this case the SCSI status was 00 (SCSISTAT_GOOD), the SRB status was 09 (SRB_STATUS_TIMEOUT), and the command was 28 (SCSIOP_READ).
The most common SCSI commands are:
SCSIOP_READ - 0x28
SCSIOP_WRITE - 0x2A
The most common SRB statuses are below:
SRB_STATUS_TIMEOUT - 0x09
SRB_STATUS_BUS_RESET - 0x0E
SRB_STATUS_COMMAND_TIMEOUT - 0x0B
A complete list of SCSI operations and statuses can be found in scsi.h in the WDK. A list of SRB statuses can be found in srb.h.
The timeout errors (SRB_STATUS_TIMEOUT and SRB_STATUS_COMMAND_TIMEOUT) indicate a request timed out in the adapter. In other words a request was sent to the drive and there was no response within the timeout period. The bus reset error (SRB_STATUS_BUS_RESET) indicates that the device was reset and that the request is being retried due to the reset since all outstanding requests are aborted when a drive receives a reset.
A system administrator who encounters event 153 errors should investigate the health of the computer’s disk subsystem. Although an occasional timeout may be part of the normal operation of a system, the frequent need to retry requests indicates a performance issue with the storage that should be corrected.
I dont have WDK to have access to the full scsi.h and srb.h. Could you please post more codes online to make it easier to find more information about this error? I'm getting a 00 04 28, so SCSI is good but SRB is ????, all that while doing a read.
[Hi Mauricio. The WDK is a free download, you can get it from http://msdn.microsoft.com/en-us/library/windows/hardware/hh852362.aspx. Regarding the error you are seeing, 04 is SRB_STATUS_ERROR.]
Downloading the whole WDK just to find the codes does seem a little overkill.
I'd be especially thankful if you could decode the following "02 08 28".
[Thank you for your feedback. To decode your message:
08 - SRB_STATUS_NO_DEVICE
28 - SCSIOP_READ
It appears your system attempted to read from a device which was not present. Most likely the device was removed.]
this is great stuff man. Would this also report with wiht the Microsoft iSCSIPORT driver. Can is help troubleshoot dropped frames for an ethernet/iSCSI SAN?
[Most iSCSI implementations now use msiscsi rather than iscsiport. To answer your question, it depends on if msiscsi returns an error that that will bubble up to the class driver to be retried. I do not recall of any errors that are handled in that way. The only one I can think of that may bubble up is SRB_STATUS_BUS_RESET (0xE). Most all of the retryable errors occur between msiscsi and storport. Msiscsi does not time requests, so you should not see a timeout.]