This documentation is archived and is not being maintained.

NdisMArcIndicateReceive function

Note   NDIS 5. x has been deprecated and is superseded by NDIS 6. x. For new NDIS driver development, see Network Drivers Starting with Windows Vista. For information about porting NDIS 5. x drivers to NDIS 6. x, see Porting NDIS 5.x Drivers to NDIS 6.0.

NdisMArcIndicateReceive notifies NDIS that an ARCNET packet (or some initial lookahead portion of the packet) has arrived so NDIS can forward the received packet to bound protocols.


VOID NdisMArcIndicateReceive(
  _In_ NDIS_HANDLE MiniportAdapterHandle,
  _In_ PUCHAR      HeaderBuffer,
  _In_ PUCHAR      DataBuffer,
  _In_ UINT        Length


MiniportAdapterHandle [in]

Specifies the handle originally input to MiniportInitialize.

HeaderBuffer [in]

Specifies the base virtual address of the packet header. The header buffer includes all bytes preceding the protocol ID.

DataBuffer [in]

Specifies the virtual base virtual address of a buffer containing Length bytes of received packet data.

Length [in]

Specifies the number of bytes in the buffer at DataBuffer.

Return value



A serialized miniport driver calls NdisMArcIndicateReceive if it designates its NIC as of type NdisMediumArcnet878_3 or NdisMediumArcnetRaw in response to the OID_GEN_MEDIA_IN_USE query, unless the driver supports multipacket receives. Any miniport driver that supports multipacket receives calls NdisMIndicateReceivePacket with a packet array, rather than calling any of the medium-type-specific NdisM..IndicateReceive functions.

When a miniport driver calls NdisMArcIndicateReceive, NDIS passes a pointer to the header of the packet and a pointer to some or all of the data in the packet to the ProtocolReceive function(s) of bound protocol driver(s). Each protocol that receives such an indication can do the following:

  1. Inspect the header and data in the packet to decide whether the indication is of interest to the protocol's client(s).

  2. If it is, copy as much of the header or data as is visible into protocol-allocated memory, using NdisMoveMemory.

  3. Get the remaining data, if any, for the indication by allocating a packet descriptor with sufficient chained buffer descriptors and calling NdisTransferData. The call to NdisTransferData causes the NIC driver's MiniportTransferData function to copy the data into the protocol-supplied packet.

For any protocol driver that receives an indication through NdisMArcIndicateReceive, the HeaderBuffer and DataBuffer addresses are valid only during the current call to its ProtocolReceive function, and these buffers are read-only. A protocol driver cannot retain a pointer to the indicated packet with these associated buffers nor can it retain any pointers to these buffers for later use. Any data that a protocol driver needs from such a packet must be copied and saved during the receive indication.

The data in the header is the same as that received on the NIC. A miniport driver need not remove any headers or trailers from the data its NIC receives.

The transmitting driver adds padding to any packet that is too short for the requirements of the medium. The receiving miniport driver can include such padding in the data and length it subsequently indicates. Each bound protocol is responsible for detecting any such padding and ignoring it.

Note that only serialized miniport drivers should call NdisMArcIndicateReceive.


Target platform



Not supported in Windows Vista.


Ndis.h (include Ndis.h)



See also




Send comments about this topic to Microsoft