Hi,
I’m just wondering if anybody has seen this ASSERT in tcpip.sys and could
shed some light on what can possibly be wrong.
I have TDI clients on two XP Pro systems on local network. One is
transmitting unicast datagrams to remote system where the second TDI client
receives it. Everything appears to be fine, however on checked build of XP
I keep on getting complains from TCPIP for each IRP submitted to TDI.
Details are at the end of this message.
Thanks!
— Max.
*** Assertion failed: item != Irp
*** Source File: d:\xpclient\net\tcpip\driver\tcp\ntdisp.c, line 1038
Break repeatedly, break Once, Ignore, terminate Process, or terminate
Thread (boipt)?
Execute ‘.cxr F47BB710’ to dump context
Break instruction exception - code 80000003 (first chance)
ntoskrnl!DbgBreakPoint:
80581b48 cc int 3
kd> .cxr F47BB710
eax=f47bb710 ebx=a76dcfc8 ecx=a76dcfd4 edx=a7896f68 esi=a7896f68
edi=a76dcfc8
eip=805836b8 esp=f47bb9e8 ebp=f47bb9fc iopl=0 nv up ei ng nz na pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00000282
ntoskrnl!RtlAssert+16:
805836b8 5d pop ebp
kd> kv
*** Stack trace for last set context - .thread resets it
ChildEBP RetAddr Args to Child
f47bb9fc f5a04727 f5a045f8 f5a045cc 0000040e ntoskrnl!RtlAssert+0x16 (FPO:
[Non-Fpo])
f47bba20 f5a07618 006dcfc8 a7896fc0 a76dcfd4
tcpip!TCPPrepareIrpForCancel+0xbe (FPO: [Non-Fpo])
f47bba54 f5a089dc a7896f68 a7896fd8 ffbb0f18 tcpip!UDPSendDatagram+0x93
(FPO: [Non-Fpo])
f47bba70 804f61de ffbb0f18 a7896f68 ffbb0f18
tcpip!TCPDispatchInternalDeviceControl+0x100 (FPO: [Non-Fpo])
f47bba88 80784110 a7896f68 a55f8e78 a7896fc0 ntoskrnl!IopfCallDriver+0x4f
(FPO: [0,0,3])
f47bbaac faf0dde7 a786cfd0 00000000 c00000a3 ntoskrnl!IovCallDriver+0x9e
(FPO: [Non-Fpo])
f47bbadc faf0de8f a8e86fd0 a55f8e78 faf0d796
DkTdiSnd!CKsBaseTdiPin__Process+0xeb (FPO: [Non-Fpo])
f47bbae8 faf0d796 a8e86fd0 a55e6fe4 a55e6d44
DkTdiSnd!CKsBaseTdiInputPin__Process+0x1d (FPO: [1,0,1])
f47bbb04 fa93d11e 00000001 a7868e8c a55e6d44 DkTdiSnd!DkPinProcess+0x6e
(FPO: [Non-Fpo])
f47bbb24 fa93ccad 005e6d44 a7868dc8 f47bbb54
ks!CKsPin__ProcessingObjectWork+0x11f (FPO: [Non-Fpo])
f47bbb34 fa940808 a55e6d44 00000000 a7868dc8 ks!CKsPin__Process+0x65 (FPO:
[Non-Fpo])
f47bbb54 fa9456f3 00000000 a8e82f00 a55e6d40 ks!CKsQueue__AddFrame+0x191
(FPO: [Non-Fpo])
f47bbb84 fa9752b5 00000000 a7bf4fb0 f47bbbb4
ks!CKsQueue__TransferKsIrp+0x3c5 (FPO: [Non-Fpo])
f47bbba8 fa9573f0 a8e82fb8 a8e82f00 f47bbbf4
ks!CKsPin__DispatchDeviceIoControl+0x279 (FPO: [Non-Fpo])
f47bbbb8 804f61de 8126b440 a8e82f00 8126b440
ks!DispatchDeviceIoControl+0x26 (FPO: [Non-Fpo])
f47bbbd0 80784110 a8e82fd4 a8e82ff8 8126e618 ntoskrnl!IopfCallDriver+0x4f
(FPO: [0,0,3])
f47bbbf4 8079311c 8126e560 a8e82f00 00000000 ntoskrnl!IovCallDriver+0x9e
(FPO: [Non-Fpo])
f47bbc08 804f61de 8126e560 a8e82f00 8126e560
ntoskrnl!ViDriverDispatchGeneric+0x28 (FPO: [Non-Fpo])
f47bbc20 80784110 a8e78f10 80003400 a8e82f00 ntoskrnl!IopfCallDriver+0x4f
(FPO: [0,0,3])
f47bbc44 805ec37e ffbc17d8 a8e82fdc a8e82f00 ntoskrnl!IovCallDriver+0x9e
(FPO: [Non-Fpo])
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
> I have TDI clients on two XP Pro systems on local network. One is
transmitting unicast datagrams to remote system where the second TDI client
receives it. Everything appears to be fine, however on checked build of XP
Is the TDI file object OK?
If yes - just step to disassembly to see what causes the ASSERT.
Max
TDI object is fine.
As it turned out ASSERT was fired by TCPIP when it tried to make sure that
newly received send datagram or receive datagram IRP was not already in
its list of pendig IRPs. Meaning that it complained as though my TDI client
was submitting the same IRP again before TCPIP was through with it. This
was definitely not the case!
To me it looked like bogus ASSERT in TCPIP. The only thing that is stopping
me from saying it out loud is the fact that nobody else has ever complained
about it. I’ve spoken to MS folks about it and they promised to investigate
this case. I’m still waiting.
– Max.
— “Maxim S. Shatskih” wrote:
> > I have TDI clients on two XP Pro systems on local network. One is
> > transmitting unicast datagrams to remote system where the second TDI
> client
> > receives it. Everything appears to be fine, however on checked build of
> XP
>
> Is the TDI file object OK?
> If yes - just step to disassembly to see what causes the ASSERT.
>
> Max
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@yahoo.com
> To unsubscribe send a blank email to %%email.unsub%%
__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world’s greatest free email!
http://mail.yahoo.com/
Hello Max,
TCPPrepareIrpForCancel (called from UDPSendDatagram in this case), goes
through the pending and cancelled IRP list-entry queue in the TCP
Context structure looking for the IRP it’s preparing for possible
cancellation. If it encounters the same IRP address, that would be
considered a resubmit of an uncompleted IRP and it asserts. If not, it
inserts this IRP into the pending IRP queue. It only removes the IRP
from the pending/cancel queues in its completion routine. It can also
remove the IRP from the pending queue in the cancellation routine (which
causes the IRP to be placed on the cancel queue only to be later removed
when the completion routine runs).
I believe that this is a valid ASSERT and you should not dismiss it.
Regards,
Youssef
-----Original Message-----
From: Max Paklin [mailto:xxxxx@yahoo.com]
Sent: Wednesday, March 06, 2002 5:15 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Weird ASSERT in tcpip.sys
TDI object is fine.
As it turned out ASSERT was fired by TCPIP when it tried to make sure
that
newly received send datagram or receive datagram IRP was not already
in
its list of pendig IRPs. Meaning that it complained as though my TDI
client
was submitting the same IRP again before TCPIP was through with it. This
was definitely not the case!
To me it looked like bogus ASSERT in TCPIP. The only thing that is
stopping
me from saying it out loud is the fact that nobody else has ever
complained
about it. I’ve spoken to MS folks about it and they promised to
investigate
this case. I’m still waiting.
– Max.
— “Maxim S. Shatskih” wrote:
> > I have TDI clients on two XP Pro systems on local network. One is
> > transmitting unicast datagrams to remote system where the second TDI
> client
> > receives it. Everything appears to be fine, however on checked build
of
> XP
>
> Is the TDI file object OK?
> If yes - just step to disassembly to see what causes the ASSERT.
>
> Max
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@yahoo.com
> To unsubscribe send a blank email to %%email.unsub%%
__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world’s greatest free email!
http://mail.yahoo.com/
—
You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to %%email.unsub%%