Windows supports a wide variety of storage class devices such as hard drives, 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, Serial ATA, Fibre Channel, 1394, USB, iSCSI, SAS, RAID, 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 option, you are configuring busTRACE to capture all storage class I/O activity on the computer.

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.

The ability to capture low-level USB bus activity is not available when running under Windows Me.

At the bottom of the Configuring busTRACE 6.0 window, you are given the option to enable or disable our advanced filtering option. Default is to have the option enabled.

The Windows operating system communicates with your devices through a layered driver model called the Windows Driver Model (WDM). I/O Request Packets (IRPs) are built and then sent down through this layered model. As an IRP travels down through each driver layer, it might get modified as it goes on down. busTRACE is fully compliant with this model. We insert ourselves at the lowest point possible within this layered model, to ensure that we are seeing the actual requests being sent to a device. This gets us as close to the hardware as possible and allows us to perform our low-level bus analysis.

So what is this advanced filtering option? Some older drivers do not obey the rules of the Windows Driver Model. They bypass the layered model (also referred to as the I/O stack) and send their I/O requests directly to the controller / port driver. This is typically done by "legacy" drivers that have not yet been updated for Windows 2000 compliance. If a driver bypasses the I/O stack, busTRACE would normally not see the I/O being generated by that device.

That is where our advanced filtering comes in. In its enabled state, 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.