Microsoft KB Archive/303101

= XCON: MTA Does Not Release WinSock Control Blocks Because of Timing of Network Disruptions =

Article ID: 303101

Article Last Modified on 2/20/2007

-

APPLIES TO


 * Microsoft Exchange 2000 Server Standard Edition

-



This article was previously published under Q303101



SYMPTOMS
The Microsoft Exchange 2000 Message Transfer Agent (MTA) continues to allocate WinSock Control Blocks until all available Control Blocks are allocated.



CAUSE
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.



RESOLUTION
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 the Microsoft 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:

Component: MTA

NOTE: Due to file dependencies, this update requires Microsoft Exchange Server 2000 Service Pack 1.



STATUS
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.



MORE INFORMATION
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 

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



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  0

message 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.

Keywords: kbbug kbexchange2000presp2fix kbexchange2000sp2fix kbfix KB303101

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.