SCSI StorPort dropping valid sense data

NTDEV
1

I am seeing a loss of sense data returned from StorPort SCSI mini-port drivers. It appears that the StorPort SRB SenseInfoBufferLength field is getting set to 0x14
before it arrives at the mini-port driver no matter what value is specified in the request.

The requests may be sent via IOCTL_SCSI_PASS_THROUGH_DIRECT from a user application, or from another driver via an IRP built with IoBuildAsynchronousFsdRequest()
and major function IRP_MJ_SCSI. The sense buffer in both cases is sized at 0xFF bytes. When the SRB gets to the miniport driver the SRB SenseInfoBufferLength is always 0x14 no matter what its orignal value was. The proper sense buffer address is being used because I can return data to the caller in the sense buffer at offsets >0x14. The identical code works properly with ScsiPort mini-port drivers under Windows XP. I have seen this behavior in Windows Vista and Windows 7. I have not tested server versions.

My current work-around is to return the amount of sense data needed regardless of SenseInfoBufferLength, but there are times when the SenseInfoBufferLength field is valid and should be respected by the mini-port driver.

Has anyone run into this before or have a solution? Sense buffer lengths >0x14 are required to support descriptor based sense data, or devices which can return more sense data.

2

Another work around you can use is to set a registry value:
TotalSenseDataBytes

Please refer to following pointer for details:
http://msdn.microsoft.com/en-us/library/ff563970(VS.85).aspx

3

Thanks for the information. I tried various settings of the key mentioned, but was unsuccessful at changing the port driver behavior. The SenseInfoBufferLength field is still set to 0x14 when the request arrives at the mini-port. Even if this registry setting worked, it would be impractical as it is unique for each device instance, and does not control the overall behavior. The application is a test/exerciser so it may see many different devices which are routinely changed. Trying to maintain a registry key for each device would not be practical. Not sure what MS is thinking with this implementation.

On the bright side, the app note does imply that StorPort always uses 255. While the length passed to the miniport driver does not work as expected, the note implies the buffer will be larger which explains why the ‘fix’ implemented to transfer more data than requested works. Still, an application without a large enough sense buffer could unknowingly get a buffer overrun.