TDI_QUERY_ADDRESS_INFO in TDI_CONNECT handler?

NTDEV
1

Hi,

I’m trying to query the address information in TDI_CONNECT’s complete
routine of my TDI filter driver, originally I’m using
TdiBuildInternalDeviceControlIrp and it works only in passive level, then I
changed to use the IoAllocateIrp but system crashes inside IoCallDriver(…)
everytime. I also tried useing workqueue for dispatch level, most time it
works good but still get BSOD intermittently on some computers, what I guess
is that it’s because of the object was invalid at that moment.
After searched on the web, I found lot of people have the simillar
questions, seems the IoAllocateIrp(…) should work, but I can not get it
passed, here is my code (in the complete routine of TDI_CONNECT handler):
…
PIRP query_irp = NULL;
query_irp = IoAllocateIrp( devobj->StackSize, FALSE );
if( query_irp )
{
ctx = (PTDI_ADDROBJEX_CTX)ExAllocatePool( NonPagedPool, sizeof
(TDI_ADDROBJEX_CTX) );
if( ctx )
{
ctx->fileobj = connobj;
ctx->tai = (TDI_ADDRESS_INFO *)ExAllocatePool( NonPagedPool,
TDI_ADDRESS_INFO_MAX );
if( ctx->tai )
{
memset( ctx->tai, 0, TDI_ADDRESS_INFO_MAX );
pMdl = IoAllocateMdl( ctx->tai, TDI_ADDRESS_INFO_MAX, FALSE, FALSE,
NULL );
if( pMdl )
{
MmBuildMdlForNonPagedPool( pMdl );
TdiBuildQueryInformation( query_irp, devobj, connobj,
TDI_ConnCompleteEx, ctx, TDI_QUERY_ADDRESS_INFO, pMdl );
Status = IoCallDriver( devobj, query_irp ); **************** crash
inside
…

The crash dump says:
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at
an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000166, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804fb726, address which referenced memory

Debugging Details:

READ_ADDRESS: 00000166

CURRENT_IRQL: 2

FAULTING_IP:
nt!KeInsertQueueApc+22
804fb726 389e66010000 cmp [esi+0x166],bl

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from 804f880d to 80527da8

STACK_TEXT:
f79ee120 804f880d 00000003 f79ee47c 00000000
nt!RtlpBreakWithStatusInstruction
f79ee16c 804f93fa 00000003 00000166 804fb726 nt!KiBugCheckDebugBreak+0x19
f79ee54c 80540853 0000000a 00000166 00000002 nt!KeBugCheck2+0x574
f79ee54c 804fb726 0000000a 00000166 00000002 nt!KiTrap0E+0x233
f79ee5f8 804f1498 829f5768 00000000 00000000 nt!KeInsertQueueApc+0x22
f79ee62c f5ce9ad2 829f5798 829f5728 829f579c nt!IopfCompleteRequest+0x1d8
f79ee644 f5cf005b 829f5702 00000000 0000001a
tcpip!TCPDataRequestComplete+0xa6
f79ee67c f5cefbe5 829f5728 829f5798 829f5728 tcpip!TCPQueryInformation+0xba
f79ee698 f7340b0f 82810958 829f5728 829b3d7d
tcpip!TCPDispatchInternalDeviceControl+0x182
WARNING: Stack unwind information not available. Following frames may be
wrong.
f79ee6b4 804eedf9 82810958 829f5728 828d8300 fsdfw+0x7b0f
f79ee6c4 f50fab27 828d8397 00000001 82901320 nt!IopfCallDriver+0x31
f79ee6f4 f50fa46a 829cde80 82901320 829f5728 testnet!TDI_ConnComplete+0x2a3
[D:\testnet\testKTdi.cpp @ 1980]
…

Anyone can shed some lights on this problem?

thanks in advance,

AFei

2

You need to set a completion routine on your irp (query_irp) and then
return STATUS_MORE_PROCCESSING_REQUIRED so that the i/o manager does not
try to complete the irp back to the owning thread (which there is none
b/c you allocated the irp on your own). You still need to free the irp
by calling IoFreeIrp somewhere in your code, could be your completion
routine, could be after you synchronously wait for the irp to complete.

d

– I can spell, I just can’t type.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of AFei
Sent: Thursday, July 20, 2006 2:57 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] TDI_QUERY_ADDRESS_INFO in TDI_CONNECT handler?

Hi,

I’m trying to query the address information in TDI_CONNECT’s complete
routine of my TDI filter driver, originally I’m using
TdiBuildInternalDeviceControlIrp and it works only in passive level,
then I changed to use the IoAllocateIrp but system crashes inside
IoCallDriver(…) everytime. I also tried useing workqueue for dispatch
level, most time it works good but still get BSOD intermittently on some
computers, what I guess is that it’s because of the object was invalid
at that moment.
After searched on the web, I found lot of people have the simillar
questions, seems the IoAllocateIrp(…) should work, but I can not get
it passed, here is my code (in the complete routine of TDI_CONNECT
handler):
…
PIRP query_irp = NULL;
query_irp = IoAllocateIrp( devobj->StackSize, FALSE );
if( query_irp )
{
ctx = (PTDI_ADDROBJEX_CTX)ExAllocatePool( NonPagedPool, sizeof
(TDI_ADDROBJEX_CTX) );
if( ctx )
{
ctx->fileobj = connobj;
ctx->tai = (TDI_ADDRESS_INFO *)ExAllocatePool( NonPagedPool,
TDI_ADDRESS_INFO_MAX );
if( ctx->tai )
{
memset( ctx->tai, 0, TDI_ADDRESS_INFO_MAX );
pMdl = IoAllocateMdl( ctx->tai, TDI_ADDRESS_INFO_MAX, FALSE, FALSE,
NULL );
if( pMdl )
{
MmBuildMdlForNonPagedPool( pMdl );
TdiBuildQueryInformation( query_irp, devobj, connobj,
TDI_ConnCompleteEx, ctx, TDI_QUERY_ADDRESS_INFO, pMdl );
Status = IoCallDriver( devobj, query_irp ); **************** crash
inside …

The crash dump says:
************************************************************************
*******
*
*
* Bugcheck Analysis
*
*
*
************************************************************************
*******

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address
at an interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000166, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804fb726, address which referenced memory

Debugging Details:

READ_ADDRESS: 00000166

CURRENT_IRQL: 2

FAULTING_IP:
nt!KeInsertQueueApc+22
804fb726 389e66010000 cmp [esi+0x166],bl

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from 804f880d to 80527da8

STACK_TEXT:
f79ee120 804f880d 00000003 f79ee47c 00000000
nt!RtlpBreakWithStatusInstruction f79ee16c 804f93fa 00000003 00000166
804fb726 nt!KiBugCheckDebugBreak+0x19 f79ee54c 80540853 0000000a
00000166 00000002 nt!KeBugCheck2+0x574 f79ee54c 804fb726 0000000a
00000166 00000002 nt!KiTrap0E+0x233
f79ee5f8 804f1498 829f5768 00000000 00000000 nt!KeInsertQueueApc+0x22
f79ee62c f5ce9ad2 829f5798 829f5728 829f579c
nt!IopfCompleteRequest+0x1d8
f79ee644 f5cf005b 829f5702 00000000 0000001a
tcpip!TCPDataRequestComplete+0xa6
f79ee67c f5cefbe5 829f5728 829f5798 829f5728
tcpip!TCPQueryInformation+0xba
f79ee698 f7340b0f 82810958 829f5728 829b3d7d
tcpip!TCPDispatchInternalDeviceControl+0x182
WARNING: Stack unwind information not available. Following frames may be
wrong.
f79ee6b4 804eedf9 82810958 829f5728 828d8300 fsdfw+0x7b0f
f79ee6c4 f50fab27 828d8397 00000001 82901320 nt!IopfCallDriver+0x31
f79ee6f4 f50fa46a 829cde80 82901320 829f5728
testnet!TDI_ConnComplete+0x2a3 [D:\testnet\testKTdi.cpp @ 1980] …

Anyone can shed some lights on this problem?

thanks in advance,

AFei

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

3

Hi Doron, thanks for the reply. I do have complete routine set in the
query_irp when calling the macro TdiBuildQueryInformation(…), also I have
the IoFreeIrp(…) in the complete routine as you said. But I didn’t quite
understand the return “STATUS_MORE_PROCESSING_REQUIRED”, In the complete
routine of TDI_CONNECT filter, I created a query IRP and called the
IoCallDriver directly, it won’t return unless get the address information or
failed by some reason, I can just ignore the result and return success for
testing purpose. But the crash happened right after calling
IoCallDriver(…) didn’t reach my complete routine yet (I have verified this
in debugger), could you please give me more detail information? a piece of
workable code is very appreciated. thanks again.

“Doron Holan” wrote in message
news:xxxxx@ntdev…
You need to set a completion routine on your irp (query_irp) and then
return STATUS_MORE_PROCCESSING_REQUIRED so that the i/o manager does not
try to complete the irp back to the owning thread (which there is none
b/c you allocated the irp on your own). You still need to free the irp
by calling IoFreeIrp somewhere in your code, could be your completion
routine, could be after you synchronously wait for the irp to complete.

d

– I can spell, I just can’t type.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of AFei
Sent: Thursday, July 20, 2006 2:57 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] TDI_QUERY_ADDRESS_INFO in TDI_CONNECT handler?

Hi,

I’m trying to query the address information in TDI_CONNECT’s complete
routine of my TDI filter driver, originally I’m using
TdiBuildInternalDeviceControlIrp and it works only in passive level,
then I changed to use the IoAllocateIrp but system crashes inside
IoCallDriver(…) everytime. I also tried useing workqueue for dispatch
level, most time it works good but still get BSOD intermittently on some
computers, what I guess is that it’s because of the object was invalid
at that moment.
After searched on the web, I found lot of people have the simillar
questions, seems the IoAllocateIrp(…) should work, but I can not get
it passed, here is my code (in the complete routine of TDI_CONNECT
handler):
…
PIRP query_irp = NULL;
query_irp = IoAllocateIrp( devobj->StackSize, FALSE );
if( query_irp )
{
ctx = (PTDI_ADDROBJEX_CTX)ExAllocatePool( NonPagedPool, sizeof
(TDI_ADDROBJEX_CTX) );
if( ctx )
{
ctx->fileobj = connobj;
ctx->tai = (TDI_ADDRESS_INFO )ExAllocatePool( NonPagedPool,
TDI_ADDRESS_INFO_MAX );
if( ctx->tai )
{
memset( ctx->tai, 0, TDI_ADDRESS_INFO_MAX );
pMdl = IoAllocateMdl( ctx->tai, TDI_ADDRESS_INFO_MAX, FALSE, FALSE,
NULL );
if( pMdl )
{
MmBuildMdlForNonPagedPool( pMdl );
TdiBuildQueryInformation( query_irp, devobj, connobj,
TDI_ConnCompleteEx, ctx, TDI_QUERY_ADDRESS_INFO, pMdl );
Status = IoCallDriver( devobj, query_irp ); crash
inside …

The crash dump says:
*******************************************************



Bugcheck Analysis



***********************************************************************
*******

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address
at an interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000166, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804fb726, address which referenced memory

Debugging Details:
------------------

READ_ADDRESS: 00000166

CURRENT_IRQL: 2

FAULTING_IP:
nt!KeInsertQueueApc+22
804fb726 389e66010000 cmp [esi+0x166],bl

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from 804f880d to 80527da8

STACK_TEXT:
f79ee120 804f880d 00000003 f79ee47c 00000000
nt!RtlpBreakWithStatusInstruction f79ee16c 804f93fa 00000003 00000166
804fb726 nt!KiBugCheckDebugBreak+0x19 f79ee54c 80540853 0000000a
00000166 00000002 nt!KeBugCheck2+0x574 f79ee54c 804fb726 0000000a
00000166 00000002 nt!KiTrap0E+0x233
f79ee5f8 804f1498 829f5768 00000000 00000000 nt!KeInsertQueueApc+0x22
f79ee62c f5ce9ad2 829f5798 829f5728 829f579c
nt!IopfCompleteRequest+0x1d8
f79ee644 f5cf005b 829f5702 00000000 0000001a
tcpip!TCPDataRequestComplete+0xa6
f79ee67c f5cefbe5 829f5728 829f5798 829f5728
tcpip!TCPQueryInformation+0xba
f79ee698 f7340b0f 82810958 829f5728 829b3d7d
tcpip!TCPDispatchInternalDeviceControl+0x182
WARNING: Stack unwind information not available. Following frames may be
wrong.
f79ee6b4 804eedf9 82810958 829f5728 828d8300 fsdfw+0x7b0f
f79ee6c4 f50fab27 828d8397 00000001 82901320 nt!IopfCallDriver+0x31
f79ee6f4 f50fa46a 829cde80 82901320 829f5728
testnet!TDI_ConnComplete+0x2a3 [D:\testnet\testKTdi.cpp @ 1980] …
---------

Anyone can shed some lights on this problem?

thanks in advance,

AFei

—
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

4

Post all of your init code for the irp, somehow the irp is being
completed back to the io manager. I didn’t see anywhere where you are
setting a completion routine.

Arg1: 00000166, memory referenced <– a NULL deref + 0x166

And you see in the callstack that the i/o manager is trying to queue an
APC which is what it does to finalize an irp completion.

f79ee5f8 804f1498 829f5768 00000000 00000000 nt!KeInsertQueueApc+0x22
f79ee62c f5ce9ad2 829f5798 829f5728 829f579c
nt!IopfCompleteRequest+0x1d8
f79ee644 f5cf005b 829f5702 00000000 0000001a
tcpip!TCPDataRequestComplete+0xa6

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of AFei
Sent: Thursday, July 20, 2006 9:46 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] TDI_QUERY_ADDRESS_INFO in TDI_CONNECT handler?

Hi Doron, thanks for the reply. I do have complete routine set in the
query_irp when calling the macro TdiBuildQueryInformation(…), also I
have
the IoFreeIrp(…) in the complete routine as you said. But I didn’t
quite
understand the return “STATUS_MORE_PROCESSING_REQUIRED”, In the complete

routine of TDI_CONNECT filter, I created a query IRP and called the
IoCallDriver directly, it won’t return unless get the address
information or
failed by some reason, I can just ignore the result and return success
for
testing purpose. But the crash happened right after calling
IoCallDriver(…) didn’t reach my complete routine yet (I have verified
this
in debugger), could you please give me more detail information? a piece
of
workable code is very appreciated. thanks again.

“Doron Holan” wrote in message
news:xxxxx@ntdev…
You need to set a completion routine on your irp (query_irp) and then
return STATUS_MORE_PROCCESSING_REQUIRED so that the i/o manager does not
try to complete the irp back to the owning thread (which there is none
b/c you allocated the irp on your own). You still need to free the irp
by calling IoFreeIrp somewhere in your code, could be your completion
routine, could be after you synchronously wait for the irp to complete.

d

– I can spell, I just can’t type.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of AFei
Sent: Thursday, July 20, 2006 2:57 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] TDI_QUERY_ADDRESS_INFO in TDI_CONNECT handler?

Hi,

I’m trying to query the address information in TDI_CONNECT’s complete
routine of my TDI filter driver, originally I’m using
TdiBuildInternalDeviceControlIrp and it works only in passive level,
then I changed to use the IoAllocateIrp but system crashes inside
IoCallDriver(…) everytime. I also tried useing workqueue for dispatch
level, most time it works good but still get BSOD intermittently on some
computers, what I guess is that it’s because of the object was invalid
at that moment.
After searched on the web, I found lot of people have the simillar
questions, seems the IoAllocateIrp(…) should work, but I can not get
it passed, here is my code (in the complete routine of TDI_CONNECT
handler):
…
PIRP query_irp = NULL;
query_irp = IoAllocateIrp( devobj->StackSize, FALSE );
if( query_irp )
{
ctx = (PTDI_ADDROBJEX_CTX)ExAllocatePool( NonPagedPool, sizeof
(TDI_ADDROBJEX_CTX) );
if( ctx )
{
ctx->fileobj = connobj;
ctx->tai = (TDI_ADDRESS_INFO )ExAllocatePool( NonPagedPool,
TDI_ADDRESS_INFO_MAX );
if( ctx->tai )
{
memset( ctx->tai, 0, TDI_ADDRESS_INFO_MAX );
pMdl = IoAllocateMdl( ctx->tai, TDI_ADDRESS_INFO_MAX, FALSE, FALSE,
NULL );
if( pMdl )
{
MmBuildMdlForNonPagedPool( pMdl );
TdiBuildQueryInformation( query_irp, devobj, connobj,
TDI_ConnCompleteEx, ctx, TDI_QUERY_ADDRESS_INFO, pMdl );
Status = IoCallDriver( devobj, query_irp ); crash
inside …

The crash dump says:
*******************************************************



Bugcheck Analysis



***********************************************************************
*******

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address
at an interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000166, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804fb726, address which referenced memory

Debugging Details:
------------------

READ_ADDRESS: 00000166

CURRENT_IRQL: 2

FAULTING_IP:
nt!KeInsertQueueApc+22
804fb726 389e66010000 cmp [esi+0x166],bl

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from 804f880d to 80527da8

STACK_TEXT:
f79ee120 804f880d 00000003 f79ee47c 00000000
nt!RtlpBreakWithStatusInstruction f79ee16c 804f93fa 00000003 00000166
804fb726 nt!KiBugCheckDebugBreak+0x19 f79ee54c 80540853 0000000a
00000166 00000002 nt!KeBugCheck2+0x574 f79ee54c 804fb726 0000000a
00000166 00000002 nt!KiTrap0E+0x233
f79ee5f8 804f1498 829f5768 00000000 00000000 nt!KeInsertQueueApc+0x22
f79ee62c f5ce9ad2 829f5798 829f5728 829f579c
nt!IopfCompleteRequest+0x1d8
f79ee644 f5cf005b 829f5702 00000000 0000001a
tcpip!TCPDataRequestComplete+0xa6
f79ee67c f5cefbe5 829f5728 829f5798 829f5728
tcpip!TCPQueryInformation+0xba
f79ee698 f7340b0f 82810958 829f5728 829b3d7d
tcpip!TCPDispatchInternalDeviceControl+0x182
WARNING: Stack unwind information not available. Following frames may be
wrong.
f79ee6b4 804eedf9 82810958 829f5728 828d8300 fsdfw+0x7b0f
f79ee6c4 f50fab27 828d8397 00000001 82901320 nt!IopfCallDriver+0x31
f79ee6f4 f50fa46a 829cde80 82901320 829f5728
testnet!TDI_ConnComplete+0x2a3 [D:\testnet\testKTdi.cpp @ 1980] …
---------

Anyone can shed some lights on this problem?

thanks in advance,

AFei

—
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

—
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

5

Did you turn on the driver verifier?
You may see that the stack size is too small from the verifier.
Add the stack for your driver.

PIRP query_irp = NULL;
query_irp = IoAllocateIrp( devobj->StackSize + 1, FALSE );

Chesong Lee

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of AFei
Sent: Friday, July 21, 2006 12:46 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] TDI_QUERY_ADDRESS_INFO in TDI_CONNECT handler?

Hi Doron, thanks for the reply. I do have complete routine set in the
query_irp when calling the macro TdiBuildQueryInformation(…), also I
have
the IoFreeIrp(…) in the complete routine as you said. But I didn’t
quite
understand the return “STATUS_MORE_PROCESSING_REQUIRED”, In the complete

routine of TDI_CONNECT filter, I created a query IRP and called the
IoCallDriver directly, it won’t return unless get the address
information or
failed by some reason, I can just ignore the result and return success
for
testing purpose. But the crash happened right after calling
IoCallDriver(…) didn’t reach my complete routine yet (I have verified
this
in debugger), could you please give me more detail information? a piece
of
workable code is very appreciated. thanks again.

“Doron Holan” wrote in message
news:xxxxx@ntdev…
You need to set a completion routine on your irp (query_irp) and then
return STATUS_MORE_PROCCESSING_REQUIRED so that the i/o manager does not
try to complete the irp back to the owning thread (which there is none
b/c you allocated the irp on your own). You still need to free the irp
by calling IoFreeIrp somewhere in your code, could be your completion
routine, could be after you synchronously wait for the irp to complete.

d

– I can spell, I just can’t type.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of AFei
Sent: Thursday, July 20, 2006 2:57 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] TDI_QUERY_ADDRESS_INFO in TDI_CONNECT handler?

Hi,

I’m trying to query the address information in TDI_CONNECT’s complete
routine of my TDI filter driver, originally I’m using
TdiBuildInternalDeviceControlIrp and it works only in passive level,
then I changed to use the IoAllocateIrp but system crashes inside
IoCallDriver(…) everytime. I also tried useing workqueue for dispatch
level, most time it works good but still get BSOD intermittently on some
computers, what I guess is that it’s because of the object was invalid
at that moment.
After searched on the web, I found lot of people have the simillar
questions, seems the IoAllocateIrp(…) should work, but I can not get
it passed, here is my code (in the complete routine of TDI_CONNECT
handler):
…
PIRP query_irp = NULL;
query_irp = IoAllocateIrp( devobj->StackSize, FALSE );
if( query_irp )
{
ctx = (PTDI_ADDROBJEX_CTX)ExAllocatePool( NonPagedPool, sizeof
(TDI_ADDROBJEX_CTX) );
if( ctx )
{
ctx->fileobj = connobj;
ctx->tai = (TDI_ADDRESS_INFO )ExAllocatePool( NonPagedPool,
TDI_ADDRESS_INFO_MAX );
if( ctx->tai )
{
memset( ctx->tai, 0, TDI_ADDRESS_INFO_MAX );
pMdl = IoAllocateMdl( ctx->tai, TDI_ADDRESS_INFO_MAX, FALSE, FALSE,
NULL );
if( pMdl )
{
MmBuildMdlForNonPagedPool( pMdl );
TdiBuildQueryInformation( query_irp, devobj, connobj,
TDI_ConnCompleteEx, ctx, TDI_QUERY_ADDRESS_INFO, pMdl );
Status = IoCallDriver( devobj, query_irp ); crash
inside …

The crash dump says:
*******************************************************



Bugcheck Analysis



***********************************************************************
*******

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address
at an interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000166, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804fb726, address which referenced memory

Debugging Details:
------------------

READ_ADDRESS: 00000166

CURRENT_IRQL: 2

FAULTING_IP:
nt!KeInsertQueueApc+22
804fb726 389e66010000 cmp [esi+0x166],bl

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from 804f880d to 80527da8

STACK_TEXT:
f79ee120 804f880d 00000003 f79ee47c 00000000
nt!RtlpBreakWithStatusInstruction f79ee16c 804f93fa 00000003 00000166
804fb726 nt!KiBugCheckDebugBreak+0x19 f79ee54c 80540853 0000000a
00000166 00000002 nt!KeBugCheck2+0x574 f79ee54c 804fb726 0000000a
00000166 00000002 nt!KiTrap0E+0x233
f79ee5f8 804f1498 829f5768 00000000 00000000 nt!KeInsertQueueApc+0x22
f79ee62c f5ce9ad2 829f5798 829f5728 829f579c
nt!IopfCompleteRequest+0x1d8
f79ee644 f5cf005b 829f5702 00000000 0000001a
tcpip!TCPDataRequestComplete+0xa6
f79ee67c f5cefbe5 829f5728 829f5798 829f5728
tcpip!TCPQueryInformation+0xba
f79ee698 f7340b0f 82810958 829f5728 829b3d7d
tcpip!TCPDispatchInternalDeviceControl+0x182
WARNING: Stack unwind information not available. Following frames may be
wrong.
f79ee6b4 804eedf9 82810958 829f5728 828d8300 fsdfw+0x7b0f
f79ee6c4 f50fab27 828d8397 00000001 82901320 nt!IopfCallDriver+0x31
f79ee6f4 f50fa46a 829cde80 82901320 829f5728
testnet!TDI_ConnComplete+0x2a3 [D:\testnet\testKTdi.cpp @ 1980] …
---------

Anyone can shed some lights on this problem?

thanks in advance,

AFei

—
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

—
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

6

Hi Lee, thanks for the information, unfortunately it’s not the problem. The
driver verifier didn’t complain that and also the CurrentStackLocation of
IRP is 2 which is enough in IoCallDriver(…). :slight_smile:

“Chesong Lee” wrote in message news:xxxxx@ntdev…
Did you turn on the driver verifier?
You may see that the stack size is too small from the verifier.
Add the stack for your driver.

PIRP query_irp = NULL;
query_irp = IoAllocateIrp( devobj->StackSize + 1, FALSE );

Chesong Lee

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of AFei
Sent: Friday, July 21, 2006 12:46 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] TDI_QUERY_ADDRESS_INFO in TDI_CONNECT handler?

Hi Doron, thanks for the reply. I do have complete routine set in the
query_irp when calling the macro TdiBuildQueryInformation(…), also I
have
the IoFreeIrp(…) in the complete routine as you said. But I didn’t
quite
understand the return “STATUS_MORE_PROCESSING_REQUIRED”, In the complete

routine of TDI_CONNECT filter, I created a query IRP and called the
IoCallDriver directly, it won’t return unless get the address
information or
failed by some reason, I can just ignore the result and return success
for
testing purpose. But the crash happened right after calling
IoCallDriver(…) didn’t reach my complete routine yet (I have verified
this
in debugger), could you please give me more detail information? a piece
of
workable code is very appreciated. thanks again.

“Doron Holan” wrote in message
news:xxxxx@ntdev…
You need to set a completion routine on your irp (query_irp) and then
return STATUS_MORE_PROCCESSING_REQUIRED so that the i/o manager does not
try to complete the irp back to the owning thread (which there is none
b/c you allocated the irp on your own). You still need to free the irp
by calling IoFreeIrp somewhere in your code, could be your completion
routine, could be after you synchronously wait for the irp to complete.

d

– I can spell, I just can’t type.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of AFei
Sent: Thursday, July 20, 2006 2:57 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] TDI_QUERY_ADDRESS_INFO in TDI_CONNECT handler?

Hi,

I’m trying to query the address information in TDI_CONNECT’s complete
routine of my TDI filter driver, originally I’m using
TdiBuildInternalDeviceControlIrp and it works only in passive level,
then I changed to use the IoAllocateIrp but system crashes inside
IoCallDriver(…) everytime. I also tried useing workqueue for dispatch
level, most time it works good but still get BSOD intermittently on some
computers, what I guess is that it’s because of the object was invalid
at that moment.
After searched on the web, I found lot of people have the simillar
questions, seems the IoAllocateIrp(…) should work, but I can not get
it passed, here is my code (in the complete routine of TDI_CONNECT
handler):
…
PIRP query_irp = NULL;
query_irp = IoAllocateIrp( devobj->StackSize, FALSE );
if( query_irp )
{
ctx = (PTDI_ADDROBJEX_CTX)ExAllocatePool( NonPagedPool, sizeof
(TDI_ADDROBJEX_CTX) );
if( ctx )
{
ctx->fileobj = connobj;
ctx->tai = (TDI_ADDRESS_INFO )ExAllocatePool( NonPagedPool,
TDI_ADDRESS_INFO_MAX );
if( ctx->tai )
{
memset( ctx->tai, 0, TDI_ADDRESS_INFO_MAX );
pMdl = IoAllocateMdl( ctx->tai, TDI_ADDRESS_INFO_MAX, FALSE, FALSE,
NULL );
if( pMdl )
{
MmBuildMdlForNonPagedPool( pMdl );
TdiBuildQueryInformation( query_irp, devobj, connobj,
TDI_ConnCompleteEx, ctx, TDI_QUERY_ADDRESS_INFO, pMdl );
Status = IoCallDriver( devobj, query_irp ); crash
inside …

The crash dump says:
*******************************************************



Bugcheck Analysis



***********************************************************************
*******

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address
at an interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000166, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804fb726, address which referenced memory

Debugging Details:
------------------

READ_ADDRESS: 00000166

CURRENT_IRQL: 2

FAULTING_IP:
nt!KeInsertQueueApc+22
804fb726 389e66010000 cmp [esi+0x166],bl

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from 804f880d to 80527da8

STACK_TEXT:
f79ee120 804f880d 00000003 f79ee47c 00000000
nt!RtlpBreakWithStatusInstruction f79ee16c 804f93fa 00000003 00000166
804fb726 nt!KiBugCheckDebugBreak+0x19 f79ee54c 80540853 0000000a
00000166 00000002 nt!KeBugCheck2+0x574 f79ee54c 804fb726 0000000a
00000166 00000002 nt!KiTrap0E+0x233
f79ee5f8 804f1498 829f5768 00000000 00000000 nt!KeInsertQueueApc+0x22
f79ee62c f5ce9ad2 829f5798 829f5728 829f579c
nt!IopfCompleteRequest+0x1d8
f79ee644 f5cf005b 829f5702 00000000 0000001a
tcpip!TCPDataRequestComplete+0xa6
f79ee67c f5cefbe5 829f5728 829f5798 829f5728
tcpip!TCPQueryInformation+0xba
f79ee698 f7340b0f 82810958 829f5728 829b3d7d
tcpip!TCPDispatchInternalDeviceControl+0x182
WARNING: Stack unwind information not available. Following frames may be
wrong.
f79ee6b4 804eedf9 82810958 829f5728 828d8300 fsdfw+0x7b0f
f79ee6c4 f50fab27 828d8397 00000001 82901320 nt!IopfCallDriver+0x31
f79ee6f4 f50fa46a 829cde80 82901320 829f5728
testnet!TDI_ConnComplete+0x2a3 [D:\testnet\testKTdi.cpp @ 1980] …
---------

Anyone can shed some lights on this problem?

thanks in advance,

AFei

—
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

—
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

7

Hi Doron,

All the IRP init code is there, the complete routine was set in the macro
TdiBuildQueryInformation(…) (the IoSetCompletionRoutine() was called
inside with my complete routine as a parameter).
But as you said, please take a look the following call stack, it seems TCPIP
finished the data query and trying to complete IRP, at this moment, system
crashed, and my complete routine somehow wasn’t called. I’m going to dig
more. Any hints?

thanks a lot.

STACK_TEXT:
f7a12410 804f880d 00000003 f7a1276c 00000000
nt!RtlpBreakWithStatusInstruction
f7a1245c 804f93fa 00000003 00000166 804fb726 nt!KiBugCheckDebugBreak+0x19
f7a1283c 80540853 0000000a 00000166 00000002 nt!KeBugCheck2+0x574
f7a1283c 804fb726 0000000a 00000166 00000002 nt!KiTrap0E+0x233
f7a128e8 804f1498 82886e88 00000000 00000000 nt!KeInsertQueueApc+0x22
f7a1291c f3caaad2 82886edc 82886e48 82886ee0
nt!IopfCompleteRequest+0x1d8 -------------------> ???
f7a12934 f3cb105b 82886e02 00000000 0000001a
tcpip!TCPDataRequestComplete+0xa6
f7a1296c f3cb0be5 82886e48 82886edc 82886e48 tcpip!TCPQueryInformation+0xba
f7a12988 f731bb0f 829a0030 82886e48 829f83cd
tcpip!TCPDispatchInternalDeviceControl+0x182
WARNING: Stack unwind information not available. Following frames may be
wrong.
f7a129a4 804eedf9 829a0030 82886e48 827e4c88 fsdfw+0x7b0f
f7a129b4 f3148b5b 827e4d1f 00000001 82980028 nt!IopfCallDriver+0x31
f7a129e4 f314847a 82847db8 82980028 82886e48 testnet!TDI_ConnComplete+0x2b3
f7a12a18 804f1362 82847db8 827e4c88 82886e48
testnet!TDI_ConnectComplete+0x68
f7a12a48 f3caaad2 8296dd30 827d1c20 00000002 nt!IopfCompleteRequest+0xa2
f7a12a60 f3cb0cc8 827e4c88 00000000 00000000
tcpip!TCPDataRequestComplete+0xa6
f7a12a74 f3cb1ba5 827e4c88 00000000 00000000 tcpip!TCPRequestComplete+0x12
f7a12a94 f3cb3a5a 827d1c20 f7a12c54 00000000 tcpip!CompleteConnReq+0x87
f7a12b18 f3ca7ef5 82a1e008 0100007f 0100007f tcpip!TCPRcv+0xdda
f7a12b78 f3ca7b19 00000020 82a1e008 f3caa076 tcpip!DeliverToUser+0x18e
f7a12bf4 f3ca7836 f3ce73f0 82a1e008 f7a12d10 tcpip!DeliverToUserEx+0x95e
f7a12cac f3cb537e 82a1e008 f7a12d24 0000001c tcpip!IPRcvPacket+0x6cb
f7a12d58 f79133e4 f3ce7180 82a1e008 f3ce7190 tcpip!LoopXmitRtn+0x195
f7a12d74 80534dd0 82a1e008 00000000 82bbada8 TDI!CTEpEventHandler+0x32
f7a12dac 805c5a06 f3ce7180 00000000 00000000 nt!ExpWorkerThread+0x100
f7a12ddc 80541fa2 80534cd0 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

8

I don’t have the original message, pls resend your code

d

– I can spell, I just can’t type.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of AFei
Sent: Friday, July 21, 2006 3:00 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] TDI_QUERY_ADDRESS_INFO in TDI_CONNECT handler?

Hi Doron,

All the IRP init code is there, the complete routine was set in the
macro
TdiBuildQueryInformation(…) (the IoSetCompletionRoutine() was called
inside with my complete routine as a parameter).
But as you said, please take a look the following call stack, it seems
TCPIP finished the data query and trying to complete IRP, at this
moment, system crashed, and my complete routine somehow wasn’t called.
I’m going to dig more. Any hints?

thanks a lot.

STACK_TEXT:
f7a12410 804f880d 00000003 f7a1276c 00000000
nt!RtlpBreakWithStatusInstruction f7a1245c 804f93fa 00000003 00000166
804fb726 nt!KiBugCheckDebugBreak+0x19 f7a1283c 80540853 0000000a
00000166 00000002 nt!KeBugCheck2+0x574 f7a1283c 804fb726 0000000a
00000166 00000002 nt!KiTrap0E+0x233
f7a128e8 804f1498 82886e88 00000000 00000000 nt!KeInsertQueueApc+0x22
f7a1291c f3caaad2 82886edc 82886e48 82886ee0
nt!IopfCompleteRequest+0x1d8 -------------------> ???
f7a12934 f3cb105b 82886e02 00000000 0000001a
tcpip!TCPDataRequestComplete+0xa6
f7a1296c f3cb0be5 82886e48 82886edc 82886e48
tcpip!TCPQueryInformation+0xba
f7a12988 f731bb0f 829a0030 82886e48 829f83cd
tcpip!TCPDispatchInternalDeviceControl+0x182
WARNING: Stack unwind information not available. Following frames may be
wrong.
f7a129a4 804eedf9 829a0030 82886e48 827e4c88 fsdfw+0x7b0f
f7a129b4 f3148b5b 827e4d1f 00000001 82980028 nt!IopfCallDriver+0x31
f7a129e4 f314847a 82847db8 82980028 82886e48
testnet!TDI_ConnComplete+0x2b3
f7a12a18 804f1362 82847db8 827e4c88 82886e48
testnet!TDI_ConnectComplete+0x68
f7a12a48 f3caaad2 8296dd30 827d1c20 00000002 nt!IopfCompleteRequest+0xa2
f7a12a60 f3cb0cc8 827e4c88 00000000 00000000
tcpip!TCPDataRequestComplete+0xa6
f7a12a74 f3cb1ba5 827e4c88 00000000 00000000
tcpip!TCPRequestComplete+0x12
f7a12a94 f3cb3a5a 827d1c20 f7a12c54 00000000 tcpip!CompleteConnReq+0x87
f7a12b18 f3ca7ef5 82a1e008 0100007f 0100007f tcpip!TCPRcv+0xdda
f7a12b78 f3ca7b19 00000020 82a1e008 f3caa076 tcpip!DeliverToUser+0x18e
f7a12bf4 f3ca7836 f3ce73f0 82a1e008 f7a12d10 tcpip!DeliverToUserEx+0x95e
f7a12cac f3cb537e 82a1e008 f7a12d24 0000001c tcpip!IPRcvPacket+0x6cb
f7a12d58 f79133e4 f3ce7180 82a1e008 f3ce7190 tcpip!LoopXmitRtn+0x195
f7a12d74 80534dd0 82a1e008 00000000 82bbada8 TDI!CTEpEventHandler+0x32
f7a12dac 805c5a06 f3ce7180 00000000 00000000 nt!ExpWorkerThread+0x100
f7a12ddc 80541fa2 80534cd0 00000001 00000000
nt!PspSystemThreadStartup+0x34 00000000 00000000 00000000 00000000
00000000 nt!KiThreadStartup+0x16

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

9

Sorry, here is the code:
(in the complete routine of TDI_CONNECT handler):
…
PIRP query_irp = NULL;
query_irp = IoAllocateIrp( devobj->StackSize, FALSE );
if( query_irp )
{
ctx = (PTDI_ADDROBJEX_CTX)ExAllocatePool( NonPagedPool, sizeof
(TDI_ADDROBJEX_CTX) );
if( ctx )
{
ctx->fileobj = connobj;
ctx->tai = (TDI_ADDRESS_INFO *)ExAllocatePool( NonPagedPool,
TDI_ADDRESS_INFO_MAX );
if( ctx->tai )
{
memset( ctx->tai, 0, TDI_ADDRESS_INFO_MAX );
pMdl = IoAllocateMdl( ctx->tai, TDI_ADDRESS_INFO_MAX, FALSE, FALSE,
NULL );
if( pMdl )
{
MmBuildMdlForNonPagedPool( pMdl );
TdiBuildQueryInformation( query_irp, devobj, connobj,
TDI_ConnCompleteEx, ctx, TDI_QUERY_ADDRESS_INFO, pMdl );
Status = IoCallDriver( devobj, query_irp ); **************** crash
inside
…

“Doron Holan” wrote in message
news:xxxxx@ntdev…
I don’t have the original message, pls resend your code

d

– I can spell, I just can’t type.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of AFei
Sent: Friday, July 21, 2006 3:00 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] TDI_QUERY_ADDRESS_INFO in TDI_CONNECT handler?

Hi Doron,

All the IRP init code is there, the complete routine was set in the
macro
TdiBuildQueryInformation(…) (the IoSetCompletionRoutine() was called
inside with my complete routine as a parameter).
But as you said, please take a look the following call stack, it seems
TCPIP finished the data query and trying to complete IRP, at this
moment, system crashed, and my complete routine somehow wasn’t called.
I’m going to dig more. Any hints?

thanks a lot.

STACK_TEXT:
f7a12410 804f880d 00000003 f7a1276c 00000000
nt!RtlpBreakWithStatusInstruction f7a1245c 804f93fa 00000003 00000166
804fb726 nt!KiBugCheckDebugBreak+0x19 f7a1283c 80540853 0000000a
00000166 00000002 nt!KeBugCheck2+0x574 f7a1283c 804fb726 0000000a
00000166 00000002 nt!KiTrap0E+0x233
f7a128e8 804f1498 82886e88 00000000 00000000 nt!KeInsertQueueApc+0x22
f7a1291c f3caaad2 82886edc 82886e48 82886ee0
nt!IopfCompleteRequest+0x1d8 -------------------> ???
f7a12934 f3cb105b 82886e02 00000000 0000001a
tcpip!TCPDataRequestComplete+0xa6
f7a1296c f3cb0be5 82886e48 82886edc 82886e48
tcpip!TCPQueryInformation+0xba
f7a12988 f731bb0f 829a0030 82886e48 829f83cd
tcpip!TCPDispatchInternalDeviceControl+0x182
WARNING: Stack unwind information not available. Following frames may be
wrong.
f7a129a4 804eedf9 829a0030 82886e48 827e4c88 fsdfw+0x7b0f
f7a129b4 f3148b5b 827e4d1f 00000001 82980028 nt!IopfCallDriver+0x31
f7a129e4 f314847a 82847db8 82980028 82886e48
testnet!TDI_ConnComplete+0x2b3
f7a12a18 804f1362 82847db8 827e4c88 82886e48
testnet!TDI_ConnectComplete+0x68
f7a12a48 f3caaad2 8296dd30 827d1c20 00000002 nt!IopfCompleteRequest+0xa2
f7a12a60 f3cb0cc8 827e4c88 00000000 00000000
tcpip!TCPDataRequestComplete+0xa6
f7a12a74 f3cb1ba5 827e4c88 00000000 00000000
tcpip!TCPRequestComplete+0x12
f7a12a94 f3cb3a5a 827d1c20 f7a12c54 00000000 tcpip!CompleteConnReq+0x87
f7a12b18 f3ca7ef5 82a1e008 0100007f 0100007f tcpip!TCPRcv+0xdda
f7a12b78 f3ca7b19 00000020 82a1e008 f3caa076 tcpip!DeliverToUser+0x18e
f7a12bf4 f3ca7836 f3ce73f0 82a1e008 f7a12d10 tcpip!DeliverToUserEx+0x95e
f7a12cac f3cb537e 82a1e008 f7a12d24 0000001c tcpip!IPRcvPacket+0x6cb
f7a12d58 f79133e4 f3ce7180 82a1e008 f3ce7190 tcpip!LoopXmitRtn+0x195
f7a12d74 80534dd0 82a1e008 00000000 82bbada8 TDI!CTEpEventHandler+0x32
f7a12dac 805c5a06 f3ce7180 00000000 00000000 nt!ExpWorkerThread+0x100
f7a12ddc 80541fa2 80534cd0 00000001 00000000
nt!PspSystemThreadStartup+0x34 00000000 00000000 00000000 00000000
00000000 nt!KiThreadStartup+0x16

—
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

10

Is devobj your device object or the one you want to send the io to?
After calling TdiBuildQueryInformation and before IoCallDriver, run !irp
<query_irp value> and see if your completion routine has been properly
set.

Are you sure your completion routine has not been called? Did you set a
bp on it and verify that the breakpoint was not hit? Can you post the
src code to TDI_ConnCompleteEx as well?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of AFei
Sent: Friday, July 21, 2006 5:34 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] TDI_QUERY_ADDRESS_INFO in TDI_CONNECT handler?

Sorry, here is the code:
(in the complete routine of TDI_CONNECT handler):
…
PIRP query_irp = NULL;
query_irp = IoAllocateIrp( devobj->StackSize, FALSE );
if( query_irp )
{
ctx = (PTDI_ADDROBJEX_CTX)ExAllocatePool( NonPagedPool, sizeof
(TDI_ADDROBJEX_CTX) );
if( ctx )
{
ctx->fileobj = connobj;
ctx->tai = (TDI_ADDRESS_INFO *)ExAllocatePool( NonPagedPool,
TDI_ADDRESS_INFO_MAX );
if( ctx->tai )
{
memset( ctx->tai, 0, TDI_ADDRESS_INFO_MAX );
pMdl = IoAllocateMdl( ctx->tai, TDI_ADDRESS_INFO_MAX, FALSE, FALSE,
NULL );
if( pMdl )
{
MmBuildMdlForNonPagedPool( pMdl );
TdiBuildQueryInformation( query_irp, devobj, connobj,
TDI_ConnCompleteEx, ctx, TDI_QUERY_ADDRESS_INFO, pMdl );
Status = IoCallDriver( devobj, query_irp ); **************** crash
inside
…

“Doron Holan” wrote in message
news:xxxxx@ntdev…
I don’t have the original message, pls resend your code

d

– I can spell, I just can’t type.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of AFei
Sent: Friday, July 21, 2006 3:00 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] TDI_QUERY_ADDRESS_INFO in TDI_CONNECT handler?

Hi Doron,

All the IRP init code is there, the complete routine was set in the
macro
TdiBuildQueryInformation(…) (the IoSetCompletionRoutine() was called
inside with my complete routine as a parameter).
But as you said, please take a look the following call stack, it seems
TCPIP finished the data query and trying to complete IRP, at this
moment, system crashed, and my complete routine somehow wasn’t called.
I’m going to dig more. Any hints?

thanks a lot.

STACK_TEXT:
f7a12410 804f880d 00000003 f7a1276c 00000000
nt!RtlpBreakWithStatusInstruction f7a1245c 804f93fa 00000003 00000166
804fb726 nt!KiBugCheckDebugBreak+0x19 f7a1283c 80540853 0000000a
00000166 00000002 nt!KeBugCheck2+0x574 f7a1283c 804fb726 0000000a
00000166 00000002 nt!KiTrap0E+0x233
f7a128e8 804f1498 82886e88 00000000 00000000 nt!KeInsertQueueApc+0x22
f7a1291c f3caaad2 82886edc 82886e48 82886ee0
nt!IopfCompleteRequest+0x1d8 -------------------> ???
f7a12934 f3cb105b 82886e02 00000000 0000001a
tcpip!TCPDataRequestComplete+0xa6
f7a1296c f3cb0be5 82886e48 82886edc 82886e48
tcpip!TCPQueryInformation+0xba
f7a12988 f731bb0f 829a0030 82886e48 829f83cd
tcpip!TCPDispatchInternalDeviceControl+0x182
WARNING: Stack unwind information not available. Following frames may be
wrong.
f7a129a4 804eedf9 829a0030 82886e48 827e4c88 fsdfw+0x7b0f
f7a129b4 f3148b5b 827e4d1f 00000001 82980028 nt!IopfCallDriver+0x31
f7a129e4 f314847a 82847db8 82980028 82886e48
testnet!TDI_ConnComplete+0x2b3
f7a12a18 804f1362 82847db8 827e4c88 82886e48
testnet!TDI_ConnectComplete+0x68
f7a12a48 f3caaad2 8296dd30 827d1c20 00000002 nt!IopfCompleteRequest+0xa2
f7a12a60 f3cb0cc8 827e4c88 00000000 00000000
tcpip!TCPDataRequestComplete+0xa6
f7a12a74 f3cb1ba5 827e4c88 00000000 00000000
tcpip!TCPRequestComplete+0x12
f7a12a94 f3cb3a5a 827d1c20 f7a12c54 00000000 tcpip!CompleteConnReq+0x87
f7a12b18 f3ca7ef5 82a1e008 0100007f 0100007f tcpip!TCPRcv+0xdda
f7a12b78 f3ca7b19 00000020 82a1e008 f3caa076 tcpip!DeliverToUser+0x18e
f7a12bf4 f3ca7836 f3ce73f0 82a1e008 f7a12d10 tcpip!DeliverToUserEx+0x95e
f7a12cac f3cb537e 82a1e008 f7a12d24 0000001c tcpip!IPRcvPacket+0x6cb
f7a12d58 f79133e4 f3ce7180 82a1e008 f3ce7190 tcpip!LoopXmitRtn+0x195
f7a12d74 80534dd0 82a1e008 00000000 82bbada8 TDI!CTEpEventHandler+0x32
f7a12dac 805c5a06 f3ce7180 00000000 00000000 nt!ExpWorkerThread+0x100
f7a12ddc 80541fa2 80534cd0 00000001 00000000
nt!PspSystemThreadStartup+0x34 00000000 00000000 00000000 00000000
00000000 nt!KiThreadStartup+0x16

—
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

—
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</query_irp>

11

Allocate 1 more stack location for the IRP.

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

----- Original Message -----
From: “AFei”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Saturday, July 22, 2006 4:33 AM
Subject: Re:[ntdev] TDI_QUERY_ADDRESS_INFO in TDI_CONNECT handler?

> Sorry, here is the code:
> (in the complete routine of TDI_CONNECT handler):
> …
> PIRP query_irp = NULL;
> query_irp = IoAllocateIrp( devobj->StackSize, FALSE );
> if( query_irp )
> {
> ctx = (PTDI_ADDROBJEX_CTX)ExAllocatePool( NonPagedPool, sizeof
> (TDI_ADDROBJEX_CTX) );
> if( ctx )
> {
> ctx->fileobj = connobj;
> ctx->tai = (TDI_ADDRESS_INFO *)ExAllocatePool( NonPagedPool,
> TDI_ADDRESS_INFO_MAX );
> if( ctx->tai )
> {
> memset( ctx->tai, 0, TDI_ADDRESS_INFO_MAX );
> pMdl = IoAllocateMdl( ctx->tai, TDI_ADDRESS_INFO_MAX, FALSE, FALSE,
> NULL );
> if( pMdl )
> {
> MmBuildMdlForNonPagedPool( pMdl );
> TdiBuildQueryInformation( query_irp, devobj, connobj,
> TDI_ConnCompleteEx, ctx, TDI_QUERY_ADDRESS_INFO, pMdl );
> Status = IoCallDriver( devobj, query_irp ); **************** crash
> inside
> …
>
>
>
> “Doron Holan” wrote in message
> news:xxxxx@ntdev…
> I don’t have the original message, pls resend your code
>
> d
>
> – I can spell, I just can’t type.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of AFei
> Sent: Friday, July 21, 2006 3:00 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] TDI_QUERY_ADDRESS_INFO in TDI_CONNECT handler?
>
> Hi Doron,
>
> All the IRP init code is there, the complete routine was set in the
> macro
> TdiBuildQueryInformation(…) (the IoSetCompletionRoutine() was called
> inside with my complete routine as a parameter).
> But as you said, please take a look the following call stack, it seems
> TCPIP finished the data query and trying to complete IRP, at this
> moment, system crashed, and my complete routine somehow wasn’t called.
> I’m going to dig more. Any hints?
>
> thanks a lot.
>
>
> STACK_TEXT:
> f7a12410 804f880d 00000003 f7a1276c 00000000
> nt!RtlpBreakWithStatusInstruction f7a1245c 804f93fa 00000003 00000166
> 804fb726 nt!KiBugCheckDebugBreak+0x19 f7a1283c 80540853 0000000a
> 00000166 00000002 nt!KeBugCheck2+0x574 f7a1283c 804fb726 0000000a
> 00000166 00000002 nt!KiTrap0E+0x233
> f7a128e8 804f1498 82886e88 00000000 00000000 nt!KeInsertQueueApc+0x22
> f7a1291c f3caaad2 82886edc 82886e48 82886ee0
> nt!IopfCompleteRequest+0x1d8 -------------------> ???
> f7a12934 f3cb105b 82886e02 00000000 0000001a
> tcpip!TCPDataRequestComplete+0xa6
> f7a1296c f3cb0be5 82886e48 82886edc 82886e48
> tcpip!TCPQueryInformation+0xba
> f7a12988 f731bb0f 829a0030 82886e48 829f83cd
> tcpip!TCPDispatchInternalDeviceControl+0x182
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> f7a129a4 804eedf9 829a0030 82886e48 827e4c88 fsdfw+0x7b0f
> f7a129b4 f3148b5b 827e4d1f 00000001 82980028 nt!IopfCallDriver+0x31
> f7a129e4 f314847a 82847db8 82980028 82886e48
> testnet!TDI_ConnComplete+0x2b3
> f7a12a18 804f1362 82847db8 827e4c88 82886e48
> testnet!TDI_ConnectComplete+0x68
> f7a12a48 f3caaad2 8296dd30 827d1c20 00000002 nt!IopfCompleteRequest+0xa2
> f7a12a60 f3cb0cc8 827e4c88 00000000 00000000
> tcpip!TCPDataRequestComplete+0xa6
> f7a12a74 f3cb1ba5 827e4c88 00000000 00000000
> tcpip!TCPRequestComplete+0x12
> f7a12a94 f3cb3a5a 827d1c20 f7a12c54 00000000 tcpip!CompleteConnReq+0x87
> f7a12b18 f3ca7ef5 82a1e008 0100007f 0100007f tcpip!TCPRcv+0xdda
> f7a12b78 f3ca7b19 00000020 82a1e008 f3caa076 tcpip!DeliverToUser+0x18e
> f7a12bf4 f3ca7836 f3ce73f0 82a1e008 f7a12d10 tcpip!DeliverToUserEx+0x95e
> f7a12cac f3cb537e 82a1e008 f7a12d24 0000001c tcpip!IPRcvPacket+0x6cb
> f7a12d58 f79133e4 f3ce7180 82a1e008 f3ce7190 tcpip!LoopXmitRtn+0x195
> f7a12d74 80534dd0 82a1e008 00000000 82bbada8 TDI!CTEpEventHandler+0x32
> f7a12dac 805c5a06 f3ce7180 00000000 00000000 nt!ExpWorkerThread+0x100
> f7a12ddc 80541fa2 80534cd0 00000001 00000000
> nt!PspSystemThreadStartup+0x34 00000000 00000000 00000000 00000000
> 00000000 nt!KiThreadStartup+0x16
>
>
>
>
> —
> 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
>
>
>
> —
> 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

12

I have tried as Lee suggested: query_irp = IoAllocateIrp( devobj->StackSize

  • 1, FALSE );
    , same crash.
    We need one more stack location is because we are rolling one new IRP to the
    device?
    thanks.

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
> Allocate 1 more stack location for the IRP.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> ----- Original Message -----
> From: “AFei”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Saturday, July 22, 2006 4:33 AM
> Subject: Re:[ntdev] TDI_QUERY_ADDRESS_INFO in TDI_CONNECT handler?
>
>
>> Sorry, here is the code:
>> (in the complete routine of TDI_CONNECT handler):
>> …
>> PIRP query_irp = NULL;
>> query_irp = IoAllocateIrp( devobj->StackSize, FALSE );
>> if( query_irp )
>> {
>> ctx = (PTDI_ADDROBJEX_CTX)ExAllocatePool( NonPagedPool, sizeof
>> (TDI_ADDROBJEX_CTX) );
>> if( ctx )
>> {
>> ctx->fileobj = connobj;
>> ctx->tai = (TDI_ADDRESS_INFO *)ExAllocatePool( NonPagedPool,
>> TDI_ADDRESS_INFO_MAX );
>> if( ctx->tai )
>> {
>> memset( ctx->tai, 0, TDI_ADDRESS_INFO_MAX );
>> pMdl = IoAllocateMdl( ctx->tai, TDI_ADDRESS_INFO_MAX, FALSE, FALSE,
>> NULL );
>> if( pMdl )
>> {
>> MmBuildMdlForNonPagedPool( pMdl );
>> TdiBuildQueryInformation( query_irp, devobj, connobj,
>> TDI_ConnCompleteEx, ctx, TDI_QUERY_ADDRESS_INFO, pMdl );
>> Status = IoCallDriver( devobj, query_irp ); **************** crash
>> inside
>> …
>>
>>
>>
>> “Doron Holan” wrote in message
>> news:xxxxx@ntdev…
>> I don’t have the original message, pls resend your code
>>
>> d
>>
>> – I can spell, I just can’t type.
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of AFei
>> Sent: Friday, July 21, 2006 3:00 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re:[ntdev] TDI_QUERY_ADDRESS_INFO in TDI_CONNECT handler?
>>
>> Hi Doron,
>>
>> All the IRP init code is there, the complete routine was set in the
>> macro
>> TdiBuildQueryInformation(…) (the IoSetCompletionRoutine() was called
>> inside with my complete routine as a parameter).
>> But as you said, please take a look the following call stack, it seems
>> TCPIP finished the data query and trying to complete IRP, at this
>> moment, system crashed, and my complete routine somehow wasn’t called.
>> I’m going to dig more. Any hints?
>>
>> thanks a lot.
>>
>>
>> STACK_TEXT:
>> f7a12410 804f880d 00000003 f7a1276c 00000000
>> nt!RtlpBreakWithStatusInstruction f7a1245c 804f93fa 00000003 00000166
>> 804fb726 nt!KiBugCheckDebugBreak+0x19 f7a1283c 80540853 0000000a
>> 00000166 00000002 nt!KeBugCheck2+0x574 f7a1283c 804fb726 0000000a
>> 00000166 00000002 nt!KiTrap0E+0x233
>> f7a128e8 804f1498 82886e88 00000000 00000000 nt!KeInsertQueueApc+0x22
>> f7a1291c f3caaad2 82886edc 82886e48 82886ee0
>> nt!IopfCompleteRequest+0x1d8 -------------------> ???
>> f7a12934 f3cb105b 82886e02 00000000 0000001a
>> tcpip!TCPDataRequestComplete+0xa6
>> f7a1296c f3cb0be5 82886e48 82886edc 82886e48
>> tcpip!TCPQueryInformation+0xba
>> f7a12988 f731bb0f 829a0030 82886e48 829f83cd
>> tcpip!TCPDispatchInternalDeviceControl+0x182
>> WARNING: Stack unwind information not available. Following frames may be
>> wrong.
>> f7a129a4 804eedf9 829a0030 82886e48 827e4c88 fsdfw+0x7b0f
>> f7a129b4 f3148b5b 827e4d1f 00000001 82980028 nt!IopfCallDriver+0x31
>> f7a129e4 f314847a 82847db8 82980028 82886e48
>> testnet!TDI_ConnComplete+0x2b3
>> f7a12a18 804f1362 82847db8 827e4c88 82886e48
>> testnet!TDI_ConnectComplete+0x68
>> f7a12a48 f3caaad2 8296dd30 827d1c20 00000002 nt!IopfCompleteRequest+0xa2
>> f7a12a60 f3cb0cc8 827e4c88 00000000 00000000
>> tcpip!TCPDataRequestComplete+0xa6
>> f7a12a74 f3cb1ba5 827e4c88 00000000 00000000
>> tcpip!TCPRequestComplete+0x12
>> f7a12a94 f3cb3a5a 827d1c20 f7a12c54 00000000 tcpip!CompleteConnReq+0x87
>> f7a12b18 f3ca7ef5 82a1e008 0100007f 0100007f tcpip!TCPRcv+0xdda
>> f7a12b78 f3ca7b19 00000020 82a1e008 f3caa076 tcpip!DeliverToUser+0x18e
>> f7a12bf4 f3ca7836 f3ce73f0 82a1e008 f7a12d10 tcpip!DeliverToUserEx+0x95e
>> f7a12cac f3cb537e 82a1e008 f7a12d24 0000001c tcpip!IPRcvPacket+0x6cb
>> f7a12d58 f79133e4 f3ce7180 82a1e008 f3ce7190 tcpip!LoopXmitRtn+0x195
>> f7a12d74 80534dd0 82a1e008 00000000 82bbada8 TDI!CTEpEventHandler+0x32
>> f7a12dac 805c5a06 f3ce7180 00000000 00000000 nt!ExpWorkerThread+0x100
>> f7a12ddc 80541fa2 80534cd0 00000001 00000000
>> nt!PspSystemThreadStartup+0x34 00000000 00000000 00000000 00000000
>> 00000000 nt!KiThreadStartup+0x16
>>
>>
>>
>>
>> —
>> 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
>>
>>
>>
>> —
>> 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
>
>

13

Technically no since your completion is set in the next stack location,
so there is no real need for your own.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of AFei
Sent: Sunday, July 23, 2006 9:38 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:TDI_QUERY_ADDRESS_INFO in TDI_CONNECT handler?

I have tried as Lee suggested: query_irp = IoAllocateIrp(
devobj->StackSize

  • 1, FALSE );
    , same crash.
    We need one more stack location is because we are rolling one new IRP to
    the
    device?
    thanks.

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
> Allocate 1 more stack location for the IRP.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> ----- Original Message -----
> From: “AFei”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Saturday, July 22, 2006 4:33 AM
> Subject: Re:[ntdev] TDI_QUERY_ADDRESS_INFO in TDI_CONNECT handler?
>
>
>> Sorry, here is the code:
>> (in the complete routine of TDI_CONNECT handler):
>> …
>> PIRP query_irp = NULL;
>> query_irp = IoAllocateIrp( devobj->StackSize, FALSE );
>> if( query_irp )
>> {
>> ctx = (PTDI_ADDROBJEX_CTX)ExAllocatePool( NonPagedPool, sizeof
>> (TDI_ADDROBJEX_CTX) );
>> if( ctx )
>> {
>> ctx->fileobj = connobj;
>> ctx->tai = (TDI_ADDRESS_INFO *)ExAllocatePool( NonPagedPool,
>> TDI_ADDRESS_INFO_MAX );
>> if( ctx->tai )
>> {
>> memset( ctx->tai, 0, TDI_ADDRESS_INFO_MAX );
>> pMdl = IoAllocateMdl( ctx->tai, TDI_ADDRESS_INFO_MAX, FALSE,
FALSE,
>> NULL );
>> if( pMdl )
>> {
>> MmBuildMdlForNonPagedPool( pMdl );
>> TdiBuildQueryInformation( query_irp, devobj, connobj,
>> TDI_ConnCompleteEx, ctx, TDI_QUERY_ADDRESS_INFO, pMdl );
>> Status = IoCallDriver( devobj, query_irp ); ****************
crash
>> inside
>> …
>>
>>
>>
>> “Doron Holan” wrote in message
>> news:xxxxx@ntdev…
>> I don’t have the original message, pls resend your code
>>
>> d
>>
>> – I can spell, I just can’t type.
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of AFei
>> Sent: Friday, July 21, 2006 3:00 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re:[ntdev] TDI_QUERY_ADDRESS_INFO in TDI_CONNECT handler?
>>
>> Hi Doron,
>>
>> All the IRP init code is there, the complete routine was set in the
>> macro
>> TdiBuildQueryInformation(…) (the IoSetCompletionRoutine() was
called
>> inside with my complete routine as a parameter).
>> But as you said, please take a look the following call stack, it
seems
>> TCPIP finished the data query and trying to complete IRP, at this
>> moment, system crashed, and my complete routine somehow wasn’t
called.
>> I’m going to dig more. Any hints?
>>
>> thanks a lot.
>>
>>
>> STACK_TEXT:
>> f7a12410 804f880d 00000003 f7a1276c 00000000
>> nt!RtlpBreakWithStatusInstruction f7a1245c 804f93fa 00000003 00000166
>> 804fb726 nt!KiBugCheckDebugBreak+0x19 f7a1283c 80540853 0000000a
>> 00000166 00000002 nt!KeBugCheck2+0x574 f7a1283c 804fb726 0000000a
>> 00000166 00000002 nt!KiTrap0E+0x233
>> f7a128e8 804f1498 82886e88 00000000 00000000 nt!KeInsertQueueApc+0x22
>> f7a1291c f3caaad2 82886edc 82886e48 82886ee0
>> nt!IopfCompleteRequest+0x1d8 -------------------> ???
>> f7a12934 f3cb105b 82886e02 00000000 0000001a
>> tcpip!TCPDataRequestComplete+0xa6
>> f7a1296c f3cb0be5 82886e48 82886edc 82886e48
>> tcpip!TCPQueryInformation+0xba
>> f7a12988 f731bb0f 829a0030 82886e48 829f83cd
>> tcpip!TCPDispatchInternalDeviceControl+0x182
>> WARNING: Stack unwind information not available. Following frames may
be
>> wrong.
>> f7a129a4 804eedf9 829a0030 82886e48 827e4c88 fsdfw+0x7b0f
>> f7a129b4 f3148b5b 827e4d1f 00000001 82980028 nt!IopfCallDriver+0x31
>> f7a129e4 f314847a 82847db8 82980028 82886e48
>> testnet!TDI_ConnComplete+0x2b3
>> f7a12a18 804f1362 82847db8 827e4c88 82886e48
>> testnet!TDI_ConnectComplete+0x68
>> f7a12a48 f3caaad2 8296dd30 827d1c20 00000002
nt!IopfCompleteRequest+0xa2
>> f7a12a60 f3cb0cc8 827e4c88 00000000 00000000
>> tcpip!TCPDataRequestComplete+0xa6
>> f7a12a74 f3cb1ba5 827e4c88 00000000 00000000
>> tcpip!TCPRequestComplete+0x12
>> f7a12a94 f3cb3a5a 827d1c20 f7a12c54 00000000
tcpip!CompleteConnReq+0x87
>> f7a12b18 f3ca7ef5 82a1e008 0100007f 0100007f tcpip!TCPRcv+0xdda
>> f7a12b78 f3ca7b19 00000020 82a1e008 f3caa076
tcpip!DeliverToUser+0x18e
>> f7a12bf4 f3ca7836 f3ce73f0 82a1e008 f7a12d10
tcpip!DeliverToUserEx+0x95e
>> f7a12cac f3cb537e 82a1e008 f7a12d24 0000001c tcpip!IPRcvPacket+0x6cb
>> f7a12d58 f79133e4 f3ce7180 82a1e008 f3ce7190 tcpip!LoopXmitRtn+0x195
>> f7a12d74 80534dd0 82a1e008 00000000 82bbada8
TDI!CTEpEventHandler+0x32
>> f7a12dac 805c5a06 f3ce7180 00000000 00000000 nt!ExpWorkerThread+0x100
>> f7a12ddc 80541fa2 80534cd0 00000001 00000000
>> nt!PspSystemThreadStartup+0x34 00000000 00000000 00000000 00000000
>> 00000000 nt!KiThreadStartup+0x16
>>
>>
>>
>>
>> —
>> 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
>>
>>
>>
>> —
>> 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
>
>

—
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

14

However, AFAIK, the DeviceObject argument to the CRTN may be ‘undefined’ in
this case and cannot be relied on. The Context argument, however, comes
(like the CRTN address) from the ‘next’ stack location.

Is it possible that the OP has inadvertantly expected the CRTN argument
DevObj to be ‘relevant’ to the completion and has mucked up the works by
using the passed value?

I appologize for not having paid close attention to the ideas already
proffered in this thread. I don’t recall, however, seeing the OP post the
code for the CRTN TDI_ConnCompleteEx() which (as I believe Doron postulated)
*must* be getting called. Is it possible that the CRTN
TDI_ConnCompleteEx() is failing to return the
STATUS_MORE_PROCESSING_REQUIRED result because it is goofed into a code path
by expecting that the DeviceObject parameter actually points at something?

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Sunday, July 23, 2006 12:47 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Re:TDI_QUERY_ADDRESS_INFO in TDI_CONNECT handler?

Technically no since your completion is set in the next stack location, so
there is no real need for your own.

d

15

He has not yet posted the completion routine (CR) code. Even if you add
a stack location, the DeviceObject passed to the CR is still NULL. You
have to do more setup work before sending the PIRP to make sure the
DeviceObject parameter != NULL

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Sunday, July 23, 2006 6:12 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Re:TDI_QUERY_ADDRESS_INFO in TDI_CONNECT handler?

However, AFAIK, the DeviceObject argument to the CRTN may be ‘undefined’
in
this case and cannot be relied on. The Context argument, however, comes
(like the CRTN address) from the ‘next’ stack location.

Is it possible that the OP has inadvertantly expected the CRTN argument
DevObj to be ‘relevant’ to the completion and has mucked up the works by
using the passed value?

I appologize for not having paid close attention to the ideas already
proffered in this thread. I don’t recall, however, seeing the OP post
the
code for the CRTN TDI_ConnCompleteEx() which (as I believe Doron
postulated)
*must* be getting called. Is it possible that the CRTN
TDI_ConnCompleteEx() is failing to return the
STATUS_MORE_PROCESSING_REQUIRED result because it is goofed into a code
path
by expecting that the DeviceObject parameter actually points at
something?

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Sunday, July 23, 2006 12:47 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Re:TDI_QUERY_ADDRESS_INFO in TDI_CONNECT handler?

Technically no since your completion is set in the next stack location,
so
there is no real need for your own.

d

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

16

Right. Simply allocating the IRP with an extra stack location is not
enough. IoSetNextIrpStackLocation() must be called and
IoGetCurrentIrpStackLocation() must be used to fetch the iosp to use to
stuff the DeviceObject value into or some other relatively equivalent set of
IRP SP manipulations. I am just wondering if the OP is inadvertantly
relying on the value of the DeviceObject arg to be non-null.

Thanks for the correction/amplification.

Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Sunday, July 23, 2006 9:21 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Re:TDI_QUERY_ADDRESS_INFO in TDI_CONNECT handler?

He has not yet posted the completion routine (CR) code. Even if you add a
stack location, the DeviceObject passed to the CR is still NULL. You have
to do more setup work before sending the PIRP to make sure the DeviceObject
parameter != NULL

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Sunday, July 23, 2006 6:12 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Re:TDI_QUERY_ADDRESS_INFO in TDI_CONNECT handler?

However, AFAIK, the DeviceObject argument to the CRTN may be ‘undefined’
in
this case and cannot be relied on. The Context argument, however, comes
(like the CRTN address) from the ‘next’ stack location.

Is it possible that the OP has inadvertantly expected the CRTN argument
DevObj to be ‘relevant’ to the completion and has mucked up the works by
using the passed value?

I appologize for not having paid close attention to the ideas already
proffered in this thread. I don’t recall, however, seeing the OP post the
code for the CRTN TDI_ConnCompleteEx() which (as I believe Doron
postulated)
*must* be getting called. Is it possible that the CRTN
TDI_ConnCompleteEx() is failing to return the
STATUS_MORE_PROCESSING_REQUIRED result because it is goofed into a code path
by expecting that the DeviceObject parameter actually points at something?

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Sunday, July 23, 2006 12:47 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Re:TDI_QUERY_ADDRESS_INFO in TDI_CONNECT handler?

Technically no since your completion is set in the next stack location, so
there is no real need for your own.

d

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

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

17

>He has not yet posted the completion routine (CR) code. Even if you add

a stack location, the DeviceObject passed to the CR is still NULL.

To avoid this:

  • allocate 1 more stack location
  • then
    IoSetNextIrpStackLocation(Irp);
    IoGetCurrentIrpStackLocation(Irp)->DeviceObject = MyDeviceObject;
  • then set the completion routine, fill the next stack location and do
    IoCallDriver

In this case, DeviceObject argument to the completion routine will be
MyDeviceObject.

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

18

Thank you all, it works now!
Based on your suggestions, I carefully ran the codes step by step in
debugger, you guys are right, my complete routine actually was called before
the crash, the crash comes from I simply returned the STATUS_SUCCESS in the
CR, the CR DeviceObject is NULL but I didn’t rely on this pointer, still I
have it fixed. :slight_smile:
And now the code is like this:

TDI_CONNECT complete routine:

…
ctx = ExAllocatePool(…)
pMdl = IoAllocateMdl(…)
qirp = IoAllocateIrp( devobj->StackSize + 1, FALSE );
MmBuildMdlForNonPagedPool( pMdl );
IoSetNextIrpStackLocation( qirp );
cirps = IoGetCurrentIrpStackLocation( qirp );
cirps->DeviceObject = devobj; // this makes DeviceObject != NULL
TdiBuildQueryInformation( qirp, devobj, connobj, TDI_ConnCompleteEx, ctx,
TDI_QUERRY_ADDRESS_INFO, pMdl );
IoCallDriver( devobj, qirp );
…

TDI_ConnCompleteEx(…)

…// log stuff
if( Irp->MdlAddress ) IoFreeMdl( Irp->MdlAddress );
ExFreePool( ctx );
return STATUS_MORE_PROCESSING_REQUIRED; // *** important
}

So, to make myself understand more of this problem, why we have to return
STATUS_MORE_PROCESSING_REQUIRED in our complete routine all the time? is it
because we have to return the control to the original TDI_CONNECT CR? Also,
to put the code into a product level, is my code safe? should I take care of
other cases for this function?

Again, thanks so much for all of your great analysis!

AFei

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
> >He has not yet posted the completion routine (CR) code. Even if you add
>>a stack location, the DeviceObject passed to the CR is still NULL.
>
> To avoid this:
> - allocate 1 more stack location
> - then
> IoSetNextIrpStackLocation(Irp);
> IoGetCurrentIrpStackLocation(Irp)->DeviceObject = MyDeviceObject;
> - then set the completion routine, fill the next stack location and do
> IoCallDriver
>
> In this case, DeviceObject argument to the completion routine will be
> MyDeviceObject.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>