Registering an Intermediate Driver as a Miniport (NDIS 5.1)

  • Article

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.

An intermediate driver calls NdisIMRegisterLayeredMiniportto export its MiniportXxx functions. The DriverHandlethat is returned by NdisIMRegisterLayeredMiniportmust be retained by the intermediate driver and input to NDIS when the driver calls NdisIMInitializeDeviceInstanceEx. The NdisWrapperHandle, returned by a previous call to NdisMInitializeWrapper, must be passed to NdisIMRegisterLayeredMiniport.

The intermediate driver must:

  1. Zero-initialize a structure of type NDIS_MINIPORT_CHARACTERISTICS with NdisZeroMemory.

  2. Store the addresses of the mandatory MiniportXxx functions, as well as any optional MiniportXxx functions the driver exports. Any other MiniportXxx entry points must be set to NULL.

An intermediate driver that supports NDIS 5.1 features should register as a version 5.1 miniport. An intermediate driver that does not support NDIS 5.1 features should register as either a version 4.0 or version 5.0 miniport driver. For more information about specifying miniport driver version numbers, see Specifying the NDIS Version Number.

You must set the following entries in MiniportCharacteristics to a valid MiniportXxxfunction address unless the function is optional and is not exported. If the driver does not export the function, set the address to NULL.

  • HaltHandler
    MiniportHalt is a required function. NDIS calls MiniportHalt if the virtual miniport device that the intermediate driver exposed is disabled or stopped, or if the intermediate driver called NdisIMDeInitializeDeviceInstance to initiate its removal.

  • InitializeHandler
    NDIS calls MiniportInitialize as a result of the intermediate driver calling NdisIMInitializeDeviceInstanceEx to initialize its miniport adapter operations for the virtual miniport being initialized.

  • QueryInformationHandler
    MiniportQueryInformation receives OID_XXX requests originating from or passed through by an overlying driver that has called NdisRequest with a request type of NdisRequestQueryInformation. The intermediate driver might handle a request or pass it on to the underlying miniport driver.

  • ResetHandler
    NDIS can call an intermediate driver's MiniportReset function at the direction of a higher-level protocol driver that has called NdisReset.

  • SetInformationHandler
    MiniportSetInformation processes OID_XXX requests made by or passed through an overlying driver that has called NdisRequest with a request type of NdisRequestSetInformation. The intermediate driver might handle a request or pass it on to the underlying miniport driver.

  • SendPacketsHandler
    MiniportSendPackets receives an array of one or more pointers to packet descriptors that specify packets for transmission over the network. Every intermediate driver should supply a MiniportSendPackets function. For more information, see Transmitting Packets Through an Intermediate Driver.

  • TransferDataHandler
    NDIS calls MiniportTransferData to transfer the remaining part of a received packet that was not previously indicated up in the lookahead buffer passed by the intermediate driver to NdisMXxxIndicateReceive. The intermediate driver might have processed the packet after having received it through the ProtocolReceive function or ProtocolReceivePacket function. MiniportTransferData is required if the intermediate driver indicates received packets to its overlying driver by calling any medium-specific NdisMXxxIndicateReceive function except for NdisMWanIndicateReceive. If the intermediate driver always indicates packets to the overlying driver by calling NdisMIndicateReceivePacket, it need not provide a MiniportTransferData function. For more information about using the MiniportTransferData function, see Indicating a Receive Packet with an NdisMXxxIndicateReceive function.

  • ReturnPacketHandler
    MiniportReturnPacket receives a returned packet descriptor that it previously indicated to a higher-level driver by calling NdisMIndicateReceivePacket. The call to NdisMIndicateReceivePacket relinquishes control of the resources indicated to the higher-level driver. After the higher-level driver consumes each indication, the intermediate driver allocated packet descriptor and the resources it describes are returned to the MiniportReturnPacket function. Do not register a MiniportReturnPacket handler if the intermediate driver always calls a medium-specific NdisMXxxIndicateReceive function to indicate packets, or if the driver always sets the status in the OOB data block associated with each packet descriptor to NDIS_STATUS_RESOURCES before it calls NdisMIndicateReceivePacket.

  • CheckForHangHandler
    NDIS calls MiniportCheckForHang at an NDIS-determined or, alternatively, at an intermediate-driver-determined interval. Generally, an NDIS intermediate driver does not provide a MiniportCheckForHang function because such a driver has no way to determine if an underlying NIC is hung. An intermediate driver probably would provide this handler if it was layered over a non-NDIS driver whose state is inaccessible to NDIS.

Certain miniport driver handler functions are never supplied by an intermediate driver. Reasons for this include: such drivers do not manage interrupting devices, such drivers do not allocate buffers at raised IRQL; or, in the case of the ReconfigureHandler, because NDIS currently does not call a MiniportReconfigurefunction. The following miniport driver handler functions are never supplied by an intermediate driver.

  • DisableInterruptHandler

  • EnableInterruptHandler

  • HandleInterruptHandler

  • ISRHandler

  • AllocateCompleteHandler

  • ReconfigureHandler

 

 

Send comments about this topic to Microsoft