This web page refers to our older busTRACE 7.0 which is no longer shipping. Click here for details on our latest generation busTRACE software.

busTRACE This WEB page comes from the busTRACE 7.0 User's Manual. (Table of Contents)

Previous Topic Next Topic

This section describes the I/O Handling configuration options available within busTRACE.

General Settings

Perform automatic data corruption analysis when capture stops

Place a checkmark on this option to configure busTRACE to automatically perform a data corruption analysis each time you stop the capture process.

Report overruns / underruns as errors

An overrun occurs if a device wants to send or receive more data than is available in the data buffer. This error should never occur unless there is a bug in the software that generated the I/O request. An underrun, on the other hand, is common. What this means is that the device wants to send or receive less data than is specified in the data buffer. This is usually by design. For example, perhaps the caller knows that the device will return up to 600 bytes, but no more than 600 bytes, so it sends down a buffer length of 600. The device may only return 350 bytes. The caller expected this and can look within the returned data stream to determine the actual amount of data returned. Within the Windows operating system, both of these errors are grouped together as one error. Unfortunately, analyzing bus activity is complicated by the fact that the OS reports an underrun as an error. If we place an error indicator on the screen, it may distract you from what you're really looking for. By removing the checkmark on this option, you can force busTRACE to not report overruns / underruns as errors. This is the default setting.

NOTE: This option only applies to SCSI Request Blocks (SRBs).

Check for software defects in SCSI requests

Place a checkmark on this option if you want busTRACE to automatically check for software defects in captured SRB/CDB requests.

Track mouse movements over interleaved I/O activity

If busTRACE is configured to show you interleaved I/O activity, leaving a checkmark on this option will cause busTRACE to highlight the point where the I/O starts (i.e. going down the I/O stack) as well as where the I/O finishes (i.e. going up the I/O stack). A gradient background color is used to visually show you where the I/O starts, where it finishes, and what other I/O activity might be occurring in between.

This feature is only available when you have busTRACE configured to sort I/O activity on the Counter column in ascending order (the default setting).

Show single interleave indicator for lifetime of one I/O request

For some I/O activity, such as MPIO or some USB activity, the same I/O Request Packet (IRP) is used and captured multiple times. For example, with MPIO, you may have a IRP sent to a virtual device and then that same IRP sent to a physical device. Once the physical device IRP completes, the virtual device IRP completes.

This option configures busTRACE as to how you want the interleave indicators draw. With this option disabled, if you have the same IRP being used for a virtual and physical device (as one example), you would see something like this:

In the above example, you can see how I/O counter 778 is wrapped by I/O 777. You can also see by the "IRP Pointer" value, this is the exact same IRP.

If you take this exact same example, but this time place a checkmark next to this "Show single interleave indicator for lifetime of one I/O request" setting, you will see this:

In the above example, we notice that the "Interleave" column now only shows one indicator line for the one IRP that is being processed. The red indicator for I/O #778 allows you to see the wrapped nature of the captured I/O request.

Understanding how the same IRP is sent from one device stack down to another device stack is a complex topic. The above example is its simplest form but can get far more complex, particularly with MPIO. If you are uncertain, you can simply leave this option disabled and you will see an arrow indicator for each individual I/O.

LBA and Sector Count Display Settings

Display values as hex

Choose this option if you want all LBA and Sector Count information display as hex.

Display values as decimal

Choose this option if you want all LBA and Sector Count information display as decimal.

Always export as decimal to CSV or XML file

Place a checkmark on this option if you always want LBA and Sector Count information exported as decimal to CSV or XML files. This feature is useful since Spreadsheet programs do not have a built-in "hex" data type.

Data Length Analysis (CDB Decoding)

When a Command Descriptor Block is sent to a device, the device might not transfer the full data buffer. As an example, you can send an Inquiry CDB through Windows with a 252 byte buffer, but the device may only return 36 bytes of valid data. This is an example of an underrun where the device returns less data than what was specified in the data buffer. It is not an error and happens quite regularly.

Windows clearly defines that port/miniport drivers are supposed to let drivers and applications know the actual amount of data transferred. Unfortunately, a variety of such drivers do NOT properly return the amount of data transferred. Using our Inquiry example above, the port/miniport driver should return that only 36 bytes of data were transferred. However, it is common to see the port/miniport driver incorrectly return that 252 bytes of data were transferred.

This poses challenges for our CDB decoding engine as we need to know how much of the data, in the captured data buffer, is actually valid. Since we cannot fully trust the data transferred length (as returned by the port/miniport driver), we have provided several options to allow you to configure busTRACE.

Automatic - Let busTRACE determine data length (default setting)

Selecting this option lets busTRACE determine how best to determine how much data is actually valid to decode.

Analyze Data - Use length determined by analyzing data buffer

Selecting this option will cause busTRACE to, where possible, look at any CDB values and/or data headers to let the device tell us how much of the data is actually valid.

Port/Miniport - Use length returned by port/miniport driver

Selecting this option tells busTRACE to use the amount of data transferred as reported by the port/miniport driver. If your port/miniport driver is not properly returning this value, you may see the CDB decoded with more data than was actually transferred.

See Also: