IRP Stack size issue with TDI driver

NTDEV
1

Hello All,

I am getting bugcheck 35 (No_MORE_IRP_ STACK_LOCATION) when my TDI driver is intalled over \Device\Tcp if 2 TDI device objects already present in the device stack.

I found out that default IRP stack size for AFD.SYS is 4 thats why IRP sent by AFD.SYS has only 4 stack locations. So only 2 TDI filter drivers can be installed over Tcp. (Afd->Tdi1->Tdi2->Tcp)

I added DWROD:IrpStackSize at HKLM\CurrentControl Set\Services\ Afd\Parameters and set it to 5 then problem got solved, but I do not think this is the right solution.

Can you please suggest what should be the right solution for this problem? How should I handle IRP received from Afd.sys when its stack size is less than the actual device stack?

Thanks
Abhay

Luggage? GPS? Comic books?
Check out fitting gifts for grads at Yahoo! Search.

2

You have only two choices:

  1. Do not ‘filter’ the IRP by calling IoSkipCurrentIrpStackLocation() &
    IoCallDriver(). Obviously in this case you cannot have a completion routine
    since you don’t have a stack location.

  2. Create a new IRP (a ‘repeater’ IRP) and copy the request parameters from
    the original IRP to the new IRP making sure to complete the original IRP
    when the repeater IRP is completed.

Good Luck,
Dave Cattley
Consulting Engineer
System Software Development

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of soni singh
Sent: Wednesday, July 25, 2007 8:32 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] IRP Stack size issue with TDI driver

Hello All,

I am getting bugcheck 35 (No_MORE_IRP_ STACK_LOCATION) when my TDI driver is
intalled over \Device\Tcp if 2 TDI device objects already present in the
device stack.

I found out that default IRP stack size for AFD.SYS is 4 thats why IRP sent
by AFD.SYS has only 4 stack locations. So only 2 TDI filter drivers can be
installed over Tcp. (Afd->Tdi1->Tdi2->Tcp)

I added DWROD:IrpStackSize at HKLM\CurrentControl Set\Services\
Afd\Parameters and set it to 5 then problem got solved, but I do not think
this is the right solution.

Can you please suggest what should be the right solution for this problem?
How should I handle IRP received from Afd.sys when its stack size is less
than the actual device stack?

Thanks
Abhay

Luggage? GPS? Comic books?
Check out fitting gifts
http:mail&p=graduation+gifts&cs=bz> for grads at Yahoo! Search. — Questions?
First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</http:>

3

To be honest, the whole thing seems to be pretty bizzare…

When driver X sends IRP to driver Y, it cannot and should not make any pre-defined (i.e. hardcoded,
obtained from the registry,etc) assumptions about the stack size of the target device. Therefore, I don’t really think MSFT-provided AFD.SYS would do something like that. Instead, I would rather suspect third-party drivers. Are you sure it is not one of those two filters that you have mentioned whi is a culprit here???

Can you please suggest what should be the right solution for this problem?

Debug the problem and analyze who is responsible for it. If you discover that this is third-party TDI filter who is responsible for this behaviour (and I am pretty sure this is the case here), contact the vendor and demand fixing their crap - don’t even think about adjusting your driver to its possible presence on the target machine…

Anton Bassov

4

While I know next to nothing about TDI filters, those of us who have been
doing file system filters since the NT4 days and before are VERY familiar
with IRP stack sizes “hard coded” in the registry for Microsoft drivers
(srv.sys). So I have no doubt that “MSFT-provided AFD.SYS” might do
something like that.

AFAIK, this is still true for SRV, although the default is much more
reasonable than it used to be.

The reason for using the predefined size is that it uses a preallocated pool
of IRPs out of a (perhaps silly) worry about performance.

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, July 25, 2007 8:08 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] IRP Stack size issue with TDI driver

To be honest, the whole thing seems to be pretty bizzare…

When driver X sends IRP to driver Y, it cannot and should not make any
pre-defined (i.e. hardcoded, obtained from the registry,etc) assumptions
about the stack size of the target device. Therefore, I don’t really think
MSFT-provided AFD.SYS would do something like that. Instead, I would rather
suspect third-party drivers. Are you sure it is not one of those two filters
that you have mentioned whi is a culprit here???

Can you please suggest what should be the right solution for this
problem?

Debug the problem and analyze who is responsible for it. If you discover
that this is third-party TDI filter who is responsible for this behaviour
(and I am pretty sure this is the case here), contact the vendor and demand
fixing their crap - don’t even think about adjusting your driver to its
possible presence on the target machine…

Anton Bassov

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

5

> While I know next to nothing about TDI filters, those of us who have been

doing file system filters since the NT4 days and before are VERY familiar
with IRP stack sizes “hard coded” in the registry for Microsoft drivers
(srv.sys). So I have no doubt that “MSFT-provided AFD.SYS” might do
something like that.

Please note that AFD.SYS in *NOT* on the same stack with \Device\Tcp and friends - instead, it is
just TDI client who builds all its requests with TdiBuildInternalDeviceControlIrp() -TdiBuildxxx()sequence ( the former is just a macro that passes all arguments to IoBuildDeviceIoControlRequest(), and the latter is a macro that sets up IRP’s next stack location) , and passes them to the target device.

As you can see, the concept of pre-defining stack locations hardly applies to it…

Anton Bassov

6

Thanks everybody for your reply.
Our debugging shows that probelm is with AFD.sys (TDI Client), because when we change the registry entry “HKLM\SYSTEM\CurrentControlSet\Services\AFD\Parameters\IrpStackSize” from 4 to 5 it solves our problem. It means these is a Max. limit on IrpStackSize allocated by AFD. I also noticed that when there are 2 or 1 TDI filter driver above TCP, AFD computed the Irp Stack size correctly ( that is 4 or 3). But when one more TDI filter driver is coming on that stack it is still showing the stack as 4 (instead of 5). It means there is some relation between Max. stack size allocated by AFD and the one defined in the registry. Any suggestion will be appreciated.

Thanks
Soni
xxxxx@hotmail.com wrote:
> While I know next to nothing about TDI filters, those of us who have been

doing file system filters since the NT4 days and before are VERY familiar
with IRP stack sizes “hard coded” in the registry for Microsoft drivers
(srv.sys). So I have no doubt that “MSFT-provided AFD.SYS” might do
something like that.

Please note that AFD.SYS in *NOT* on the same stack with \Device\Tcp and friends - instead, it is
just TDI client who builds all its requests with TdiBuildInternalDeviceControlIrp() -TdiBuildxxx()sequence ( the former is just a macro that passes all arguments to IoBuildDeviceIoControlRequest(), and the latter is a macro that sets up IRP’s next stack location) , and passes them to the target device.

As you can see, the concept of pre-defining stack locations hardly applies to it…

Anton Bassov

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

Yahoo! oneSearch: Finally, mobile search that gives answers, not web links.

7

And SRV.sys is not on the same stack with filesystems. But it creates a
pool of IRPs when it starts, using a registry parameter to determine how
many stack locations they should have. If you add too many file system
filter drivers, you have trouble.

A quick google search makes it appear that AFD.sys does exactly the same
thing.

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, July 25, 2007 9:55 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] IRP Stack size issue with TDI driver

While I know next to nothing about TDI filters, those of us who have
been doing file system filters since the NT4 days and before are VERY
familiar with IRP stack sizes “hard coded” in the registry for
Microsoft drivers (srv.sys). So I have no doubt that “MSFT-provided
AFD.SYS” might do something like that.

Please note that AFD.SYS in *NOT* on the same stack with \Device\Tcp and
friends - instead, it is just TDI client who builds all its requests with
TdiBuildInternalDeviceControlIrp() -TdiBuildxxx()sequence ( the former is
just a macro that passes all arguments to IoBuildDeviceIoControlRequest(),
and the latter is a macro that sets up IRP’s next stack location) , and
passes them to the target device.

As you can see, the concept of pre-defining stack locations hardly applies
to it…

Anton Bassov

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

8

> when we change the registry entry

“HKLM\SYSTEM\CurrentControlSet\Services\AFD\Parameters\IrpStackSize” from 4 to 5
it solves our problem.

Actually, I checked the above mentioned key, but on my machine (XP SP2) I don’t see anything
under this key - AFD.SYS does not seem to need any parameters. Probably, this parameter is just optional, and comes into a play when it gets specified. If this is the case, then it not a default behaviour but simply an optional optimization, which in this particular case turned out to be wrong for the target machine’s actual configuration…

Anton Bassov

9

Hi,
This particular registry does not exist on the machine where we saw the
problem. But as I understand if reg key does not exit means default value of
IrppStackSize is 4. I created a reg entry and set it to 5 then problem got
fixed. It clearly shows that this particular registry entry affecting the
IrpStackSize allocated by Afd.

Any suggestions how this problem can be fixed?

xxxxx@hotmail.com wrote: > when we change the registry entry

“HKLM\SYSTEM\CurrentControlSet\Services\AFD\Parameters\IrpStackSize” from 4 to 5
it solves our problem.

Actually, I checked the above mentioned key, but on my machine (XP SP2) I don’t see anything
under this key - AFD.SYS does not seem to need any parameters. Probably, this parameter is just optional, and comes into a play when it gets specified. If this is the case, then it not a default behaviour but simply an optional optimization, which in this particular case turned out to be wrong for the target machine’s actual configuration…

Anton Bassov

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

Be a better Heartthrob. Get better relationship answers from someone who knows.
Yahoo! Answers - Check it out.

10

Hi,
This particular registry does not exist on the machine where we saw the
problem. But as I understand if reg key does not exit means default value of
IrppStackSize is 4. I created a reg entry and set it to 5 then problem got
fixed. It clearly shows that this particular registry entry affecting the
IrpStackSize allocated by Afd.

Any suggestions how this problem can be fixed?

Thanks
Soni

xxxxx@hotmail.com wrote:
> when we change the registry entry

“HKLM\SYSTEM\CurrentControlSet\Services\AFD\Parameters\IrpStackSize” from 4 to 5
it solves our problem.

Actually, I checked the above mentioned key, but on my machine (XP SP2) I don’t see anything
under this key - AFD.SYS does not seem to need any parameters. Probably, this parameter is just optional, and comes into a play when it gets specified. If this is the case, then it not a default behaviour but simply an optional optimization, which in this particular case turned out to be wrong for the target machine’s actual configuration…

Anton Bassov

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

Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool.