All I/O operations in Windows are described by an I/O Request Packet (IRP). If you’re familiar with IRP handling, you already know that there is a fixed part of the IRP and also a variable length part of the IRP. This variable-length part of the IRP contains all the IRP’s I/O stack locations.

When an I/O request is issued, the I/O Manager (or a kernel-mode driver) allocates an IRP with at least as many I/O stack locations as there are drivers that it thinks will need to handle the request. The number of stack locations in the IRP defines the maximum number of devices that will be allowed to handle the request.

When an IRP is allocated either by the I/O Manager or a driver, the StackSize member of the target DeviceObject is used to determine the number of stack locations that are needed for the IRP. In other words, the StackSize member reflects the number of devices that are logically in the stack that is going to process this request. If an IRP with too few I/O stack locations is allocated, when an attempt is made to forward the IRP on to a lower device and all of the stack locations have been exhausted, the system bugchecks with NO_MORE_IRP_STACK_LOCATIONS.

All drivers in the system are responsible for maintaining the StackSize member of the device objects they create. Drivers do this by ensuring that whenever they attach one of their devices above any other device, the driver sets their device object’s StackSize to that of the of lower device object’s, plus one. If any driver in the chain breaks this, its error bubbles up the stack and the StackSize of all the higher devices in the stack will be off. Note that the standard DDI used to attach one device to another, IoAttachDeviceToDeviceStack, takes care of updating this member for the attaching device. Therefore, one of these bugchecks usually indicates one of three things:

1) There is a driver in the system that tried to do something clever to add its device to the device stack.

2) A driver allocated an IRP with too few stack locations and passed it on to another driver.

3) A driver took an IRP it received and "jumped stacks." In other words, it did not pass it directly to the device it attached to but to some other device.

The first parameter to the bugcheck code is a pointer to the IRP which has run out of stack locations. Supplying the IRP’s address to the !irp command will show all of the devices that have so far processed the IRP. Using this information, you will need to examine all of the device objects in the stack, paying attention to their StackSize members. As you examine the StackSize values, look for a device whose StackSize value is equal to or less than the StackSize of the device below it. If you find such a device, you will potentially have found the portion of the stack where the offending driver exists. Note that because a driver relies on the driver below it following the rules and doing the right thing, the broken driver is not always obvious.

If the entire stack seems to be in order in terms of its StackSize values, the culprit of the bugcheck may be the driver that allocated the IRP. If the driver had ignored the StackSize member of the target device object and did not allocate enough stack locations for the entire stack, it would lead to this bugcheck even though the drivers in the system were following the rules.

If the offending driver is your driver, then fix it! However, if you are, for example, a filter driver and it is a driver above you that is broken, then you really have two choices:

1) Harass the developer of the driver until they fix it.

2) Allocate a new IRP with the correct number of stack locations and pass that on to the lower driver. When that IRP completes, you would then need to adjust the original IRP to reflect the result of the duplicate IRP and complete the original IRP.

Of course there may be some other solutions based on your particular situation, but the above two are globally applicable.

Here’s an example of the steps you can take to try to find the driver in the stack that has broken the StackSize rules.

Well, THAT certainly doesn’t look right. It would appear that in this case, the FSRecognizer device is the culprit, because he was the first to break the chain of its device’s StackSize being that of the lower driver plus one. But, c’mon, debugging is never that easy!

It turned out in this case that FilterA was actually at fault, because it had reused its device object. At an earlier point, the filter had attached itself to a stack with a single device object, which left FilterA’s StackSize at two. The FSRecognizer driver then came along and attached itself to FilterA, leaving FSRecognizer’s StackSize at three. FilterA then detached its device object from the original stack (IoDetachDevice) and reattached its device to another stack with IoAttachDeviceToDeviceStack. As we learned earlier, this routine sets the attaching device’s StackSize member to that of the lower device’s plus one. Note that it does nothing to the StackSize values of device object’s attached above the attaching device.

On the new stack, the lower device’s StackSize was eight, making FilterA’s StackSize nine. But, because the filter played this little trick, the FSRecognizer never realized that it had been moved from one stack to another and so it still had the old StackSize value. When FilterB came along, it did the right thing and set its StackSize to the lower driver’s plus one. Unfortunately, the stack was already horribly broken at that point and was doomed to blue screen.