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.
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.
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 ClientAfter 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_MILLISECONDSFor 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\FwcWspFor 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.
Status
Microsoft has confirmed that this is a problem in the program that uses Winsock.
References
For more information about DllMain specifications, go to the following MSDN website:
DllMain entry pointFor more information about firewall client computers, go to the following Microsoft TechNet website:
About firewall client computersFor 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
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\FwcWspFor 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.
