Windows supports a wide variety of storage class devices such as HDDs, SSDs, tape drives, CD/DVD drives, jukeboxes, and more. To communicate with these devices, Windows drivers build up SCSI Request Blocks (SRBs). Do not be confused by the term "SCSI" within the term SCSI Request Block. SRBs are used to communicate with devices across a wide variety of bus architectures including SCSI, ATAPI, ATA, SATA, Fibre Channel, 1394, USB, iSCSI, SAS, RAID, PCIe, and more. Details on the SRB structure can be found in Microsoft's Windows Driver Development Kit.

Embedded within an SRB is a Command Descriptor Block (CDB). A CDB defines the command and its options being sent to a device (e.g. Test Unit Ready, Request Sense, etc.). The device's command specifications define which commands are supported and their behavior. Command specifications are typically available through industry standards organizations such as the Incits T10 Technical Committee (http://www.t10.org).

By placing a checkmark next to this tree's sub-items, you are configuring busTRACE to capture all storage class I/O activity on the specified bus architectures.

Windows supports a wide variety of USB devices such as keyboards, mice, cameras, network adapters, hard drives, and more. With the proper software, there are no limits as to the types of USB devices you can hook up to your computer. USB software drivers set up USB Request Blocks (URBs) to send requests to the USB controller driver which then sends them to the actual USB device. The URB structure defines a format for all possible commands that can be sent to a USB device.

By placing a checkmark next to this option, you are configuring busTRACE to capture all low-level USB I/O activity on the computer.

busTRACE is especially powerful if you want to capture I/O activity on a USB storage class device such as a flash drive or CD/DVD device. Not only will you be able to see all the SRBs/CDBs being sent to the device, but also the underlying URBs that will be built and sent to process the SRBs/CDBs.

Some older Windows device drivers bypass the normal driver layered model of Windows and send their I/O requests directly to the controller / port driver. If a driver bypasses the I/O stack, busTRACE would normally not see all the I/O being send to the device. With advanced filtering enabled, we look for drivers that bypass the I/O stack and ensure that we are able to capture their I/O activity. You should not need to disable this option.

This options is for use by busTRACE technical support. The option should be left disabled.

This options is for use by busTRACE technical support. The option should be left disabled.

Enabling this option will cause busTRACE to enumerate and cache the IDENTIFY page for any ATA/SATA/ATAPI devices.

Enabling this option will cause busTRACE to send an Inquiry CDB to each detected storage device and cache the results in the busTRACE capture file. The decoded CDB can be seen in the System Explorer. The information collected here can also be used to help busTRACE decode other captured CDBs.

Enabling this option will cause busTRACE to enumerate and cache all the device's VPD pages. Please note that busTRACE will only enumerate the VPD pages if the device reports itself as SPC-2 (or greater) compliant.

Enabling this option will cause busTRACE to send a Security Protocol In - Supported Security Protocol List CDB to each detected storage device and cache the results in the busTRACE capture file. The decoded CDB can be seen in the System Explorer. The information collected here can also be used to help busTRACE decode other captured CDBs. This CDB is only sent if busTRACE detects the device is SPC-4 (or higher) compliant.

Enabling this option will cause busTRACE to cache the IEEE-1667 Probe Silo on any device where such support is detected. The decoded CDB can be seen in the System Explorer. The information collected here can also be used to help busTRACE decode other captured CDBs.

Enabling this option will cause busTRACE to enumerate all of the USB descriptors present in each detected USB device. The decoded USB descriptors can be seen in the System Explorer. The information collected here can also be used to help busTRACE decode other captured USB Request Blocks.