NdisMCmDeactivateVc - NtDoc
Native API online documentation, based on the System Informer
(formerly Process Hacker) phnt
headers
// ndis.h
NDIS_STATUS NdisMCmDeactivateVc(
[in] NDIS_HANDLE NdisVcHandle
);
View the official Windows Driver Kit DDI referenceNo description available.
NdisMCmDeactivateVc notifies NDIS that there will be no further transfers on a particular active VC.
NdisVcHandle [in]Specifies the handle identifying the VC. This handle was supplied by NDIS to the MCM driver either when it called NdisMCmCreateVc for an incoming call or when its ProtocolCoCreateVc function set up the VC for a client-initiated outgoing call.
NdisMCmDeactivateVc can return one of the following:
| Return code | Description |
|---|---|
| NDIS_STATUS_SUCCESS | NDIS marked the VC as inactive. |
| NDIS_STATUS_NOT_ACCEPTED | The VC is already deactivated, so this call is redundant. |
An MCM driver calls NdisMCmDeactivateVc as an essential step in closing a call, usually after the packet exchange with network components that tears down the connection.
A successful call to NdisMCmDeactivateVc allows the MCM driver to discard the current call parameters for transfers on the VC, possibly reinitializing them to miniport driver-determined default values. However, if the VC is reactivated subsequently for another call, the client will supply new call parameters to the miniport driver.
The NdisVcHandle passed to NdisMCmDeactivateVc remains valid after VC deactivation is completed. The deactivation of any VC allows its creator to reinitialize the VC for reuse or to destroy it:
The driver writer determines whether an MCM driver has an (internal) MiniportCoDeactivateVc function that the driver calls in the context of tearing down connections for outgoing and incoming calls.
Only connection-oriented miniport drivers that provide integrated call-management support can call NdisMCmDeactivateVc. Stand-alone call managers, which register themselves with NDIS as protocol drivers, call NdisCmDeactivateVc instead.