I have faced the same problem here and somehow I didn’t trust NDIS ( is it a
common feeling ?? )
Anyway the problem was solved eventually, but not before losing half my
sanity.
The deserial NT driver is not documented, but Microsoft says that it is
identical to the NDIS 5 deserial driver, here are the discrepencies…
* The miniport Return packet is never called, it treats the Rx Packets in
a Serial driver manner, that is yhou have to check the status upton return
from IndicateReceivePacket and free it up immediately if we have a SUCCESS.
* Regarding Shahsi’s problem, ( after having seen your code… how
??? … I’m his partner 
) the problem lies in the fact that it does
not behave like it’s supposed to, that is for a deserial driver NDIS gives
us MiniportReservedEx area which contains 3 PVOIDS, but it doesn’t ( the
creep !!! ) it only gives us 2, which was the cause of the panic, since we
were using all 3 and it was causing corruption.
Well, when the code was modified to use only 2 of the PVOID’s the panic went
away, the real fact being that it didn’t actually give the
MiniportReservedEx area in the first place.!!! It gave is the
MiniportReservedArea for a serial driver , but the code still worked with
the MiniportReservedEx area after the modification since we were usign only
2 PVOID’s and the structure is a UNION and hence whether we use the
MiniportReservedArea or 2 PVOID’s of the MiniportReservedEx area it mount’s
to same thing.
So NDIS was acting like a stingy hog and holding back more than it was
required to!!
So much for NDIS 4 and deserial drivers.
Ramit.
----- Original Message -----
From: “Vodicka, Michal”
To: “NT Developers Interest List”
Sent: Thursday, April 19, 2001 12:17 AM
Subject: [ntdev] RE: NdisMSendComplete crashes
> This problem usualy occurs when an invalid packet pointer is given to
> NdisMSendComplete(). Packet can be invalid for various reason. Original
> owner could free it already if you set status incorrectly when returning
> from MiniportSend() or MiniportSendPackets(), your queue code can be
broken
> etc. It is always a bug in miniport code. At first, check if a packet you
> complete is really the NDIS packet.
>
> Best regards,
>
> Michal Vodicka
> Veridicom
> (RKK - Skytale)
> [WWW: http://www.veridicom.com , http://www.skytale.com]
>
>
>
> > ----------
> > From: shashidhar ramareddy[SMTP:xxxxx@wipro.com]
> > Reply To: NT Developers Interest List
> > Sent: Wednesday, April 18, 2001 3:58 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] NdisMSendComplete crashes
> >
> > Hi,
> > We have a NDIS4 deserial, miniport driver which works fine as long as
> > resources are available in the driver. This means there is no queueing
> > done
> > in this case.
> >
> > When we don’t have resources, the packet is queued internally. At a
later
> > point of time, when resources become available, the packet is
> > transmitted.
> > While handling the Tx Complete interrrupt for this packet, we get a blue
> > screen when NdisMSendComplete() is called.
> >
> > Anybody has seen this condition ?? Or any ideas what we can check in the
> > NDIS_PACKET before calling NdisMSendComplete ?
> >
> > Interestingly, the same code works in NDIS5(Win 2000).
> >
> > Any help will be appreciated.
> >
> > Thanks.
> >
> >
> >
> > —
> > 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: xxxxx@wipro.com
> 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