Deleting a VC (NDIS 5.1)
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.
Only the connection-oriented client, call manager, or MCM driver that initiated the creation of a virtual circuit (VC) can initiate the deletion of that VC. A client therefore deletes a VC that it previously created for an outgoing call, a call manager or MCM driver deletes a VC that it previously created for an incoming call over the network, and a call manager deletes a VC that it previously created for exchanging signaling messages over the network. (An MCM driver does not call NDIS to delete a VC that it created for exchanging signaling messages. The MCM driver deletes such a VC with an internal operation that is opaque to NDIS.)
A connection-oriented client or call manager initiates the deletion of a VC with NdisCoDeleteVc.
The following figure shows a client of a call manager initiating the deletion of a VC.
The following figure shows a client of an MCM driver initiating the deletion of a VC.
The following figure shows a call manager initiating the deletion of a VC.
When a client or call manager calls NdisCoDeleteVcor when an MCM driver calls NdisMCmDeleteVc, there must be no outstanding calls on the given VC and that VC must already have been deactivated (see Deactivating a VC). To meet these requirements implies that the following conditions hold:
The client has already called NdisClCloseCall with the given NdisVcHandle and its close-call request has completed successfully (see Client-Initiated Request to Close a Call).
The call manager has already called NdisCmDeactivateVc or the MCM driver has already called NdisMCmDeactivateVc with the given NdisVcHandle and the deactivation request has completed successfully (see Incoming Request to Close a Call).
A client's or call manager's call to NdisCoDeleteVccauses NDIS to call both the underlying NIC driver's MiniportCoDeleteVc function and the ProtocolCoDeleteVc function of the client or call manager with which the caller shares the NdisVcHandle(see the three previous figures).
MiniportCoDeleteVcfrees any resources allocated for the VC, as well as the miniport driver's context for the VC. ProtocolCoDeleteVc releases any resources that the client or call manager used to perform operations on and track state for the VC. Both MiniportCoDeleteVc and ProtocolCoDeleteVc are synchronous functions that cannot return NDIS_STATUS_PENDING.
An MCM driver initiates the deletion of a VC with NdisMCmDeleteVc (see the following figure).
An MCM driver's call to NdisMCmDeleteVccauses NDIS to call the ProtocolCoDeleteVcfunction of the client with which the MCM driver shared the NdisVcHandle.
When NdisCoDeleteVcor NdisMCmDeleteVcreturns control, the NdisVcHandleis no longer valid.