NO_MORE_IRP_STACK_LOCATIONS

NTDEV
1

I have a TDI driver that I wrote that is bugchecking with NO_MORE_IRP_STACK_LOCATIONS.

This link was very useful:
http://www.osronline.com/custom.cfm?name=articlePrint.cfm&id=337

However, I still can’t find my problem. When I’m the only filter driver in the stack, everything seems to work fine. However, if another filter driver is installed, everything gets unhappy. I’ve narrowed it down to my TDIReceiveDatagram function (I think). Here’s the code:

TDIReceiveDatagram (…)
{
pLowerDeviceObject = devExt->LowerDeviceObject;
if (Irp->CurrentLocation == 1)
{
Irp->CurrentLocation++;
(Irp)->Tail.Overlay.CurrentStackLocation++;
}
else
{
IoCopyCurrentIrpStackLocationToNExt(Irp);
IoSetCompletionRoute(Irp, myReceiveComplete, devExt, TRUE, TRUE, TRUE);
/* Macro to increment large int */
IncrementInt(devExt->OutstandingIoRequest, (unsigned long) 1, &devExt->SpinLock);
}

KeClearEvent (&devExt->IoInProgressEvent);
val = IoCallDriver(pLowerDeviceObject, Irp);
return (val);
}

Not sure where I’m screwing up the stack, but if anybody has any suggestions, they would be greatly appreciated.

Thanks,
– Jim

2

IIRC NetBT sends IRPs with some hardcoded number of stack locations, so, if there are TDI filters between NetBT and TCPIP, it will BSOD.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
>I have a TDI driver that I wrote that is bugchecking with NO_MORE_IRP_STACK_LOCATIONS.
>
> This link was very useful:
> http://www.osronline.com/custom.cfm?name=articlePrint.cfm&id=337
>
> However, I still can’t find my problem. When I’m the only filter driver in the stack, everything seems to work fine. However, if another filter driver is installed, everything gets unhappy. I’ve narrowed it down to my TDIReceiveDatagram function (I think). Here’s the code:
>
> TDIReceiveDatagram (…)
> {
> pLowerDeviceObject = devExt->LowerDeviceObject;
> if (Irp->CurrentLocation == 1)
> {
> Irp->CurrentLocation++;
> (Irp)->Tail.Overlay.CurrentStackLocation++;
> }
> else
> {
> IoCopyCurrentIrpStackLocationToNExt(Irp);
> IoSetCompletionRoute(Irp, myReceiveComplete, devExt, TRUE, TRUE, TRUE);
> /* Macro to increment large int */
> IncrementInt(devExt->OutstandingIoRequest, (unsigned long) 1, &devExt->SpinLock);
> }
>
> KeClearEvent (&devExt->IoInProgressEvent);
> val = IoCallDriver(pLowerDeviceObject, Irp);
> return (val);
> }
>
> Not sure where I’m screwing up the stack, but if anybody has any suggestions, they would be greatly appreciated.
>
> Thanks,
> – Jim
>

3

I assume your TDI filter is properly attaching and incrementing the
DeviceObject->StackSize. If you are using IoAttachDevice or
IoAttachDeviceToDeviceStack then this should occur automatically.

Is your filter attached above or below the ‘other’ TDI filter?

What is the stack size for the last attached Device Object in the stack?

Does the crash occur if you change the order of the attachment (yours on top
/ yours on bottom)?

I have found that plenty of ‘other’ TDI filters get this wrong and that by
inserting your TDI filter into the stack (even if it does it correctly) it
will cause some other TDI filter to crash. Of course, since your TDI filter
was the last thing installed you get the whiny “well, I installed your
product and it crashed…” with little hope of pointing out that
AV/Firewall Vendor X has a bug in their TDI filter.

As ‘safer’ check than if Irp->CurrentLocation == 1 is to compare the
remaining location count to the locations required by the lower attached
device.

Stylistically I suggest IoSkipCurrentIrpStackLocation() over manipulating
the IRP fields directly. Other’s will more easily recognize what your code
is doing (as might you 3 months from now).

And not that this is related but you can probably get away with an
InterlockedIncrement/Decrement operation on a ULONG for counting outstanding
I/O. Even a WIN64 system is unlikely to get anywhere near 2^32 outstanding
TDI operations.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@ngc.com
Sent: Sunday, July 19, 2009 6:07 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] NO_MORE_IRP_STACK_LOCATIONS

I have a TDI driver that I wrote that is bugchecking with
NO_MORE_IRP_STACK_LOCATIONS.

This link was very useful:
http://www.osronline.com/custom.cfm?name=articlePrint.cfm&id=337

However, I still can’t find my problem. When I’m the only filter driver in
the stack, everything seems to work fine. However, if another filter driver
is installed, everything gets unhappy. I’ve narrowed it down to my
TDIReceiveDatagram function (I think). Here’s the code:

TDIReceiveDatagram (…)
{
pLowerDeviceObject = devExt->LowerDeviceObject;
if (Irp->CurrentLocation == 1)
{
Irp->CurrentLocation++;
(Irp)->Tail.Overlay.CurrentStackLocation++;
}
else
{
IoCopyCurrentIrpStackLocationToNExt(Irp);
IoSetCompletionRoute(Irp, myReceiveComplete, devExt, TRUE, TRUE, TRUE);
/* Macro to increment large int */
IncrementInt(devExt->OutstandingIoRequest, (unsigned long) 1,
&devExt->SpinLock);
}

KeClearEvent (&devExt->IoInProgressEvent);
val = IoCallDriver(pLowerDeviceObject, Irp);
return (val);
}

Not sure where I’m screwing up the stack, but if anybody has any
suggestions, they would be greatly appreciated.

Thanks,
– Jim

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

Thanks Dave and Maxim.

I’ll look into this and let everyone know what I find. Thanks again.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Monday, July 20, 2009 7:49 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NO_MORE_IRP_STACK_LOCATIONS

I assume your TDI filter is properly attaching and incrementing the
DeviceObject->StackSize. If you are using IoAttachDevice or
IoAttachDeviceToDeviceStack then this should occur automatically.

Is your filter attached above or below the ‘other’ TDI filter?

What is the stack size for the last attached Device Object in the stack?

Does the crash occur if you change the order of the attachment (yours on
top / yours on bottom)?

I have found that plenty of ‘other’ TDI filters get this wrong and that
by inserting your TDI filter into the stack (even if it does it
correctly) it will cause some other TDI filter to crash. Of course,
since your TDI filter was the last thing installed you get the whiny
“well, I installed your product and it crashed…” with little hope of
pointing out that AV/Firewall Vendor X has a bug in their TDI filter.

As ‘safer’ check than if Irp->CurrentLocation == 1 is to compare the
remaining location count to the locations required by the lower attached
device.

Stylistically I suggest IoSkipCurrentIrpStackLocation() over
manipulating the IRP fields directly. Other’s will more easily
recognize what your code is doing (as might you 3 months from now).

And not that this is related but you can probably get away with an
InterlockedIncrement/Decrement operation on a ULONG for counting
outstanding I/O. Even a WIN64 system is unlikely to get anywhere near
2^32 outstanding TDI operations.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@ngc.com
Sent: Sunday, July 19, 2009 6:07 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] NO_MORE_IRP_STACK_LOCATIONS

I have a TDI driver that I wrote that is bugchecking with
NO_MORE_IRP_STACK_LOCATIONS.

This link was very useful:
http://www.osronline.com/custom.cfm?name=articlePrint.cfm&id=337

However, I still can’t find my problem. When I’m the only filter driver
in the stack, everything seems to work fine. However, if another filter
driver is installed, everything gets unhappy. I’ve narrowed it down to
my TDIReceiveDatagram function (I think). Here’s the code:

TDIReceiveDatagram (…)
{
pLowerDeviceObject = devExt->LowerDeviceObject; if (Irp->CurrentLocation
== 1) {
Irp->CurrentLocation++;
(Irp)->Tail.Overlay.CurrentStackLocation++;
}
else
{
IoCopyCurrentIrpStackLocationToNExt(Irp);
IoSetCompletionRoute(Irp, myReceiveComplete, devExt, TRUE, TRUE,
TRUE);
/* Macro to increment large int */
IncrementInt(devExt->OutstandingIoRequest, (unsigned long) 1,
&devExt->SpinLock); }

KeClearEvent (&devExt->IoInProgressEvent); val =
IoCallDriver(pLowerDeviceObject, Irp); return (val); }

Not sure where I’m screwing up the stack, but if anybody has any
suggestions, they would be greatly appreciated.

Thanks,
– Jim

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer