Intermediate Driver Reset Operations

An intermediate driver must be prepared to handle the situation where its outstanding sends on a binding to an underlying driver can be dropped because the underlying NIC is reset.

An underlying driver typically resets a NIC because NDIS calls the miniport driver's MiniportResetEx function when NDIS times out queued sends or requests that are bound for the NIC. If an underlying NIC is reset, NDIS calls the ProtocolStatusEx(or ProtocolCoStatusEx) function of each bound protocol and intermediate driver with a status of NDIS_STATUS_RESET_START. When the miniport driver completes the reset, NDIS again calls ProtocolStatusEx(or ProtocolCoStatusEx) with a status of NDIS_STATUS_RESET_END.

When a NIC is reset, if a bound intermediate driver has any transmit network data that is pending to that NIC, NDIS completes those network data back to the intermediate driver with an appropriate status. The intermediate driver must resubmit these network data again when the reset is completed.

When an intermediate driver receives a status of NDIS_STATUS_RESET_START, it should:

• Hold any network data ready to be transmitted until ProtocolStatusEx or ProtocolCoStatusEx receives an NDIS_STATUS_RESET_END notification.

• Hold any received network data that are ready to be indicated up to the next higher driver until ProtocolStatusEx(or ProtocolCoStatusEx) receives an NDIS_STATUS_RESET_END notification.

• Clean up any internal state it maintains for in-progress operations and NIC status.

After ProtocolStatusEx(or ProtocolCoStatusEx) receives NDIS_STATUS_RESET_END, the intermediate driver can resume sending network data, making requests and making indications to higher-level drivers.

An intermediate driver does not provide a MiniportResetEx function.