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

Article translations Article translations
Article ID: 303101 - View products that this article applies to.
This article was previously published under Q303101
This article has been archived. It is offered "as is" and will no longer be updated.
Expand all | Collapse all

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

Collapse this tableExpand this table
File nameVersion
Emsmta.exe6.0.4720.14

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

Properties

Article ID: 303101 - Last Review: October 24, 2013 - Revision: 1.3
APPLIES TO
  • Microsoft Exchange 2000 Server Standard Edition
Keywords: 
kbnosurvey kbarchive kbbug kbexchange2000presp2fix kbexchange2000sp2fix kbfix KB303101

Give Feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com