If you have enabled Extended IRP Capture, busTRACE will capture and decode for you important information about the I/O Request Packet (IRP) in the Extended IRP Capture tab. busTRACE takes a snapshot of key data structures as they go down the I/O stack and back up the I/O stack (the I/O stack concept was discussed in the Raw Data section).

In the screenshot above, you can see the IRP stack contents for our captured IRP as the IRP goes back up the I/O stack. We can see that the IRP first went through ntfs.sys, then volmgr.sys, then partmgr.sys, then disk.sys, then our busTRACE capture driver bustrce8.sys, and lastly to the Intel iastor.sys port driver.

At the top of the window, a toolbar is available with various options.

	Selecting this option will copy the data structure, in text format, to the clipboard. You can use this feature to quickly copy and paste the extended IRP capture information into another document. Alternatively, you can simply right click anywhere in the window and choose the Copy option to copy the data to the clipboard.
	busTRACE takes a snapshot of IRP data going down the I/O stack, and then going back up the I/O stack. You can use these toolbar buttons to select which structure you would like to see. This is a fast and easy way to view any changes that occur to the IRP data as they go down and back up the I/O stack.
	These options behave the same as they do for the Raw Data tab.
Flip I/O Stack	By default, busTRACE shows you the I/O stack in the order that it is stored in memory and also the way the !irp command works in Microsoft's WinDbg debugger. This means that the top of the I/O stack actually appears at the bottom of the display. If you prefer, you can flip the orientation by clicking on this button.
Settings	Clicking on this button will take you to our Capture Settings where you can enable or disable our Extended IRP Capture feature.

Details

Windows uses IRPs (I/O Request Packets) to initiate an I/O request. The Windows I/O manager gives each driver in a chain of layered drivers an I/O stack location for every IRP that it sets up. Each I/O stack location consists of an IO_STACK_LOCATION structure. Please refer to the Windows Driver Kit (WDK) for details on this structure.

With Extended IRP Capture enabled, busTRACE takes a snapshot of the I/O stack values as the IRP goes down the I/O stack as well as when it goes back up the I/O stack. To help you understand the values we show, we'll walk through a sample disk I/O capture. The IRP that we have captured has setup four I/O stack locations (for the four drivers that make up the chain of layered drivers). Not all of these drivers may use their stack location. They may not be interested in the IRP, not use their stack location, and simply pass the IRP on down the I/O stack. In this sample screenshot below, we have captured an IOCTL going to a RAID hard drive that is attached to our system:

In looking at the screenshot above, we notice that busTRACE has captured and is showing four I/O stack locations. Only two of the locations are currently in use. The I/O stack is displayed in the order it is stored in memory. This is important as the top of the I/O stack is actually at the bottom of our display. If you prefer to display the topmost I/O stack location at the top of our display, you can click on the Flip I/O Stack toolbar button.

The first stack location is displayed as "Stack Location #4 of 4 (\Driver\disk)". This tells us that the topmost stack location is in use by a \Driver\disk device object. We provide four pieces of information for each cached I/O stack location:

• MajorFunction, Minor Function: For this field, we display the I/O stack location's MajorFunction and MinorFunction. The IRP major function code indicates the type of I/O operation to be performed. The MinorFunction indicates a subfunction for the MajorFunction. The PnP manager, power manager, file system drivers, and SCSI class drivers set this member for some requests. Where possible, in addition to displaying the numerical value, we will also display the function name. In our sample above, we note that this is an IRP_MJ_DEVICE_CONTROL I/O stack location. You may also note that in Stack Location #3 of 4, a '>' greater than sign appears just to the left of the MajorFunction and Minor Function. We use this indicator to let you know that this was the active stack location when the IRP was captured. In our sample, we note that the busTRACE device object was active when the IRP was captured.
• DeviceObject: For this field, we display the I/O stack's DeviceObject pointer (i.e. PDEVICE_OBJECT) in hex. If we have additional details about the driver that created this device object, we will show you the name of the driver appended after the hex value. In addition, the DeviceObject tree item can be expanded to provide additional details about the driver. In our sample, we see that I/O stack location #4 is in use by the disk.sys driver.
• CompletionRoutine: For this field, we display the I/O stack's CompletionRoutine pointer in hex. A driver's CompletionRoutine callback function executes when another driver completes a specified I/O request. Like the DeviceObject, if we know which driver this completion routine would execute in, we will show you the name of the driver appended after the CompletionRoutine hex address. If the driver is recognized by busTRACE, the CompletionRoutine tree item can be expanded to provide additional details about the driver. In our sample, we see that no completion routines have been set yet.
• Args: Each I/O stack location has a "union" of I/O parameters. Please refer to Microsoft's WDK for details on this "Parameters" union. The last entry in this union are four PVOID arguments. For this field, we show you the hex values for these four arguments.

In the above sample, the IRP was traveling down the I/O stack and no completion routines were set yet. Now let's look at the same I/O stack as the IRP is going back up the I/O stack:

Now we see that three of the available four I/O stack locations were used. Stack Location #2 of 4 is a \Driver\HpCISSs2 device object created by the hpcisss2.sys miniport driver. Also note the CompletionRoutine of bustrce8.sys. That is our busTRACE kernel driver. This shows us that when the HpCISSs2 miniport driver completes the IRP, our bustrce8.sys kernel driver will be notified of the completion.

There are times where busTRACE has captured the I/O stack but you want to learn more about the device driver that created the device object, or is handling the completion callback routine. We can expand out the hpcisss2.sys DeviceObject (as one example) to learn more about the driver the created the device object:

Now we can clearly see that this driver was created by Hewlett-Packard and is their Smart Array SAS/SATA Controller Storport Driver. The version is 6.12.4.32 Build 1. Attached to our system, is an HP Smart Array P400 RAID Controller.

By looking at the I/O stack, we can see which drivers have inserted themselves into the chain of layered drivers that processed the IRP.

See Also:

• busTRACE Screen Layout
• Error Analysis
• CDB View 1 / CDB View 2
• Raw Data
• Data Structures