Microsoft KB Archive Search

Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

  1. Home
  2. XCON: MTA Does Not Release WinSock CB Because of Timing of Network Disruptions

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

View products that this article applies to.

This article was previously published under Q303102

↑ Back to the top

Symptoms

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

↑ Back to the top

Cause

The MTA may not release Winsock Control Blocks when a connection timeout occurs before the 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.

↑ Back to the top

Resolution

A supported fix is now available from Microsoft, but it is only intended to correct the problem that is described in this article. Apply it only to computers that are experiencing this specific problem. This fix may receive additional testing. Therefore, if you are not severely affected by this problem, Microsoft recommends that you wait for the next Microsoft Exchange Server 5.5 service pack that contains this hotfix.

To resolve this problem immediately, contact Microsoft Product Support Services to obtain the fix. For a complete list of Microsoft Product Support Services phone numbers and information about support costs, visit the following Microsoft Web site:
http://support.microsoft.com/default.aspx?scid=fh;EN-US;CNTACTMS
NOTE: In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem. The typical support costs will apply to additional support questions and issues that do not qualify for the specific update in question.

The English version of this fix should have the following file attributes or later:

Component: MTA

File nameVersion
Dbserver.sch5.5.2655.16
Dcprods.cat5.5.2655.16
Emsmta.exe5.5.2655.16
Ems_rid.dll5.5.2655.16
Mtacheck.exe5.5.2655.16
Infoplog.cfg5.5.2655.16
Mtamsg.dll5.5.2655.16
Mtaperf.dll5.5.2655.16
P42.tpl5.5.2655.16
P772.tpl5.5.2655.16
P2.xv25.5.2655.16
X400om.dll5.5.2655.16

NOTE: Due to file dependencies, this hotfix requires Microsoft Exchange Server version 5.5 Service Pack 4.

↑ Back to the top

Status

Microsoft has confirmed that this is a problem in Microsoft Exchange Server version 5.5.

↑ Back to the top

More information

This problem is diagnosed using WinSock logging. The WinSock log will indicate 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 contains the behavior described in this article.

↑ Back to the top

Keywords: kbhotfixserver, kbqfe, kbbug, kbexchange550presp5fix, kbfix, kbqfe, KB303102

↑ Back to the top

Article Info
Article ID : 303102
Revision : 7
Created on : 10/26/2006
Published on : 10/26/2006
Exists online : False
Views : 335