NO_MORE_IRP_STACK_LOCATIONS

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 ??

Kind Regards

Mark</file:>

“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 (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</mark.cook>

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</file:></mark.cook>

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</file:></mark.cook>

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>

>peating 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.

More so. TDI filters are hack :slight_smile: and I suggest not doing them :slight_smile: use LSP or use
NDIS IM.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Thomas,

You surely don’t mean IoAttachDevice(and friends) here :slight_smile:

“Thomas F. Divine” wrote in message news:xxxxx@ntdev…

“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 (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</mark.cook>