Re: Random BugCheck in NdisAllocateMemoryWithTag , Need Help in NDIS driver

You could be caught in an infinite loop. ESPECIALLY in you see the problem when Ethereal (or any other packet sniffer) is running.

Sniffers place the lower-level miniport into promiscuous mode. In this mode all packets that are sent will be looped back by the NDIS wrapper and will show up in you ProtocolReceive/ProtocolReceivePacket handlers. See the "NDIS Loopback Discussion" at NDIS.com for more information on this behavior:

  http://www.ndis.com/papers/loopback.htm

You must add logic in your receive handlers to detect when you are receiving a packet that you have sent yourself. When you detect this you need to propogate the receive indication upwards (else the sniffer won't see it..) BUT you don't want to re-send this loopback packet (else you will be infinitely sending-receiving-sending the same packet).

Good luck,

Thomas F. Divine, Windows DDK MVP
http://www.pcausa.com

"Rajesh Gupta" <guptarajesh@xxxxxxxxx> wrote in message news:O4hrJGSmFHA.3464@xxxxxxxxxxxxxxxxxxxxxxx 
Thanks a lot for your reply. I really appreciate it.

There is no Loop in my PtReceive function. But i am not sure who is calling the functions
NDIS!ndisMLoopbackPacketX and why its being called. When i received the packet, i tried to send it using NdisSend, i am not sure why ndisMLoopbackPacketX is being called. Here is the fragment of my code.
NdisSend(&Status,pBridgeAdapt->BindingHandle,MyPacket);

if (Status != NDIS_STATUS_PENDING){

////Here we have to free all the buffer and memory..// Packet this is my packet i have to work on Packet

FltCleanPacket(MyPacket);

NdisDprFreePacket(MyPacket);

}

//

// We will have to block the original packet here

//

Status = NDIS_STATUS_SUCCESS;

return Status;

As i undestand from the stack trace, I received the pacekts in PtReceive. and i send it using NdisSend. But i do not understand the significance of these functions. Why these are being called.

f78ac854 bad6c400 899db138 f78ac874 00000001 NDIS!ethFilterDprIndicateReceivePacket+0x4a4
f78ac87c bad36f0a 899db138 0002f9e8 c000009a NDIS!ndisMLoopbackPacketX+0x1d0
f78ac898 bad71a29 8902f980 8902f9e8 f78ac8e4 NDIS!ndisMSendX+0x174

This issue came up, when i ran etherreal. Is ethereal doing something. Everything was working normally before that.

What is triple fault and how can i trace it? Sorry these are newbie questions.



"Calvin Guan" <hguan@xxxxxxxxxxxxxxxxxxx> wrote in message news:O2o%23L5RmFHA.3120@xxxxxxxxxxxxxxxxxxxxxxx
From your attached bugcheck dump, obviously, your code did bad recursion and exhausted the stack.

So my code works fine most of time, but sometimes system just reboots without any blue screen and it does not generate crash DUMP either. 

Sounds like a triple fault to me.

--
Calvin Guan (Windows DDK MVP)
Staff SW Engineer  NetXtreme Longhorn MINIPORT
Broadcom Corp. Irvine, CA
www.broadcom.com




.

Relevant Pages

  • Re: [SLE] Looking for info on setting up a packet sniffer
    ... >> Firebox sitting on RoadRunner's residential cable network. ... >> also open to suggestions on what other packet sniffing utilities might ... The Watchguard support guys asked me to put the sniffer ...
    (SuSE)
  • Re: Stable SNIFFER For The h6315?
    ... > PC based sniffer. ... > Clinton Fitch ... a good starting point is vxSniffer as it is ... >> packet sniffing. ...
    (microsoft.public.pocketpc.wireless)
  • Re: Stable SNIFFER For The h6315?
    ... > PC based sniffer. ... > Clinton Fitch ... a good starting point is vxSniffer as it is ... >> packet sniffing. ...
    (microsoft.public.pocketpc)
  • Re: Stable SNIFFER For The h6315?
    ... > PC based sniffer. ... > Clinton Fitch ... a good starting point is vxSniffer as it is ... >> packet sniffing. ...
    (microsoft.public.pocketpc.phone_edition)
  • TCP packets always two times
    ... I've written a packet sniffer (source code further down), ... int main{ ...
    (comp.os.linux.networking)