busTRACE can capture and analyze I/O activity in one of two ways. One is with "Live" capture analysis enabled; the other is with it disabled.

When busTRACE capture is active, and live capture analysis is enabled, you can view I/Os being captured as they occur. You can scroll around and view any I/Os of interest. Any I/Os that are captured are simply appended to the I/O Capture List automatically.

When busTRACE capture is active, and live capture analysis is disabled, you are not allowed to view I/O activity until after you stop the capture process. Once the capture process is stopped, all of the I/O activity captured up to that point will then appear.

Typically you will leave this feature enabled. However, there are times where you might want to disable the feature:

• Disabling this feature gives you the lowest busTRACE CPU overhead. If you are concerned about any impact capturing I/O activity will have on a performance test you're running, simply disable this feature. When disabled, busTRACE simply captures the I/O results down in kernel mode and then lets the I/O continue on its way.
• If live capture analysis is enabled, the system could theoretically generate I/O faster than busTRACE can process it. For example, fast hard drives being sent a large quantity of I/O activity at a given time. In such a case, busTRACE may automatically stop the capture process and notify you that the system is generating I/O faster than it can process it. In this case, you can simply disable live capture analysis and the problem will not occur again.

When you click on this field, you are shown a slider where you can adjust the busTRACE capture buffer size. The larger the buffer, the more I/O activity you will be able to capture. The amount of memory busTRACE will allow you to allocate depends on how much memory you have in your computer.

busTRACE uses a circular buffer. That is, when the capture buffer gets full, older I/Os are removed from memory to make room for newer I/O activity. By placing a checkmark next to this option, you are informing busTRACE that you want it to automatically stop the capture process when the buffer is full.

You can configure busTRACE to compress the captured data in memory. Depending on the type of data being captured, this will usually require less memory stored per each I/O. This, in turn, allows you to capture even more I/O activity into memory. This feature is only available when live capture analysis is enabled.

This option will only appear if you are performing a remote capture. Having this option enabled will cause busTRACE to compress the capture data before sending it across your network.

Here, you specify when you want busTRACE to perform the additional enumerations.

busTRACE can optionally perform a Windows Management Instrumentation (WMI) query and save the results with the busTRACE capture file. WMI is fully detailed on Microsoft's WEB site. Simply perform a WEB search for "Microsoft WMI".

You can select the WMI query to perform by selecting this option. A dialog box is brought up where you can create your WMI query and see the results of the query on the target system. This option only appears after placing a checkmark on the "Perform WMI Query" option.

Selecting this option causes busTRACE to enumerate and cache each device's kernel DEVICE_OBJECT structure.

Selecting this option causes busTRACE to enumerate and cache each device's I/O stack entries.

Selecting this option causes busTRACE to enumerate and cache each device's registry properties.

You can select this option to exclude certain I/Os from being captured. You can excluded I/Os based on their CDB, SRB Function, URB Function, or IRP Function.

Each I/O that is occurring within your system might transfer a large amount of data. For example, let's say an I/O is sent to read 128 blocks from the hard drive. Blocks typically store 512 bytes. That would mean that the system is attempting to read 512*128 bytes which is 64K. busTRACE can capture the entire data, if so configured.

You may find that you are not interested in storing the entire amount of data transferred with each I/O. Perhaps you are only interested in the first 16 bytes or no data at all. Perhaps you're only looking for error information and do not care about the data.

Simply enter the maximum number of bytes you would like captured per I/O. The smaller the value, the more I/O activity busTRACE will be able to capture into memory (as less space would be used to store any data transferred). busTRACE defaults to storing up to the first 512 bytes of transfer in the capture buffer (2048 for CD/DVD/BD devices).

You can enter the data in hex format if you like. Simply append the data with 'h'. For example, to submit 256 decimal bytes as the value, in hex, you would enter 100h.

When an IOCTL is submitted to a device object, some of the inbound and/or outbound data is irrelevant. Capturing that data provides no value to the user. By selecting this option, on specific IOCTLs, if busTRACE detects this condition, it will only capture the pertinent data.

Select this option if you want busTRACE to enumerate the driver (kernel IRP) or process (user mode IRP) that generated the I/O.

Select this option if you want busTRACE to enumerate the class driver for this I/O.

Select this option if you want busTRACE to enumerate the NUMA Node the I/O is running on (e.g. IRP's data buffer and processing CPU).

This feature can only work if you have our Advanced Filtering feature enabled.

Windows storage port drivers (e.g. STORPORT.SYS, ATAPI.SYS, USBSTOR.SYS, etc.) can be sent two types of requests. One is a SCSI Request Block (SRB). SRBs allow another device driver to send down a request to a device. The other is a SCSI Pass Through IOCTL (SPTI). SCSI Pass Through IOCTLs are accessible to ring 3 applications that want to send down a CDB to a storage device. busPROBE, for example, uses SCSI Pass Through IOCTLs to send CDBs.

When a port driver receives a SCSI Pass Through IRP, many will internally create an SRB IRP and send it to the device. The contents of the SRB IRP are usually identical to the SCSI Pass Through IRP. It is for this reason that busTRACE defaults to only showing you the SCSI Pass Through IRP.

If you place a checkmark on this option, busTRACE will attempt to capture any SRB IRPs that are being created in order to process the SCSI Pass Through IRP. Our ability to do this is dependent on the port driver.

Select this option if you want busTRACE to capture the IRP structure.

Select this option if you want busTRACE to capture the entire I/O stack contents (for all drivers in the stack). The stack contents are copied copied both going down and back up the I/O stack. This can be useful if you want to see which drivers insert themselves into the I/O stack for the given IRP.

When busTRACE is active capturing I/O activity, this setting lets busTRACE know what it should do when new devices appear while the capture is active. Placing a checkmark on this option will cause busTRACE to automatically capture I/O activity on the new devices. Removing the checkmark will tell busTRACE to ignore any new devices added while the capture is active.

When busTRACE is busy capturing I/O activity, you normally cannot exit busTRACE with the capture active. However, if you have live capture analysis disabled, and you try and exit busTRACE, you will see a Capture and Exit option:

By selecting the Capture and Exit option, the busTRACE application will close but leave the kernel driver active capturing I/O activity. In this configuration, there is no application running. Only the kernel driver is active. When you re-run busTRACE, the capture process will continue and you can stop and save the capture results.

NOTE: Event Log activity is only captured while the busTRACE capture application is running. While in Capture and Exit mode, event log activity will not be captured.

To enable trigger points, you start by placing a checkmark on this option. Once you do so, the remaining trigger point options will appear.

You can configure busTRACE as to what it should to do when a trigger point occurs. You can have it automatically stop the capture and optionally block further I/O from reaching the device. If you want to try and keep the system in its current state, you can also force a bug check.

Place a checkmark on this option if you want any failed I/O to set a trigger point.

Here you can specify an I/O submission that would cause a trigger point. You can configure the trigger point based on its CDB, SRB Function, URB Function, or IRP Function.

Here you can specify an I/O completion that would cause a trigger point. You can configure the trigger point based on its sense code, execution time, SRB Status, SCSI Status, or URB Status.

Here you can specify an input or output trigger point on a given COM port. If using an output trigger, any time busTRACE detects a trigger point, it will set the RTS line on the specified RS-232 port. If an input trigger is configured, if the CTS line on the specified RS-232 COM port is set, a busTRACE trigger point will be set.

It the setting is disabled within busTRACE, this indicates that no serial ports were detected on the system.

To enable the automatic e-mail notification feature, you start by placing a checkmark on this option. Once you do so, the remaining options will appear.

Place a checkmark on this option if you want an e-mail sent out any time a trigger point is detected.

Place a checkmark on this option if you want busTRACE to e-mail you periodic status reports.

If you enabled Periodic status reports, specify the frequency of the status reports here.

Here you specify the e-mail message to send out, who to send it too, its message subject, and its message body.