Re : Re: NDIS IM Driver on NT

NTDEV
1

Hi Everyone,
Ya I’m using IMSamp deserialize driver only and I tried to run this for SP4 to SP6. The messages are keep appearing on each setup. I’m again sending you a snap of kernel stack and the debug messages from IMSamp. I want a guide to where to concentrate to get the root of this?
Here in the following Debug message I observed a major threat from Packet-Id. In the following Imsamp dump somewhere it is “8083AE78” while in Indication and return it shows “8083AE00”. Any idea or explaination?
------------------ IMSAMP Dump -----------------------
Imsamp: (80849DA8) MPSendPackets: 1 XPORT packets
Imsamp: MPSendPackets: (80849DA8) Adapter: Packets to send = 1
Imsamp: (80849DA8) MPSendPackets: 1 IM packets @ 8083AE78,
Imsamp: ClReceiveIndication (80849DA8) +Adapter:h 2
Imsamp: (80849DA8) CLReceiveIndication: Packet 8083AE00 Packetsize 96
Imsamp: CLReceivePacket: Before NdisMIndicateReceivePacket
Imsamp: CLReceivePacket: After NdisMIndicateReceivePacket
Imsamp: (80849DA8) MPReturnPacket: IM Packet 8083AE00
Imsamp: (80849DA8) -Adapter:a 1
Imsamp: (80849DA8) CLReceiveComplete:
Imsamp: (80849DA8) PacketCompletion: IM Packet 8083AE78, Status: 00000000
---------------------- Kernel Stack Dump -------------------
kd> kp
ChildEBP RetAddr
80184200 80169d42 ntoskrnl!DbgBreakPoint
801842dc fcd0b66f ntoskrnl!RtlAssert+0x96
8018433c fccfe572 NDIS!ethFilterDprIndicateReceivePacket+0x3c
80184364 fccdac9d NDIS!ndisMLoopbackPacketX+0xdd
80184378 fcbf5d41 NDIS!ndisMSendX+0x6a
801843a4 fcbe4677 tcpip!ARPSendBCast+0x269
801843d4 fcbe9339 tcpip!ARPTransmit+0xcd
80184454 fcbf6a96 tcpip!IPTransmit+0x1ef
801844a4 fcbf6430 tcpip!UDPSend+0x246
801844c4 fcbf5fc0 tcpip!TdiSendDatagram+0x112
80184500 fcbe4033 tcpip!UDPSendDatagram+0xa7
80184518 8011c9a9 tcpip!TCPDispatchInternalDeviceControl+0x173
8018453c fcb97582 ntoskrnl!IofCallDriver+0x68
8018455c fcb96995 netbt!TdiSendDatagram+0x1fd
8018459c fcbc3c39 netbt!UdpSendDatagram+0xd3
801845e8 fcba02ca netbt!UdpSendNSBcast+0x34a
80184638 fcb99c1f netbt!MSnodeRegCompletion+0x2b9
8018465c 8012c4ae netbt!TimerExpiry+0xb4
8018475c 8012c3bb ntoskrnl!KiTimerListExpire+0xea
80184788 801784e8 ntoskrnl!KiTimerExpiration+0xdf

Thanks to read and write.
Regards,
– Sumit
----- Original Message -----
From: Michal Vodicka
Subject: [ntdev] Re: NDIS IM Driver on NT

>> ----------
>> From: xxxxx@hotmail.com>
>> NT4 supports deserialized drivers since SP3. Maybe it isn’t documented and “supported”

> Clarification: after NT4 SP3 release Microsoft made available the first NDIS IM driver sample named ImSamp. IIRC it was in July 1997.Best regards,

> Michal Vodicka

____________________________________________________________
eLitecore Technologies Pvt. Ltd.

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

2

Sumit,

if it is the problem you send here periodically for months, the root of the
problem is ASSERT message. You must not ignore it. Instead, find what causes
it and and solve problem.

*** Assertion failed: MINIPORT_LOCK_ACQUIRED(Miniport)
*** Source File: w:\nt\private\ntos\ndis\ndis40\mp..\efilter.c, line 2113

It means NDIS expects miniport lock should be acquired and it isn’t.
Miniport lock is acquired (internally by NDIS) when you make an indication
(packet, status…) to above layer from serialized driver. Deserialized
drivers don’t use it. So if you make an indication from deserialized driver
and this ASSERT is called, it means serialized handler is used. NDIS is
probably confused about your driver and mixes deserialized and serialized
handlers. I saw it in the past but already forgot what exactly caused it. It
may be some a flag you set, bad report to query or even if you set some
handler which isn’t expected for deserialized drivers. I believe ImSamp
normally works so compare your code with original and examined changes.

I would put a breakpoint at NDIS!ndisMLoopbackPacketX and examine why
ethFilterDprIndicateReceivePacket is called and why miniport lock isn’t
acquired in this case. The first function seems make some decision and it
can be important to examine it. You’ll probably need to understand internal
NDIS structures; use ndiskd KD extension and also examine ndis.h file.
_NDIS_MINIPORT_BLOCK should be interesting for you.

BTW, what attributes you set using NdisMSetAttributesEx()? There should be
NDIS_ATTRIBUTE_DESERIALIZE alone, if you have full duplex there, it may
cause the problem.

Best regards,

Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.com]

From: Sumit Pandya[SMTP:xxxxx@elitecore.com]
Reply To: NT Developers Interest List
Sent: Thursday, September 27, 2001 9:07 AM
To: NT Developers Interest List
Subject: [ntdev] Re : Re: NDIS IM Driver on NT

Hi Everyone,
Ya I’m using IMSamp deserialize driver only and I tried to run this
for SP4 to SP6. The messages are keep appearing on each setup. I’m again
sending you a snap of kernel stack and the debug messages from IMSamp. I
want a guide to where to concentrate to get the root of this?
Here in the following Debug message I observed a major threat from
Packet-Id. In the following Imsamp dump somewhere it is “8083AE78” while
in Indication and return it shows “8083AE00”. Any idea or explaination?
------------------ IMSAMP Dump -----------------------
Imsamp: (80849DA8) MPSendPackets: 1 XPORT packets
Imsamp: MPSendPackets: (80849DA8) Adapter: Packets to send = 1
Imsamp: (80849DA8) MPSendPackets: 1 IM packets @ 8083AE78,
Imsamp: ClReceiveIndication (80849DA8) +Adapter:h 2
Imsamp: (80849DA8) CLReceiveIndication: Packet 8083AE00 Packetsize 96
Imsamp: CLReceivePacket: Before NdisMIndicateReceivePacket
Imsamp: CLReceivePacket: After NdisMIndicateReceivePacket
Imsamp: (80849DA8) MPReturnPacket: IM Packet 8083AE00
Imsamp: (80849DA8) -Adapter:a 1
Imsamp: (80849DA8) CLReceiveComplete:
Imsamp: (80849DA8) PacketCompletion: IM Packet 8083AE78, Status: 00000000
---------------------- Kernel Stack Dump -------------------
kd> kp
ChildEBP RetAddr
80184200 80169d42 ntoskrnl!DbgBreakPoint
801842dc fcd0b66f ntoskrnl!RtlAssert+0x96
8018433c fccfe572 NDIS!ethFilterDprIndicateReceivePacket+0x3c
80184364 fccdac9d NDIS!ndisMLoopbackPacketX+0xdd
80184378 fcbf5d41 NDIS!ndisMSendX+0x6a
801843a4 fcbe4677 tcpip!ARPSendBCast+0x269
801843d4 fcbe9339 tcpip!ARPTransmit+0xcd
80184454 fcbf6a96 tcpip!IPTransmit+0x1ef
801844a4 fcbf6430 tcpip!UDPSend+0x246
801844c4 fcbf5fc0 tcpip!TdiSendDatagram+0x112
80184500 fcbe4033 tcpip!UDPSendDatagram+0xa7
80184518 8011c9a9 tcpip!TCPDispatchInternalDeviceControl+0x173
8018453c fcb97582 ntoskrnl!IofCallDriver+0x68
8018455c fcb96995 netbt!TdiSendDatagram+0x1fd
8018459c fcbc3c39 netbt!UdpSendDatagram+0xd3
801845e8 fcba02ca netbt!UdpSendNSBcast+0x34a
80184638 fcb99c1f netbt!MSnodeRegCompletion+0x2b9
8018465c 8012c4ae netbt!TimerExpiry+0xb4
8018475c 8012c3bb ntoskrnl!KiTimerListExpire+0xea
80184788 801784e8 ntoskrnl!KiTimerExpiration+0xdf

Thanks to read and write.
Regards,
– Sumit
----- Original Message -----
From: Michal Vodicka
> Subject: [ntdev] Re: NDIS IM Driver on NT
>
> >> ----------
> >> From: xxxxx@hotmail.com>
> >> NT4 supports deserialized drivers since SP3. Maybe it isn’t documented
> and “supported”
>
> > Clarification: after NT4 SP3 release Microsoft made available the first
> NDIS IM driver sample named ImSamp. IIRC it was in July 1997.Best regards,
>
> > Michal Vodicka
>
>
>
> ____________________________________________________________
> eLitecore Technologies Pvt. Ltd.
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@rkk.cz
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

3

OK. I stand corrected. All it says to me is that Microsoft needs to do a
better job of documenting what is and isn’t supported!

Scott

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

4

> ----------

From: xxxxx@hotmail.com[SMTP:xxxxx@hotmail.com]
Reply To: NT Developers Interest List
Sent: Friday, September 28, 2001 2:26 PM
To: NT Developers Interest List
Subject: [ntdev] Re: NDIS IM Driver on NT

OK. I stand corrected. All it says to me is that Microsoft needs to do a

better job of documenting what is and isn’t supported!

I would say that Microsoft needs to do a better job of documenting at all.
Every exported function should be documented. Even better, kernel sources
should be available (as read-only). Also, I’d like to know what the word
“supported” really means in this context :wink:

Best regards,

Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.com]

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

5

> Every exported function should be documented. Even better, kernel sources

should be available (as read-only).

Yes, for instance, in the form of CL’s listings.
What does MS afraid of? Of somebody creating an NT clone from these sources?
This can be easily banned legally.

Max

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com