This article was previously published under Q303101
This article has been archived. It is offered "as is" and will no longer be updated.
The Microsoft Exchange 2000 Message Transfer Agent (MTA) continues to allocate WinSock Control Blocks until all available Control Blocks are allocated.
The MTA may not release WinSock Control Blocks when a connection timeout occurs before the connection close request is received from the transport layer to WinSock. The problem is a timing issue caused by disruptions to network communications. Restarting the MTA clears any Control Blocks in use or waiting.
To resolve this problem, obtain the latest service pack for Microsoft Exchange 2000 Server. For additional information, click the following article number to view the article in theMicrosoft Knowledge Base:
301378 XGEN: How to Obtain the Latest Exchange 2000 Server Service Pack
The English version of this fix should have the following file attributes or later:
NOTE: Due to file dependencies, this update requires Microsoft Exchange Server 2000 Service Pack 1.
Microsoft has confirmed that this is a problem in Microsoft Exchange 2000 Server. This problem was first corrected in Microsoft Exchange 2000 Server Service Pack 2.
This problem is diagnosed using WinSock logging. The WinSock log will indicate that the Control Block is allocated but never used, disconnected, or closed. The following is an example of a failure in a Winsock.log file:
(001) CB 18 (instance 21) allocated(001) Use thread cb 0 for Winsock cb 18(001) Message type 1 for cb 18(008) Socket 13020 created on cb 18(008) Ac/Cl/Cn events for cb 18, socket 13020, handle 12636<additional logging entries will continue but the CB will not be returned to use>
A normal example of a Winsock.log file will include events similar to the following:
(008) CB 2 (instance 2) allocated(008) WSAAccept OK, 0 events on new socket 11340 on cb 2(008) Ac/Cl/Cn events for cb 2, socket 11340, handle 10848(008) Use thread cb 0 for Winsock cb 2(008) Wait for cb 0, handle 9036(008) Wait for cb 1, handle 11364(008) Wait for cb 2, handle 10848(001) Message type 1 for cb 2(001) Message type 243 for cb 2(008) R/W/Cl events on cb 2, handle 10848(008) Wait for cb 0, handle 9036(008) Wait for cb 1, handle 11364(008) Wait for cb 2, handle 10848(008) Events 3 notified for cb 2 using handle 10848(008) Receive header for cb 2 at offset 0(008) Header done, TPKT data length 14 bytes(008) WSARecv on cb 2, offset 24(008) WSARecv returned 14 bytes(008) Entire TPKT received(008) ioctlsocket returned 0, cb 2(008) No more data<additional logging removed for readability>
Later in the log, CB 2 will be released:
(008) Issue Disconnect for cb 2(008) close socket 11340 on cb 2, handle 10848(008) Wait for cb 0, handle 9036(008) Wait for cb 1, handle 11364(007) Message type 2 for cb 2(008) close socket -1 on cb 2, handle 0
The problem can create the following events, which are caused by network problems and which will occur when the above problem exists (but can also happen when this problem does not occur):
message NMI9215: Internal Operating System Error, severity 14 (BASE IL TCP/IP DRVR(8) Proc 262) 06-06-01 03:36:27pm connect() call failed on CB 5 Socket error 0message NMI9214: Internal Operating System Error, severity 12 (BASE IL TCP/IP DRVR(8) Proc 259) 06-06-01 03:36:27pm closesocket() call failed on CB 5 Socket error 10057
The events 9215 and 9214 are not conclusive evidence of this problem and only the Winsock.log file can properly diagnose this problem. Do not apply this fix without confirming that the Winsock. log file contains the behavior described in this article.