Mark,
Starting your driver after TCPIP but before NBT does solve the NBT problem
but it does not help, for instance, with even worse TDI clients like PPTP
which don?t even bother to call IoGetRelatedDeviceObject() the first time
the Transport is opened.
NBT may be imperfect in that after it opens \Device\Tcp and \Device\Udp it
is not expecting the number of locations to change, but PPTP is just down
right broken.
Repeating the IRP is really the only reasonable option. Some TDI filters
will ?borrow? the IRP stack location of the caller and put it back in the
CRTN but this will still be caught by Verifier as a potential failure before
you ever get to the borrowing. Borrowing an I/O stack location is a hack
and I am not suggesting you do it.
Keep in mind that if you repeat the IRP you are queuing the original IRP ?
mind the cancel logic.
Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Cook, Mark
Sent: Monday, May 23, 2005 3:50 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NO_MORE_IRP_STACK_LOCATIONS
Tony and Thomas
Many thanks to you both for your clear explanations of this behaviour. I
was investigating whether or not it would be possible to install my driver
earlier in the boot cycle (after TCP but before NetBT) but Tony?s suggestion
seems far cleaner.
Regards
Mark
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: 22 May 2005 00:05
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NO_MORE_IRP_STACK_LOCATIONS
The best way to work around this situation is to detect it and when you find
it, allocate a new IRP with the necessary number of I/O stack locations and
then send it down to the lower driver; in the completion routine, complete
the original IRP. Not terribly difficult code to write, but generally
useful.
The I/O Manager doesn?t suffer from this deficiency because it recomputes
this value prior to building each IRP (IoGetRelatedDeviceObject does this).
The driver in question (NetBT) isn?t filtering, it just calls directly, so
once it has computed the necessary size it never looks to see if the size is
still correct. This sort of sloppy programming is common for intermediate
drivers, unfortunately, because they assume the state of the world will not
change after initialization.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com http:</http:>
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of Thomas F. Divine
Sent: Saturday, May 21, 2005 7:26 AM
To: ntdev redirect
Subject: Re:[ntdev] NO_MORE_IRP_STACK_LOCATIONS
“Cook, Mark” <mark.cook> wrote in message news:xxxxx@ntdev…
Hi all
I?ve been developing a TDI filter driver that attaches to \Device\Tcp
<file:> (among other things) using IoAttachDevice. It
doesn?t currently do much apart from pass through any IRPs destined for the
original device by calling IoCallDriver.
Everything appears to work correctly until I attempt to make a NetBIOS call
(in this case by typing net view at the command prompt). As soon as I do
this, the system bugchecks with stop code 35 (NO_MORE_IRP_STACK_LOCATIONS).
Dumping the irp from the memory dump, I see the following (note that tdimon
is my filter driver):
Bugcheck code 00000035
Arguments 862abc00 00000000 00000000 00000000
kd> !irp 862abc00
Irp is active with 2 stacks 0 is current (= 0x862baca0)
No Mdl Thread 00000000: Irp stack trace.
cmd flg cl Device File Completion-Context
[f, 3] 0 e0 862baca0 86c6f170 f5162bf1-86af38c8 Success Error Cancel
\Driver\tdimon netbt!TcpConnectComplete
Args: 00000000 86ca4578 00000000 f507bc50
[f, 3] 0 e1 86ad8d30 86dffca0 f5165a8a-86c5d158 Success Error Cancel
pending
\Driver\NetBT netbt!NbtpConnectCompletionRoutine
Args: 00000000 86c5d168 00000000 f507bc50
I have verified that when I call IoAttachDevice, the StackSize for my object
increases to 2 (I am only attached to Device\TCP at this point which itself
has a StackSize of 1) and I have verified that when the system bugchecks,
this is still set to 2. In fact, if I dump the device stack for my device,
it still appears to be correct:
kd> !devstack 862baca0
!DevObj !DrvObj !DevExt ObjectName
> 862baca0 \Driver\tdimon 00000000
86d29e50 \Driver\Tcpip 00000000 Tcp
And using the dt against the DEVICE_OBJECTs for these two devices reveals
that the stack sizes are set to 2 and 1 respectively which also appears to
be correct.
From the IRP dump, it appears that one of the stack locations has been
consumed by device 86ad8d30 but this device is not on my stack. In fact if I
dump the device stack for this device, I see the following:
kd> !devstack 86ad8d30
!DevObj !DrvObj !DevExt ObjectName
> 86ad8d30 \Driver\NetBT 86ad8de8
NetBT_Tcpip_{F941E083-3AC1-4540-883C-169D85D2FBD5}
Curiously, when I run dt against this device, it also has a StackSize of 2
even though it doesn?t appear to be attached to anything.
It appears to me that because this device has consumed one of the stack
locations for my IRP, by the time it reaches my device the stack has been
exhausted and when I call IoCallDriver, the system bugchecks. What I don?t
see though is why this IRP would be going through the mysterious
NetBT_Tcpip_{F941E083-3AC1-4540-883C-169D85D2FBD5} device at all because it
doesn?t seem to be in my driver stack.
Does anybody have any ideas about why device
NetBT_Tcpip_{F941E083-3AC1-4540-883C-169D85D2FBD5} is on my stack ??
NetBT is a TDI Client that attached to \Device\Tcp BEFORE you attached your
filter. It does not know that you inserted your filter later and
consequently does not provide IRPs with the extra stack location.
Thomas F. Divine, Windows DDK MVP
http://www.pcausa.com
Kind Regards
Mark
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com</file:></mark.cook>