An NDIS intermediate driver must register its MiniportXxx functions and its ProtocolXxx functions, if any, with NDIS in the context of its DriverEntry function. To register its MiniportXxx functions, an intermediate driver must make either of two possible NDIS registration calls, NdisMRegisterMiniport and NdisIMRegisterLayeredMiniport. Both Ndis..Register..Miniport calls export the intermediate driver’s MiniportXxx functions. Which of these functions is called determines whether the intermediate driver or NDIS controls when the intermediate driver initializes as a miniport and, as a result, when the intermediate driver's virtual NIC(s) are made available for requests from higher level drivers.
An example of an intermediate driver that would select NdisIMRegisterLayeredMiniport over NdisMRegisterMiniport is one that needs to set up certain state after querying the underlying NIC driver before it is ready to accept requests from higher level drivers. By delaying the initialization of its virtual NIC(s), such an intermediate driver can bind to the underlying NIC driver(s), negotiate over the network to establish its operating characteristics and then, when it is ready to accept external requests directed to its virtual NIC(s), the intermediate driver makes each virtual NIC available by calling NdisIMInitializeDeviceInstance.
NDIS then calls the intermediate driver’s MiniportInitialize function in the context of NdisIMInitializeDeviceInstance for the specified virtual device instance. If the intermediate driver exports more than one virtual NIC, the driver must call NdisIMInitializeDeviceInstance for each NIC that it makes available for network requests. An intermediate driver could use this capability to make more or fewer of its virtual NICs available, depending on network traffic.
If the NDIS intermediate driver also exports a set of ProtocolXxx functions, it must also register these functions with the NDIS library by calling NdisRegisterProtocol.