How to trace IRPs between drivers?

I’m doing a live kernel debugging of a driver. I can see that it’s sending an IRP to another driver using IofCallDriver function, and the other driver returns a generic error status code. I need to see where the target driver is failing,

I could get the device object and the parameters of the IRP using !devobj <addr> and !irp <addr> WinDbg commands before IofCallDriver is called.

But how do I trap processing of this IRP on the other end, or in the receiving driver?

Any suggestions will be appreciated.

What do you expect to find out? The other driver is not failing, it’s just returning an error. (Which error?) If you can break in your driver where you call IoCallDriver, you can single step through it until it gets to the target (IoCallDriver isn’t that complicated), and maybe you could set a breakpoint at IoCompleteRequest, but that gets called a lot.

You can also set an access breakpoint (ba) on Irp->IoStatus.Status to see where the driver sets the failure status value. Of course, depending on the way the driver is written this might be very far away from where the error actually originated.

Yep, thanks guys.