Receiving Error Notifications
In response to client-submitted IRPs, the transport driver notifies a TDI client of error conditions in the status codes that it returns. While this provides a client with request-specific errors, it would be difficult for the client to maintain a count of failed IRPs and apply internal logic to determine whether the underlying drivers are in a state that renders the client's subsequent network I/O operations unreliable.
To receive a notification of unexpected error conditions in an underlying driver or in the underlying physical medium, the client can register its ClientEventErroror ClientEventErrorExhandler with its underlying transport, as already described in Opening a Transport Address. Then, if the transport itself or any lower driver that the transport depends on to carry out client communications over the network encounters such an error condition, the transport calls ClientEventError(Ex). This call notifies its client that network I/O on the client's open transport address is no longer reliable (or, sometimes, even possible). Then, the client can notify its own higher level clients of the network failure and clean up all TDI-client-allocated resources for pending operations on the affected open transport address.
Note The TDI feature is deprecated and will be removed in future versions of Microsoft Windows. Depending on how you use TDI, use either the Winsock Kernel (WSK) or Windows Filtering Platform (WFP). For more information about WFP and WSK, see Windows Filtering Platform and Winsock Kernel. For a Windows Core Networking blog entry about WSK and TDI, see Introduction to Winsock Kernel (WSK).