Problem Cancelling a TDI Receive

OSR_Community_User · July 29, 2003, 7:02pm

Hi,

I am facing a problem while cancelling a receive irp issued to a
tdi tcp end point. I understand that this problem might be specific
to my driver, but I am hoping someone might have faced similar issue
and might be able to help.

Normal i/o and a few (hundreds) cancels happen succesfully. However,
every once in a while the dual processor windows 2000 server SP4 machine
bug checks with bug code 0xD1 with stack attached below. I unmap the
mdl buffers in my routine that issues the receive, after I ensure that
my completion routine is called (in this case for cancel of irp), ie.
irp->IoStatus.Status == STATUS_CANCELLED;

Hope someone on the list has some suggestions for me to try/ or insights
into what I might be doing wrong else I might have to go to a different
design and implementation. Thanks in advance for any help.
-Shyam

My pseudo code:
mdl = IoAllocateMdl
MmProbeAndLockPages
IoAllocateIrp
TdiBuildReceive
IoCallDriver
status = KeWaitForSingleObject
if (status == STATUS_TIMEOUT)
IoCancelIrp
MmUnlockPages (mdl)
IoFreeMdl
IoFreeIrp

In my completion routine for the above irp, I always return
STATUS_MORE_PROCESSING_REQUIRED, to the irp stays valid in the
allocating routine.

!analyze -v info is as follows:

0: kd> !analyze -v
*******************************************************************************

*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

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

Debugging Details:

READ_ADDRESS: 00000020

CURRENT_IRQL: 2

FAULTING_IP:
tcpip!BufferData+42
f1e3ac85 8b5320 mov edx,[ebx+0x20]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from 8042aa0f to 804564d0

STACK_TEXT:
80473d68 8042aa0f 00000003 80473db0 00000020
nt!RtlpBreakWithStatusInstruction
80473d98 8042b002 00000003 00000020 f1e3ac85 nt!KiBugCheckDebugBreak+0x31
80474124 8046987c 00000000 00000020 00000002 nt!KeBugCheckEx+0x390
80474124 f1e3ac85 00000000 00000020 00000002 nt!KiTrap0E+0x284
804741e0 f1e26466 8187c5c8 00001050 804742fc tcpip!BufferData+0x42
80474248 f1e2415d 00000000 8504020a b304020a tcpip!TCPRcv+0xad1
80474294 f1e2405d f1e261c7 8190a148 81e4300e tcpip!DeliverToUser+0xf9
8047434c f1e2398c 8190a148 81e43022 000005c8 tcpip!IPRcvPacket+0x5f8
8047438c f1e239ed 00000000 81ed3a7c 81e43000
tcpip!ARPRcvIndicationNew+0x172
804743c8 f87c1183 81910d48 00000000 00000000 tcpip!ARPRcvPacket+0x5c
80474420 f1f8d757 81fa8b00 80474440 00000008
NDIS!ethFilterDprIndicateReceivePacket+0x2ea
WARNING: Stack unwind information not available. Following frames may be
wrong.
80474554 f1f8d4fb 81f9e008 80474580 81f9e35c e1000nt5+0x757
80474578 f87aabb8 81f9e000 80470370 ffdff848 e1000nt5+0x4fb
8047458c 80465728 81f9e370 81f9e35c 00000000 NDIS!ndisMDpcX+0x2b
804745a4 80465680 0000000e 00000000 00000000 nt!KiRetireDpcList+0x47
804745ac 00000000 00000000 00000000 00000000 nt!KiIdleLoop+0x28

FOLLOWUP_IP:
tcpip!BufferData+42
f1e3ac85 8b5320 mov edx,[ebx+0x20]

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: tcpip!BufferData+42

MODULE_NAME: tcpip

IMAGE_NAME: tcpip.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3eaf053b

STACK_COMMAND: kb

BUCKET_ID: 0xD1_tcpip!BufferData+42

Followup: MachineOwner

Srin_Kumar · July 29, 2003, 7:18pm

Shyam,
The code is ending up accessing a null pointer. BufferData
function is looking for something at offset 20 of NULL pointer. You need
to disassemble the function and see what the function is trying to
access. That would give you a tip.

-Srin.

-----Original Message-----
From: Shyam [mailto:xxxxx@vormetric.com]
Sent: Tuesday, July 29, 2003 4:02 PM
To: Windows System Software Developers Interest List
Subject: [ntdev] Problem Cancelling a TDI Receive

Hi,

I am facing a problem while cancelling a receive irp issued to a
tdi tcp end point. I understand that this problem might be specific
to my driver, but I am hoping someone might have faced similar issue
and might be able to help.

Normal i/o and a few (hundreds) cancels happen succesfully. However,
every once in a while the dual processor windows 2000 server SP4
machine
bug checks with bug code 0xD1 with stack attached below. I unmap the
mdl buffers in my routine that issues the receive, after I ensure that
my completion routine is called (in this case for cancel of irp), ie.
irp->IoStatus.Status == STATUS_CANCELLED;

Hope someone on the list has some suggestions for me to try/ or
insights
into what I might be doing wrong else I might have to go to a
different
design and implementation. Thanks in advance for any help.
-Shyam

My pseudo code:
mdl = IoAllocateMdl
MmProbeAndLockPages
IoAllocateIrp
TdiBuildReceive
IoCallDriver
status = KeWaitForSingleObject
if (status == STATUS_TIMEOUT)
IoCancelIrp
MmUnlockPages (mdl)
IoFreeMdl
IoFreeIrp

In my completion routine for the above irp, I always return
STATUS_MORE_PROCESSING_REQUIRED, to the irp stays valid in the
allocating routine.

!analyze -v info is as follows:

0: kd> !analyze -v

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

*****

*
*
* Bugcheck Analysis
*
*
*

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

*****

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

Debugging Details:

READ_ADDRESS: 00000020

CURRENT_IRQL: 2

FAULTING_IP:
tcpip!BufferData+42
f1e3ac85 8b5320 mov edx,[ebx+0x20]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from 8042aa0f to 804564d0

STACK_TEXT:
80473d68 8042aa0f 00000003 80473db0 00000020
nt!RtlpBreakWithStatusInstruction
80473d98 8042b002 00000003 00000020 f1e3ac85
nt!KiBugCheckDebugBreak+0x31
80474124 8046987c 00000000 00000020 00000002 nt!KeBugCheckEx+0x390
80474124 f1e3ac85 00000000 00000020 00000002 nt!KiTrap0E+0x284
804741e0 f1e26466 8187c5c8 00001050 804742fc tcpip!BufferData+0x42
80474248 f1e2415d 00000000 8504020a b304020a tcpip!TCPRcv+0xad1
80474294 f1e2405d f1e261c7 8190a148 81e4300e tcpip!DeliverToUser+0xf9
8047434c f1e2398c 8190a148 81e43022 000005c8 tcpip!IPRcvPacket+0x5f8
8047438c f1e239ed 00000000 81ed3a7c 81e43000
tcpip!ARPRcvIndicationNew+0x172
804743c8 f87c1183 81910d48 00000000 00000000 tcpip!ARPRcvPacket+0x5c
80474420 f1f8d757 81fa8b00 80474440 00000008
NDIS!ethFilterDprIndicateReceivePacket+0x2ea
WARNING: Stack unwind information not available. Following frames may
be
wrong.
80474554 f1f8d4fb 81f9e008 80474580 81f9e35c e1000nt5+0x757
80474578 f87aabb8 81f9e000 80470370 ffdff848 e1000nt5+0x4fb
8047458c 80465728 81f9e370 81f9e35c 00000000 NDIS!ndisMDpcX+0x2b
804745a4 80465680 0000000e 00000000 00000000 nt!KiRetireDpcList+0x47
804745ac 00000000 00000000 00000000 00000000 nt!KiIdleLoop+0x28

FOLLOWUP_IP:
tcpip!BufferData+42
f1e3ac85 8b5320 mov edx,[ebx+0x20]

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: tcpip!BufferData+42

MODULE_NAME: tcpip

IMAGE_NAME: tcpip.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3eaf053b

STACK_COMMAND: kb

BUCKET_ID: 0xD1_tcpip!BufferData+42

Followup: MachineOwner

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@nai.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · July 29, 2003, 7:36pm

Thanks Srini,

I did my due investigation into this problem for more than a day,
before posting. I was also looking for info along the lines of
if tdi supports cancels cleanly and if others on the group have
done cancels of tdi irps, if they had problems with it. I already
know that the tcp!BufferData routine is attempting to pass the data
upstream, and the possibility that I just unmapped the buffer that
it is trying to copy to (thereby null pointer derefernce). Further,
I know the fact that I just unmapped the buffer on one proc while
the bugcheck happens on other proc.

I believe there was a bug in my first posting - pseudo code, I missed
a line which I included below.

mdl = IoAllocateMdl
MmProbeAndLockPages
IoAllocateIrp
TdiBuildReceive
IoCallDriver
status = KeWaitForSingleObject
if (status == STATUS_TIMEOUT)
IoCancelIrp
>>>>>>>>>>> KeWaitForSingleObject // missed line in original posting.
MmUnlockPages (mdl)
IoFreeMdl
IoFreeIrp

Thanks again.

-Shyam

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of xxxxx@NAI.com
Sent: Tuesday, July 29, 2003 4:18 PM
To: Windows System Software Developers Interest List
Subject: [ntdev] RE: Problem Cancelling a TDI Receive

Shyam,
The code is ending up accessing a null pointer. BufferData
function is looking for something at offset 20 of NULL pointer. You need
to disassemble the function and see what the function is trying to
access. That would give you a tip.

-Srin.

-----Original Message-----
From: Shyam [mailto:xxxxx@vormetric.com]
Sent: Tuesday, July 29, 2003 4:02 PM
To: Windows System Software Developers Interest List
Subject: [ntdev] Problem Cancelling a TDI Receive

Hi,

I am facing a problem while cancelling a receive irp issued to a
tdi tcp end point. I understand that this problem might be specific
to my driver, but I am hoping someone might have faced similar issue
and might be able to help.

Normal i/o and a few (hundreds) cancels happen succesfully. However,
every once in a while the dual processor windows 2000 server SP4
machine
bug checks with bug code 0xD1 with stack attached below. I unmap the
mdl buffers in my routine that issues the receive, after I ensure that
my completion routine is called (in this case for cancel of irp), ie.
irp->IoStatus.Status == STATUS_CANCELLED;

Hope someone on the list has some suggestions for me to try/ or
insights
into what I might be doing wrong else I might have to go to a
different
design and implementation. Thanks in advance for any help.
-Shyam

My pseudo code:
mdl = IoAllocateMdl
MmProbeAndLockPages
IoAllocateIrp
TdiBuildReceive
IoCallDriver
status = KeWaitForSingleObject
if (status == STATUS_TIMEOUT)
IoCancelIrp
MmUnlockPages (mdl)
IoFreeMdl
IoFreeIrp

In my completion routine for the above irp, I always return
STATUS_MORE_PROCESSING_REQUIRED, to the irp stays valid in the
allocating routine.

!analyze -v info is as follows:

0: kd> !analyze -v

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

*****

*
*
* Bugcheck Analysis
*
*
*

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

*****

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

Debugging Details:

READ_ADDRESS: 00000020

CURRENT_IRQL: 2

FAULTING_IP:
tcpip!BufferData+42
f1e3ac85 8b5320 mov edx,[ebx+0x20]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from 8042aa0f to 804564d0

STACK_TEXT:
80473d68 8042aa0f 00000003 80473db0 00000020
nt!RtlpBreakWithStatusInstruction
80473d98 8042b002 00000003 00000020 f1e3ac85
nt!KiBugCheckDebugBreak+0x31
80474124 8046987c 00000000 00000020 00000002 nt!KeBugCheckEx+0x390
80474124 f1e3ac85 00000000 00000020 00000002 nt!KiTrap0E+0x284
804741e0 f1e26466 8187c5c8 00001050 804742fc tcpip!BufferData+0x42
80474248 f1e2415d 00000000 8504020a b304020a tcpip!TCPRcv+0xad1
80474294 f1e2405d f1e261c7 8190a148 81e4300e tcpip!DeliverToUser+0xf9
8047434c f1e2398c 8190a148 81e43022 000005c8 tcpip!IPRcvPacket+0x5f8
8047438c f1e239ed 00000000 81ed3a7c 81e43000
tcpip!ARPRcvIndicationNew+0x172
804743c8 f87c1183 81910d48 00000000 00000000 tcpip!ARPRcvPacket+0x5c
80474420 f1f8d757 81fa8b00 80474440 00000008
NDIS!ethFilterDprIndicateReceivePacket+0x2ea
WARNING: Stack unwind information not available. Following frames may
be
wrong.
80474554 f1f8d4fb 81f9e008 80474580 81f9e35c e1000nt5+0x757
80474578 f87aabb8 81f9e000 80470370 ffdff848 e1000nt5+0x4fb
8047458c 80465728 81f9e370 81f9e35c 00000000 NDIS!ndisMDpcX+0x2b
804745a4 80465680 0000000e 00000000 00000000 nt!KiRetireDpcList+0x47
804745ac 00000000 00000000 00000000 00000000 nt!KiIdleLoop+0x28

FOLLOWUP_IP:
tcpip!BufferData+42
f1e3ac85 8b5320 mov edx,[ebx+0x20]

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: tcpip!BufferData+42

MODULE_NAME: tcpip

IMAGE_NAME: tcpip.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3eaf053b

STACK_COMMAND: kb

BUCKET_ID: 0xD1_tcpip!BufferData+42

Followup: MachineOwner

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@nai.com
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: xxxxx@vormetric.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Maxim_S_Shatskih · July 29, 2003, 8:30pm

Why use TDI_RECEIVE at all?
In my kernel sockets implementation, TDI_RECEIVE is sent only after
STATUS_DATA_NOT_ACCEPTED is returned from ClientEventReceive, and the
cancellation is not necessary at all since there is some data for sure in the
TDI endpoint.
All other receive is done using ClientEvent(Chained)Receive.

Max

----- Original Message -----
From: “Nagaraj Shyam”
To: “Windows System Software Developers Interest List”
Sent: Wednesday, July 30, 2003 3:36 AM
Subject: [ntdev] RE: Problem Cancelling a TDI Receive

> Thanks Srini,
>
> I did my due investigation into this problem for more than a day,
> before posting. I was also looking for info along the lines of
> if tdi supports cancels cleanly and if others on the group have
> done cancels of tdi irps, if they had problems with it. I already
> know that the tcp!BufferData routine is attempting to pass the data
> upstream, and the possibility that I just unmapped the buffer that
> it is trying to copy to (thereby null pointer derefernce). Further,
> I know the fact that I just unmapped the buffer on one proc while
> the bugcheck happens on other proc.
>
> I believe there was a bug in my first posting - pseudo code, I missed
> a line which I included below.
>
> > mdl = IoAllocateMdl
> > MmProbeAndLockPages
> > IoAllocateIrp
> > TdiBuildReceive
> > IoCallDriver
> > status = KeWaitForSingleObject
> > if (status == STATUS_TIMEOUT)
> > IoCancelIrp
> >>>>>>>>>>>> KeWaitForSingleObject // missed line in original posting.
> > MmUnlockPages (mdl)
> > IoFreeMdl
> > IoFreeIrp
>
>
> Thanks again.
>
> -Shyam
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of xxxxx@NAI.com
> Sent: Tuesday, July 29, 2003 4:18 PM
> To: Windows System Software Developers Interest List
> Subject: [ntdev] RE: Problem Cancelling a TDI Receive
>
>
> Shyam,
> The code is ending up accessing a null pointer. BufferData
> function is looking for something at offset 20 of NULL pointer. You need
> to disassemble the function and see what the function is trying to
> access. That would give you a tip.
>
> -Srin.
>
> > -----Original Message-----
> > From: Shyam [mailto:xxxxx@vormetric.com]
> > Sent: Tuesday, July 29, 2003 4:02 PM
> > To: Windows System Software Developers Interest List
> > Subject: [ntdev] Problem Cancelling a TDI Receive
> >
> > Hi,
> >
> > I am facing a problem while cancelling a receive irp issued to a
> > tdi tcp end point. I understand that this problem might be specific
> > to my driver, but I am hoping someone might have faced similar issue
> > and might be able to help.
> >
> > Normal i/o and a few (hundreds) cancels happen succesfully. However,
> > every once in a while the dual processor windows 2000 server SP4
> machine
> > bug checks with bug code 0xD1 with stack attached below. I unmap the
> > mdl buffers in my routine that issues the receive, after I ensure that
> > my completion routine is called (in this case for cancel of irp), ie.
> > irp->IoStatus.Status == STATUS_CANCELLED;
> >
> > Hope someone on the list has some suggestions for me to try/ or
> insights
> > into what I might be doing wrong else I might have to go to a
> different
> > design and implementation. Thanks in advance for any help.
> > -Shyam
> >
> > My pseudo code:
> > mdl = IoAllocateMdl
> > MmProbeAndLockPages
> > IoAllocateIrp
> > TdiBuildReceive
> > IoCallDriver
> > status = KeWaitForSingleObject
> > if (status == STATUS_TIMEOUT)
> > IoCancelIrp
> > MmUnlockPages (mdl)
> > IoFreeMdl
> > IoFreeIrp
> >
> > In my completion routine for the above irp, I always return
> > STATUS_MORE_PROCESSING_REQUIRED, to the irp stays valid in the
> > allocating routine.
> >
> > !analyze -v info is as follows:
> >
> > 0: kd> !analyze -v
> >
> *****
>
> >
> >
> >
> >
> >
> > * Bugcheck Analysis
> >
> >
> >
> >
>
>
> >
> >
> >
> >
> > DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
> > An attempt was made to access a pagable (or completely invalid)
> address at
> > an
> > interrupt request level (IRQL) that is too high. This is usually
> > caused by drivers using improper addresses.
> > If kernel debugger is available get stack backtrace.
> > Arguments:
> > Arg1: 00000020, memory referenced
> > Arg2: 00000002, IRQL
> > Arg3: 00000000, value 0 = read operation, 1 = write operation
> > Arg4: f1e3ac85, address which referenced memory
> >
> > Debugging Details:
> > ------------------
> >
> >
> > READ_ADDRESS: 00000020
> >
> > CURRENT_IRQL: 2
> >
> > FAULTING_IP:
> > tcpip!BufferData+42
> > f1e3ac85 8b5320 mov edx,[ebx+0x20]
> >
> > DEFAULT_BUCKET_ID: DRIVER_FAULT
> >
> > BUGCHECK_STR: 0xD1
> >
> > LAST_CONTROL_TRANSFER: from 8042aa0f to 804564d0
> >
> > STACK_TEXT:
> > 80473d68 8042aa0f 00000003 80473db0 00000020
> > nt!RtlpBreakWithStatusInstruction
> > 80473d98 8042b002 00000003 00000020 f1e3ac85
> nt!KiBugCheckDebugBreak+0x31
> > 80474124 8046987c 00000000 00000020 00000002 nt!KeBugCheckEx+0x390
> > 80474124 f1e3ac85 00000000 00000020 00000002 nt!KiTrap0E+0x284
> > 804741e0 f1e26466 8187c5c8 00001050 804742fc tcpip!BufferData+0x42
> > 80474248 f1e2415d 00000000 8504020a b304020a tcpip!TCPRcv+0xad1
> > 80474294 f1e2405d f1e261c7 8190a148 81e4300e tcpip!DeliverToUser+0xf9
> > 8047434c f1e2398c 8190a148 81e43022 000005c8 tcpip!IPRcvPacket+0x5f8
> > 8047438c f1e239ed 00000000 81ed3a7c 81e43000
> > tcpip!ARPRcvIndicationNew+0x172
> > 804743c8 f87c1183 81910d48 00000000 00000000 tcpip!ARPRcvPacket+0x5c
> > 80474420 f1f8d757 81fa8b00 80474440 00000008
> > NDIS!ethFilterDprIndicateReceivePacket+0x2ea
> > WARNING: Stack unwind information not available. Following frames may
> be
> > wrong.
> > 80474554 f1f8d4fb 81f9e008 80474580 81f9e35c e1000nt5+0x757
> > 80474578 f87aabb8 81f9e000 80470370 ffdff848 e1000nt5+0x4fb
> > 8047458c 80465728 81f9e370 81f9e35c 00000000 NDIS!ndisMDpcX+0x2b
> > 804745a4 80465680 0000000e 00000000 00000000 nt!KiRetireDpcList+0x47
> > 804745ac 00000000 00000000 00000000 00000000 nt!KiIdleLoop+0x28
> >
> >
> > FOLLOWUP_IP:
> > tcpip!BufferData+42
> > f1e3ac85 8b5320 mov edx,[ebx+0x20]
> >
> > FOLLOWUP_NAME: MachineOwner
> >
> > SYMBOL_NAME: tcpip!BufferData+42
> >
> > MODULE_NAME: tcpip
> >
> > IMAGE_NAME: tcpip.sys
> >
> > DEBUG_FLR_IMAGE_TIMESTAMP: 3eaf053b
> >
> > STACK_COMMAND: kb
> >
> > BUCKET_ID: 0xD1_tcpip!BufferData+42
> >
> > Followup: MachineOwner
> > ---------
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@nai.com
> > 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: xxxxx@vormetric.com
> 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: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · July 29, 2003, 8:58pm

Thanks Max.

Yours is another way of implementing the functionality. Maybe, I
misunderstood the ddk doc which says STATUS_DATA_NOT_ACCEPTED means “the
client is not interested in the TDSU”.

If I have a thread coming in and posting a receive, supplying user buffer
at arbitrary points in time and to be able to timeout from the receive
if the data doesnt arrive in specified time, how do I actually implement
the receives without buffering the data in my driver?

Is it possible to give more details about your implementation? We can
take this offline if you wish.

-Shyam

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Tuesday, July 29, 2003 5:31 PM
To: Windows System Software Developers Interest List
Subject: [ntdev] RE: Problem Cancelling a TDI Receive

Why use TDI_RECEIVE at all?
In my kernel sockets implementation, TDI_RECEIVE is sent only after
STATUS_DATA_NOT_ACCEPTED is returned from ClientEventReceive, and the
cancellation is not necessary at all since there is some data for sure in
the
TDI endpoint.
All other receive is done using ClientEvent(Chained)Receive.

Max

----- Original Message -----
From: “Nagaraj Shyam”
To: “Windows System Software Developers Interest List”
Sent: Wednesday, July 30, 2003 3:36 AM
Subject: [ntdev] RE: Problem Cancelling a TDI Receive

> Thanks Srini,
>
> I did my due investigation into this problem for more than a day,
> before posting. I was also looking for info along the lines of
> if tdi supports cancels cleanly and if others on the group have
> done cancels of tdi irps, if they had problems with it. I already
> know that the tcp!BufferData routine is attempting to pass the data
> upstream, and the possibility that I just unmapped the buffer that
> it is trying to copy to (thereby null pointer derefernce). Further,
> I know the fact that I just unmapped the buffer on one proc while
> the bugcheck happens on other proc.
>
> I believe there was a bug in my first posting - pseudo code, I missed
> a line which I included below.
>
> > mdl = IoAllocateMdl
> > MmProbeAndLockPages
> > IoAllocateIrp
> > TdiBuildReceive
> > IoCallDriver
> > status = KeWaitForSingleObject
> > if (status == STATUS_TIMEOUT)
> > IoCancelIrp
> >>>>>>>>>>>> KeWaitForSingleObject // missed line in original posting.
> > MmUnlockPages (mdl)
> > IoFreeMdl
> > IoFreeIrp
>
>
> Thanks again.
>
> -Shyam
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of xxxxx@NAI.com
> Sent: Tuesday, July 29, 2003 4:18 PM
> To: Windows System Software Developers Interest List
> Subject: [ntdev] RE: Problem Cancelling a TDI Receive
>
>
> Shyam,
> The code is ending up accessing a null pointer. BufferData
> function is looking for something at offset 20 of NULL pointer. You need
> to disassemble the function and see what the function is trying to
> access. That would give you a tip.
>
> -Srin.
>
> > -----Original Message-----
> > From: Shyam [mailto:xxxxx@vormetric.com]
> > Sent: Tuesday, July 29, 2003 4:02 PM
> > To: Windows System Software Developers Interest List
> > Subject: [ntdev] Problem Cancelling a TDI Receive
> >
> > Hi,
> >
> > I am facing a problem while cancelling a receive irp issued to a
> > tdi tcp end point. I understand that this problem might be specific
> > to my driver, but I am hoping someone might have faced similar issue
> > and might be able to help.
> >
> > Normal i/o and a few (hundreds) cancels happen succesfully. However,
> > every once in a while the dual processor windows 2000 server SP4
> machine
> > bug checks with bug code 0xD1 with stack attached below. I unmap the
> > mdl buffers in my routine that issues the receive, after I ensure that
> > my completion routine is called (in this case for cancel of irp), ie.
> > irp->IoStatus.Status == STATUS_CANCELLED;
> >
> > Hope someone on the list has some suggestions for me to try/ or
> insights
> > into what I might be doing wrong else I might have to go to a
> different
> > design and implementation. Thanks in advance for any help.
> > -Shyam
> >
> > My pseudo code:
> > mdl = IoAllocateMdl
> > MmProbeAndLockPages
> > IoAllocateIrp
> > TdiBuildReceive
> > IoCallDriver
> > status = KeWaitForSingleObject
> > if (status == STATUS_TIMEOUT)
> > IoCancelIrp
> > MmUnlockPages (mdl)
> > IoFreeMdl
> > IoFreeIrp
> >
> > In my completion routine for the above irp, I always return
> > STATUS_MORE_PROCESSING_REQUIRED, to the irp stays valid in the
> > allocating routine.
> >
> > !analyze -v info is as follows:
> >
> > 0: kd> !analyze -v
> >
> *****
>
> >
> >
> >
> >
> >
> > * Bugcheck Analysis
> >
> >
> >
> >
>
>
> >
> >
> >
> >
> > DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
> > An attempt was made to access a pagable (or completely invalid)
> address at
> > an
> > interrupt request level (IRQL) that is too high. This is usually
> > caused by drivers using improper addresses.
> > If kernel debugger is available get stack backtrace.
> > Arguments:
> > Arg1: 00000020, memory referenced
> > Arg2: 00000002, IRQL
> > Arg3: 00000000, value 0 = read operation, 1 = write operation
> > Arg4: f1e3ac85, address which referenced memory
> >
> > Debugging Details:
> > ------------------
> >
> >
> > READ_ADDRESS: 00000020
> >
> > CURRENT_IRQL: 2
> >
> > FAULTING_IP:
> > tcpip!BufferData+42
> > f1e3ac85 8b5320 mov edx,[ebx+0x20]
> >
> > DEFAULT_BUCKET_ID: DRIVER_FAULT
> >
> > BUGCHECK_STR: 0xD1
> >
> > LAST_CONTROL_TRANSFER: from 8042aa0f to 804564d0
> >
> > STACK_TEXT:
> > 80473d68 8042aa0f 00000003 80473db0 00000020
> > nt!RtlpBreakWithStatusInstruction
> > 80473d98 8042b002 00000003 00000020 f1e3ac85
> nt!KiBugCheckDebugBreak+0x31
> > 80474124 8046987c 00000000 00000020 00000002 nt!KeBugCheckEx+0x390
> > 80474124 f1e3ac85 00000000 00000020 00000002 nt!KiTrap0E+0x284
> > 804741e0 f1e26466 8187c5c8 00001050 804742fc tcpip!BufferData+0x42
> > 80474248 f1e2415d 00000000 8504020a b304020a tcpip!TCPRcv+0xad1
> > 80474294 f1e2405d f1e261c7 8190a148 81e4300e tcpip!DeliverToUser+0xf9
> > 8047434c f1e2398c 8190a148 81e43022 000005c8 tcpip!IPRcvPacket+0x5f8
> > 8047438c f1e239ed 00000000 81ed3a7c 81e43000
> > tcpip!ARPRcvIndicationNew+0x172
> > 804743c8 f87c1183 81910d48 00000000 00000000 tcpip!ARPRcvPacket+0x5c
> > 80474420 f1f8d757 81fa8b00 80474440 00000008
> > NDIS!ethFilterDprIndicateReceivePacket+0x2ea
> > WARNING: Stack unwind information not available. Following frames may
> be
> > wrong.
> > 80474554 f1f8d4fb 81f9e008 80474580 81f9e35c e1000nt5+0x757
> > 80474578 f87aabb8 81f9e000 80470370 ffdff848 e1000nt5+0x4fb
> > 8047458c 80465728 81f9e370 81f9e35c 00000000 NDIS!ndisMDpcX+0x2b
> > 804745a4 80465680 0000000e 00000000 00000000 nt!KiRetireDpcList+0x47
> > 804745ac 00000000 00000000 00000000 00000000 nt!KiIdleLoop+0x28
> >
> >
> > FOLLOWUP_IP:
> > tcpip!BufferData+42
> > f1e3ac85 8b5320 mov edx,[ebx+0x20]
> >
> > FOLLOWUP_NAME: MachineOwner
> >
> > SYMBOL_NAME: tcpip!BufferData+42
> >
> > MODULE_NAME: tcpip
> >
> > IMAGE_NAME: tcpip.sys
> >
> > DEBUG_FLR_IMAGE_TIMESTAMP: 3eaf053b
> >
> > STACK_COMMAND: kb
> >
> > BUCKET_ID: 0xD1_tcpip!BufferData+42
> >
> > Followup: MachineOwner
> > ---------
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@nai.com
> > 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: xxxxx@vormetric.com
> 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: xxxxx@storagecraft.com
> 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: xxxxx@vormetric.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Srin_Kumar · July 30, 2003, 2:52am

Shyam,
I used TDI cancel logic for connect and accept irps. For receive
irps I didn’t. If I were you I would try a different path, try to close
the connection object/address object you fired the receive IRPs and this
could make the tcpip to complete your receive with zero bytes received.
Is there any special reason why you are canceling receive irps?

-Srin.

-----Original Message-----
From: Nagaraj Shyam [mailto:xxxxx@vormetric.com]
Sent: Tuesday, July 29, 2003 4:37 PM
To: Windows System Software Developers Interest List
Subject: [ntdev] RE: Problem Cancelling a TDI Receive

Thanks Srini,

I did my due investigation into this problem for more than a day,
before posting. I was also looking for info along the lines of
if tdi supports cancels cleanly and if others on the group have
done cancels of tdi irps, if they had problems with it. I already
know that the tcp!BufferData routine is attempting to pass the data
upstream, and the possibility that I just unmapped the buffer that
it is trying to copy to (thereby null pointer derefernce). Further,
I know the fact that I just unmapped the buffer on one proc while
the bugcheck happens on other proc.

I believe there was a bug in my first posting - pseudo code, I missed
a line which I included below.

> mdl = IoAllocateMdl
> MmProbeAndLockPages
> IoAllocateIrp
> TdiBuildReceive
> IoCallDriver
> status = KeWaitForSingleObject
> if (status == STATUS_TIMEOUT)
> IoCancelIrp
>>>>>>>>>>>> KeWaitForSingleObject // missed line in original
posting.
> MmUnlockPages (mdl)
> IoFreeMdl
> IoFreeIrp

Thanks again.

-Shyam

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@NAI.com
Sent: Tuesday, July 29, 2003 4:18 PM
To: Windows System Software Developers Interest List
Subject: [ntdev] RE: Problem Cancelling a TDI Receive

Shyam,
The code is ending up accessing a null pointer. BufferData
function is looking for something at offset 20 of NULL pointer. You
need
to disassemble the function and see what the function is trying to
access. That would give you a tip.

-Srin.

> -----Original Message-----
> From: Shyam [mailto:xxxxx@vormetric.com]
> Sent: Tuesday, July 29, 2003 4:02 PM
> To: Windows System Software Developers Interest List
> Subject: [ntdev] Problem Cancelling a TDI Receive
>
> Hi,
>
> I am facing a problem while cancelling a receive irp issued to a
> tdi tcp end point. I understand that this problem might be specific
> to my driver, but I am hoping someone might have faced similar issue
> and might be able to help.
>
> Normal i/o and a few (hundreds) cancels happen succesfully.
However,
> every once in a while the dual processor windows 2000 server SP4
machine
> bug checks with bug code 0xD1 with stack attached below. I unmap
the
> mdl buffers in my routine that issues the receive, after I ensure
that
> my completion routine is called (in this case for cancel of irp),
ie.
> irp->IoStatus.Status == STATUS_CANCELLED;
>
> Hope someone on the list has some suggestions for me to try/ or
insights
> into what I might be doing wrong else I might have to go to a
different
> design and implementation. Thanks in advance for any help.
> -Shyam
>
> My pseudo code:
> mdl = IoAllocateMdl
> MmProbeAndLockPages
> IoAllocateIrp
> TdiBuildReceive
> IoCallDriver
> status = KeWaitForSingleObject
> if (status == STATUS_TIMEOUT)
> IoCancelIrp
> MmUnlockPages (mdl)
> IoFreeMdl
> IoFreeIrp
>
> In my completion routine for the above irp, I always return
> STATUS_MORE_PROCESSING_REQUIRED, to the irp stays valid in the
> allocating routine.
>
> !analyze -v info is as follows:
>
> 0: kd> !analyze -v
>

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

**
> *****
>
>
> *
> *
> * Bugcheck Analysis
> *
> *
> *
>

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

**
> *****
>
>
>
> DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
> An attempt was made to access a pagable (or completely invalid)
address at
> an
> interrupt request level (IRQL) that is too high. This is usually
> caused by drivers using improper addresses.
> If kernel debugger is available get stack backtrace.
> Arguments:
> Arg1: 00000020, memory referenced
> Arg2: 00000002, IRQL
> Arg3: 00000000, value 0 = read operation, 1 = write operation
> Arg4: f1e3ac85, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: 00000020
>
> CURRENT_IRQL: 2
>
> FAULTING_IP:
> tcpip!BufferData+42
> f1e3ac85 8b5320 mov edx,[ebx+0x20]
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0xD1
>
> LAST_CONTROL_TRANSFER: from 8042aa0f to 804564d0
>
> STACK_TEXT:
> 80473d68 8042aa0f 00000003 80473db0 00000020
> nt!RtlpBreakWithStatusInstruction
> 80473d98 8042b002 00000003 00000020 f1e3ac85
nt!KiBugCheckDebugBreak+0x31
> 80474124 8046987c 00000000 00000020 00000002 nt!KeBugCheckEx+0x390
> 80474124 f1e3ac85 00000000 00000020 00000002 nt!KiTrap0E+0x284
> 804741e0 f1e26466 8187c5c8 00001050 804742fc tcpip!BufferData+0x42
> 80474248 f1e2415d 00000000 8504020a b304020a tcpip!TCPRcv+0xad1
> 80474294 f1e2405d f1e261c7 8190a148 81e4300e
tcpip!DeliverToUser+0xf9
> 8047434c f1e2398c 8190a148 81e43022 000005c8 tcpip!IPRcvPacket+0x5f8
> 8047438c f1e239ed 00000000 81ed3a7c 81e43000
> tcpip!ARPRcvIndicationNew+0x172
> 804743c8 f87c1183 81910d48 00000000 00000000 tcpip!ARPRcvPacket+0x5c
> 80474420 f1f8d757 81fa8b00 80474440 00000008
> NDIS!ethFilterDprIndicateReceivePacket+0x2ea
> WARNING: Stack unwind information not available. Following frames
may
be
> wrong.
> 80474554 f1f8d4fb 81f9e008 80474580 81f9e35c e1000nt5+0x757
> 80474578 f87aabb8 81f9e000 80470370 ffdff848 e1000nt5+0x4fb
> 8047458c 80465728 81f9e370 81f9e35c 00000000 NDIS!ndisMDpcX+0x2b
> 804745a4 80465680 0000000e 00000000 00000000 nt!KiRetireDpcList+0x47
> 804745ac 00000000 00000000 00000000 00000000 nt!KiIdleLoop+0x28
>
>
> FOLLOWUP_IP:
> tcpip!BufferData+42
> f1e3ac85 8b5320 mov edx,[ebx+0x20]
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: tcpip!BufferData+42
>
> MODULE_NAME: tcpip
>
> IMAGE_NAME: tcpip.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 3eaf053b
>
> STACK_COMMAND: kb
>
> BUCKET_ID: 0xD1_tcpip!BufferData+42
>
> Followup: MachineOwner
> ---------
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@nai.com
> 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: xxxxx@vormetric.com
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: xxxxx@nai.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Maxim_S_Shatskih · July 30, 2003, 9:19am

> Yours is another way of implementing the functionality. Maybe, I

misunderstood the ddk doc which says STATUS_DATA_NOT_ACCEPTED means “the
client is not interested in the TDSU”.

This is to apply backpressure on SO_RCVBUF overflow.

the receives without buffering the data in my driver?

It is better to buffer the data in your driver AFD does this - the
SO_RCVBUF option is for this.

Max

OSR_Community_User · July 30, 2003, 11:22am

Thanks Max,

That was useful. I am still trying to do my implementation
without internal buffering in my driver.

-Shyam

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Wednesday, July 30, 2003 5:41 AM
To: Windows System Software Developers Interest List
Subject: [ntdev] RE: Problem Cancelling a TDI Receive

Yours is another way of implementing the functionality. Maybe, I
misunderstood the ddk doc which says STATUS_DATA_NOT_ACCEPTED means “the
client is not interested in the TDSU”.

This is to apply backpressure on SO_RCVBUF overflow.

the receives without buffering the data in my driver?

It is better to buffer the data in your driver AFD does this - the
SO_RCVBUF option is for this.

Max

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@vormetric.com
To unsubscribe send a blank email to xxxxx@lists.osr.com