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

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).

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

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).

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 1162 is wrapped by I/O 1161. 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 #1162 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.

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

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

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.