Partager via

Intermediate Driver DriverEntry Function (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's initial required entry point must be explicitly named DriverEntryso that the loader can properly identify it. All other exported driver functions, described here as MiniportXxx and ProtocolXxx ,can have any developer-specified name because they are passed as addresses to NDIS.

In an intermediate driver, DriverEntrymust at a minimum:

  1. Call NdisMInitializeWrapper and save the handle returned in the NdisWrapperHandle parameter.

  2. Call NdisIMRegisterLayeredMiniport to register the driver's MiniportXxx functions, passing the handle obtained in Step 1.

  3. Call NdisRegisterProtocol to register the driver's ProtocolXxx functions if the driver subsequently binds itself to an underlying NDIS driver.

  4. Call NdisIMAssociateMiniport to inform NDIS about the association between the driver's miniport lower edge and protocol upper edge.

An intermediate driver should call NdisMRegisterUnloadHandlerto register an unload handler. This unload handler is called when the system unloads the intermediate driver. If DriverEntryfails, this unload handler is not called, the driver is simply unloaded.

The unload handler registered with NdisMRegisterUnloadHandlershould call NdisDeregisterProtocolto deregister the protocol portion of the intermediate driver. The unload handler should also perform any necessary cleanup operations, such as reallocating resources used by the protocol portion of the driver.

Note that an unload handler differs from a MiniportHaltfunction: the unload handler has a more global scope, whereas the scope of the MiniportHaltfunction is restricted to a particular miniport driver instance. The intermediate driver should clean up state information and reallocate resources when each underlying miniport driver that is bound to it is halted.

ProtocolUnloadis an optional unload handler. Register an entry point for this function in the ProtocolCharacteristicsstructure that you pass to NdisRegisterProtocol. NDIS calls ProtocolUnloadin response to a user request to uninstall an intermediate driver. NDIS calls ProtocolUnbindAdapteronce for each bound adapter, then NDIS calls ProtocolUnload. This handler is called before the system actually unloads the driver. This timing provides a chance to release any device objects or other resources that might otherwise prevent the system from calling the unload handler registered with NdisMRegisterUnloadHandlerand unloading the driver.

DriverEntrycan initialize spin locks to protect any globally-shared resources that the intermediate driver allocates, such as state variables, structures, and memory areas. The driver uses these resources to track connections and to track sends in progress or driver-allocated queues.

If DriverEntryfails to allocate any resources that the driver needs to carry out network I/O operations, it should release any previously allocated resources and return an appropriate error status. For example, if DriverEntryhas called NdisMInitializeWrapper, DriverEntrymust call NdisTerminateWrapper.

For more information about registering intermediate drivers, see the following topics:

Registering as an NDIS Intermediate Driver

Registering an Intermediate Driver as a Miniport

Registering an Intermediate Driver as a Protocol

 

 

Send comments about this topic to Microsoft