the device driver microsoft virtual miniport adapter

The call to MiniportInitializeEx can happen at a later time and therefore is not necessarily within the context of the call to NdisIMInitializeDeviceInstanceEx. If NDIS does not receive such an IRP, NDIS will not call the intermediate driver's MiniportInitializeEx function. The MUX intermediate driver calls NdisIMInitializeDeviceInstanceEx once for each device name that is specified in the device name list.Ĭalling NdisIMInitializeDeviceInstanceEx results in a call to the intermediate driver's MiniportInitializeEx function to perform the initialization of the specified virtual miniport, provided that NDIS receives an IRP_MN_START_DEVICE to start the device.

In this case, the UpperBindings registry key is a MULTI_SZ entry that contains the list of device names. The recommended location for the list is the UpperBindings registry key.

The MUX intermediate driver requires a notify object that maintains the list of virtual miniport device names. The intermediate driver obtains the device name from the UpperBindings registry key.įor an n-to-one MUX intermediate driver that layers multiple virtual miniports over a single physical NIC, there must be a device name for every virtual miniport. Set the DriverInstance parameter of NdisIMInitializeDeviceInstanceEx to the device name for the virtual miniport being initialized. There does not have to be a one-to-one relationship between virtual miniports and open adapters. Note An intermediate driver is not required to call NdisIMInitializeDeviceInstanceEx when it opens an underlying miniport adapter. An intermediate driver calls NdisIMInitializeDeviceInstanceEx from its ProtocolBindAdapterEx function one or more times to request initialization of one or more virtual miniports. An intermediate driver initializes its virtual miniports after it has successfully opened an underlying miniport adapter and is ready to accept requests and sends on its virtual miniports.

The device driver microsoft virtual miniport adapter