- calling NdisSend() from within ProtocolReceive()
- Posted by Vitalie Vrabie on June 8th, 2007
hi.
in my driver, i have to solve the same problem as in
http://groups.google.com/groups?as_u...@microsoft.com
(send data back to the underlying miniport).
i did all the checking precautions, including copying of all data to
my own newly-created packet, and dropping of duplicate packets (i
never send back any packet i already seen before). and, of course, i'm
NOT calling NdisReturnPackets() in MiniportReturnPacket() for packets
i've generated in this part.
i get IRQL_NOT_LESS_OR_EQUAL when i'm trying to call NdisSend() from
within ProtocolReceive().
according to the documentation, ProtocolReceive() and
ProtocolReceivePacket() run at IRQL==DISPATCH_LEVEL, and NdisSend()
may be invoked at IRQL<=DISPATCH_LEVEL. although it seems perfectly
okay, i get that IRQL_NOT_LESS_OR_EQUAL nonetheless.
if i don't invoke NdisSend() (i.e, replace its invocation with a dummy
Status=NDIS_STATUS_SUCCESS), it doesn't generate any trouble.
can someone bring any insight on this, please?
- Posted by Anton Bassov on June 8th, 2007
What about your PtSendComplete()???? Does it make a distinction between the
packets that your driver sends on its own initiative and the ones that it
passes down from the bound protocols???? There is a very good chance that it
does not,
and calls NdisMSendComplete() whenever it gets invoked. My suspicion is based
upon the statement below
How on Earth MiniportReturnPacket() (i.e. the function that deals with the
packets that you indicate up the stack) can possibly be related to the
packets that you *SEND*???? I believe you expect these packets to be returned
to MiniportReturnPacket(), rather than to PtSendComplete(). As a result,
PtSendComplete() calls NdisMSendComplete() on the packets that you have
allocated yourself, so that indication goes up the stack. BANG!!!!
Anton Bassov
"Vitalie Vrabie" wrote:
- Posted by Vitalie Vrabie on June 8th, 2007
On Jun 8, 11:25 am, Anton Bassov
<AntonBas...@discussions.microsoft.com> wrote:
oops. my fault. of course, i should have said ProtocolSendComplete().
yes, the check is there.
- Posted by Vitalie Vrabie on June 8th, 2007
it seems that the culprit of this strange begavior was invoking
NdisIMCopySendCompletePerPacketInfo() with a null pointer as
destination. 
thanks anyway.