With this defect check enabled, busTRACE will check the amount of data transferred against the amount of data busTRACE expected to be transferred.
The best way to describe what this defect check does is by way of example. Let's use a simple Inquiry CDB as our example. In this test case, we are issuing a CDB with a 240 (F0h) byte buffer. We also specify F0h in the CDB itself so that our device knows the maximum number of bytes we would like transfer. Here is the CDB that we send:
For our example, we will use the SanDisk Cruzer Micro flash drive. Here is the return data:
Note that the CDB allowed for a maximum of 240 bytes and the SanDisk device returned 36 bytes. The device itself is telling us how many bytes are valid. We look to the "Additional Length" field in the return data. The device is returning 31 in this field. If you add 5 to that (for the # of bytes preceding and including the Additional Length), you come up with 36 bytes.
So far we have described how software lets the device know the maximum amount of data to transfer (e.g. Allocation Length). We have also described how the device lets the software know how much data it transfers (e.g. Additional Length). The port/miniport driver also provides a means for letting busTRACE know exactly how many bytes were transferred. In a SCSI_REQUEST_BLOCK request and a SCSI_PASS_THROUGH request, the DataTransferLength field is defined:
Indicates the size in bytes of the data buffer. If an underrun occurs, the miniport driver must update this member to the number of bytes actually transferred.
As Microsoft's specifications clearly state, the miniport driver must update this member to the number of bytes actually transferred. Getting back to our Inquiry example above, the DataTransferLength field would be set to 240 (F0h) when the request is submitted. When the request is finished, the miniport driver should return 36 (24h) in the DataTransferLength.
By looking at the DataTransferLength field, the CDB, and any data in/out, busTRACE is able to determine how many bytes of data should have been transferred. If the amount of data busTRACE expects to have transferred doesn't match the DataTransferLength (as set by the port/miniport driver), busTRACE will flag this as a defect. This would either indicate a port/miniport driver bug (more likely) or a bug in the device firmware.
Some engineers may prefer to disable this defect check. The reason for this is that many port/miniport driver do NOT follow the requirement that it set the DataTransferLength to the actual amount of data transferred. This is true, for example, of most ATA, ATAPI, Serial ATA, Serial ATAPI drivers. Instead of returning the amount of data transferred in the DataTransferLength field, they are simply leaving the field unchanged. This could be caused by the driver's inability to know exactly how many bytes were transferred (i.e. hardware limitation).
Most other miniport drivers properly report the number of bytes transferred. Enable this option only if you are working with miniport drivers that handle this properly.
Although we have done our best to explain this defect check above, we do realize that it is a rather complex topic. Please feel free to contact us if you have any questions.