calling NdisSend() from within ProtocolReceive()

Discussion in 'Windows Vista Drivers' started by Vitalie Vrabie, Jun 8, 2007.

  1. hi.

    in my driver, i have to solve the same problem as in
    http://groups.google.com/groups?as_umsgid=
    (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?
     
    Vitalie Vrabie, Jun 8, 2007
    #1
    1. Advertisements

  2. Vitalie Vrabie

    Anton Bassov Guest

    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
     
    Anton Bassov, Jun 8, 2007
    #2
    1. Advertisements

  3. oops. my fault. of course, i should have said ProtocolSendComplete().
    yes, the check is there.
     
    Vitalie Vrabie, Jun 8, 2007
    #3
  4. it seems that the culprit of this strange begavior was invoking
    NdisIMCopySendCompletePerPacketInfo() with a null pointer as
    destination. :)

    thanks anyway.
     
    Vitalie Vrabie, Jun 8, 2007
    #4
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.