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. FIX: A program experiences a 20-second delay when an established internal or external connection is closed when Forefront Threat Management Gateway Client is used

FIX: A program experiences a 20-second delay when an established internal or external connection is closed when Forefront Threat Management Gateway Client is used

View products that this article applies to.

Symptoms

Consider the following scenario:
  • You have Microsoft Forefront Threat Management Gateway Client installed on a client computer that is running a Windows operating system.
  • You have a program that is installed on a computer that uses Windows Sockets (Winsock) to connect to an external or an internal application server.

When an established connection between the client and the server is closed in this scenario, the program experiences a 20-second delay.

Note During this 20-second delay, the program may appear to be completely unresponsive.

↑ Back to the top

Cause

This problem may occur when the program that is running on the client computer performs Winsock cleanup by calling the WSACleanup() function from the DllMain() function in one of the DLLs that is used by the program. This causes a deadlock on the Windows NT loader, which prevents the WSACleanup() function from completing. A call to the WSACleanup() function from the DllMain() function violates DllMain specifications. The following is an excerpt from the "DllMain entry point" topic in the Microsoft Developer Network (MSDN) library:
"Calling functions that require DLLs other than Kernel32.dll may result in problems that are difficult to diagnose. For example, calling User, Shell, and COM functions can cause access violation errors, because some functions load other system components. Conversely, calling functions such as these during termination can cause access violation errors because the corresponding component may already have been unloaded or uninitialized."
To ease this deadlock situation to a limited extent, a hardcoded time-out of 20 seconds is used to detect this deadlock. When this time-out is exceeded, Forefront Threat Management Gateway Client skips Winsock cleanup.

↑ Back to the top

Resolution

To change the time that Forefront Threat Management Gateway Client waits before skipping Winsock cleanup, install the hotfix rollup that is described in the following Microsoft Knowledge Base article:
2616324 A hotfix rollup is available for Forefront Threat Management Gateway Client
After you apply this hotfix rollup, you can customize the time-out value by changing the value of the following DWORD registry setting:
WSP_CLEANUP_DEADLOCK_DETECTION_LIMIT_IN_MILLISECONDS
For 32-bit programs on 32-bit platforms or for 64-bit programs on 64-bit platforms, the DWORD registry setting is located as follows:
HKEY_LOCAL_MACHINE\Software\Microsoft\RAT\Stingray\Debug\FwcWsp
For 32-bit programs on 64-bit platforms, the DWORD registry setting is located as follows:
HKEY_LOCAL_MACHINE \Software\Wow6432Node\Microsoft\RAT\Stingray\Debug\FwcWsp

Note The registry keys that contain the time-out value might not exist. In this case you must create them.

↑ Back to the top

Status

Microsoft has confirmed that this is a problem in the program that uses Winsock.

↑ Back to the top

References

For more information about DllMain specifications, go to the following MSDN website:
DllMain entry point
For more information about firewall client computers, go to the following Microsoft TechNet website:
About firewall client computers
For more information about software update terminology, click the following article number to go to the article in the Microsoft Knowledge Base:
824684 Description of the standard terminology that is used to describe Microsoft software updates

↑ Back to the top

More Information

Under certain circumstances, an additional time-out might be reached in addition to the described WSP_CLEANUP_DEADLOCK_DETECTION_LIMIT_IN_MILLISECONDS value. This additional timeout can also influenced by creating a DWORD registry value that is named WSP_CLEANUP_TIMEOUT under the following location:

For 32-bit programs on 32-bit platforms or for 64-bit programs on 64-bit platforms:

HKEY_LOCAL_MACHINE\Software\Microsoft\RAT\Stingray\Debug\FwcWsp
For 32-bit programs on 64-bit platforms:

HKEY_LOCAL_MACHINE \Software\Wow6432Node\Microsoft\RAT\Stingray\Debug\FwcWsp

Note The time-out value must be specified in milliseconds. If the value is not created, the program uses a default value of 2,500 milliseconds. We recommend that you do not set a very low value for WSP_CLEANUP_TIMEOUT. This is because this timeout specifies how long the program waits for the so-called monitor thread to properly terminate. Therefore, you should not set this value that is less than 500 milliseconds.

↑ Back to the top

Keywords: kbnotautohotfix, kbfix, kbbug, kbexpertiseinter, kbsurveynew, kb

↑ Back to the top

Article Info
Article ID : 2620153
Revision : 1
Created on : 1/7/2017
Published on : 12/26/2013
Exists online : False
Views : 340