Package version is actually  2.2.4-dev - but I tried older versions, back to rev 1.85 (version not reported in PHPinfo for that revision) - same problem.

Here is the current version info for mysql and memcache from phpinfo():

MySQL Support enabled 
Active Persistent Links  0  
Active Links  0  
Client API version  5.0.51a  

memcache support enabled 
Active persistent connections  0  
Version  2.2.4-dev  
Revision  $Revision: 1.99 $

This sounds like a MySQL problem? I don't have access to a Windows box, would you mind running StraceNT or some other debugger like Visual Studio and extracting a backtrace so we might see where the process is actually hanging.

I ran the trace looking for something that might help - there is nothing there that looks useful. The output from stracent is huge, and filtering out kernel32.dll (or specific calls) caused access violations that did not appear without the filter. 

What is interesting is that no calls from the script into mysql are needed to cause the problem, it only needs to be linked in and a call to memcache::connect (or pconnect) causes this problem.

For clarification, it doesn't really "hang" - it just pauses for a few seconds before terminating. On a web server, the performance hit is huge.

It may be a problem with mysql, it seems to affect all of the mysql (mysql, mysqli, pdo_mysql) extensions, so I tried changing the libmysql.dll version, but the behavior persists. Again, it only happens if there is a call to memcache::connect in the script.

Any other suggestions?

Using microsoft debuggin tools, I was able to localize the problem to something that occurs when FreeLibrary(libmysql) is called from within the call to module_destructor() (DL_UNLOAD(module->handle)).

Here is a call stack:

00000001 0000001f 00313ce0 php_mysql!zm_shutdown_mysql(int type = 268466700, int module_number = 1, void *** tsrm_ls = 0x0000001f) [ext\mysql\php_mysql.c @ 417]
012f5648 00313ce0 104c7420 php5ts!module_destructor(struct _zend_module_entry * module = 0x004030a5)+0x4c [Zend\zend_API.c @ 1921]
104c7420 012f5600 00313ce0 php5ts!zend_hash_apply_deleter(struct _hashtable * ht = 0x004030a5, struct bucket * p = 0x00000002)+0x97 [Zend\zend_hash.c @ 611]
104c7420 00316408 00313ce0 php5ts!zend_hash_graceful_reverse_destroy(struct _hashtable * ht = <Memory access error>)+0x13 [Zend\zend_hash.c @ 647]
00313ce0 00313ce0 00313ce0 php5ts!zend_shutdown(void *** tsrm_ls = <Memory access error>)+0x2e [Zend\zend.c @ 735]
00313ce0 0674f6f2 0674f764 php5ts!php_module_shutdown(void *** tsrm_ls = <Memory access error>)+0x35 [main\main.c @ 1891]
00c0ffb0 00000000 56433230 php!main(int argc = <Memory access error>, char ** argv = <Memory access error>)+0x12d4 [sapi\cli\php_cli.c @ 1335]
7c913212 7c913281 7c913288 php!main(int argc = 3226848, char ** argv = 0x0674f6f2)+0x403 [sapi\cli\php_cli.c @ 728]
WARNING: Stack unwind information not available. Following frames may be wrong.
7c913281 7c913288 0000001e ntdll!LdrLockLoaderLock+0x6b
7c913288 0000001e 00151ee0 ntdll!LdrLockLoaderLock+0xa1
0000001e 00151ee0 00000208 ntdll!LdrUnlockLoaderLock+0x58
00050000 00000001 00310000 ntdll!LdrUnlockLoaderLock+0x5f
00000038 00c0ff30 00000000 ntdll!LdrUnlockLoaderLock+0x5f
00313c54 00000001 00000000 msvcrt!free+0x1cc
0674f6f2 0674f764 7ffde000 msvcrt!lock+0x6a4
0674f764 7ffde000 8054a6ed kernel32!RegisterWaitForInputIdle+0x49
7ffde000 8054a6ed 00c0ffc8 0x674f6f2
8054a6ed 00c0ffc8 84da1b38 0x674f764
00c0ffc8 84da1b38 ffffffff 0x7ffde000
84da1b38 ffffffff 7c839aa8 0x8054a6ed
ffffffff 7c839aa8 7c816fe0 0xc0ffc8
7c839aa8 7c816fe0 00000000 0x84da1b38
7c816fe0 00000000 00000000 0xffffffff
00000000 00000000 00000000 kernel32!ValidateLocale+0x2b0
00000000 00000000 00402fc2 kernel32!RegisterWaitForInputIdle+0x52

I have a feeling it has something to do with a blocking hook from Winsock being released, because of some fortuitous breaks in execution. Also, it makes some sense since sockets are what memcache and mysql have in common, and the problem only occurs if memcache::connect is called. is it possible that one of the extensions is not behaving with regards to winsock? On the mysql side, it apperas to be in libmysql since it affects all of the mysql extensions, and occurs when this library is released (I don't have the source handy - but it must be in the unregsiterDll function).

I have exactly the same problem. I am using memcached, mysqli. Whenever the page is finished rendering it hangs for 1-2 seconds, however if I comment out memcache->connect then it does not hang at all. 

Windows XP
PHP 5.2.8

I guess i have the same problem with libmysql.dll. However I use it from my c++ program and in hangs for about 10 seconds on call to ::FreeLibrary function. So looks like it;s solely a libmysql.dll issue.

Here is the stack trace:

 	ntdll.dll!_KiFastSystemCallRet@0() 	
 	ntdll.dll!_ZwWaitForSingleObject@12()  + 0xc bytes	
 	kernel32.dll!_WaitForSingleObjectEx@12()  + 0x8b bytes	
 	kernel32.dll!_WaitForSingleObject@8()  + 0x12 bytes	
 	FwcWsp.dll!5561df70() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for FwcWsp.dll]	
 	FwcWsp.dll!5560b77e() 	
 	FwcWsp.dll!5560bfe0() 	
 	FwcWsp.dll!55612315() 	
 	ws2_32.dll!DPROVIDER::WSPCleanup()  + 0x21 bytes	
 	ws2_32.dll!CleanupProtocolProviders()  + 0x18cc bytes	
 	ws2_32.dll!NSCATALOG::EnumerateCatalogItems()  + 0x25 bytes	
 	ws2_32.dll!DPROCESS::~DPROCESS()  + 0x68 bytes	
 	ws2_32.dll!DPROCESS::`scalar deleting destructor'()  + 0xd bytes	
 	ws2_32.dll!_WSACleanup@0()  + 0x48a0 bytes	
 	libmysql.dll!my_end(int infoflag=0)  Line 219	C
 	libmysql.dll!LibMain(void * hInst=0x10000000, unsigned long ul_reason_being_called=0, void * lpReserved=0x00000000)  Line 74 + 0x7 bytes	C
 	libmysql.dll!DllMain(void * hInst=0x10000000, unsigned long ul_reason_being_called=0, void * lpReserved=0x00000000)  Line 95	C
>	libmysql.dll!_DllMainCRTStartup(void * hDllHandle=0x10000000, unsigned long dwReason=0, void * lpreserved=0x00000000)  Line 297 + 0x11 bytes	C
 	ntdll.dll!_LdrpCallInitRoutine@16()  + 0x14 bytes	
 	ntdll.dll!_LdrUnloadDll@4()  + 0x7569 bytes	
 	kernel32.dll!_FreeLibrary@4()  + 0x19 bytes

Can you try with a newer php+memcache version please?

Also I'm not sure how it is related to memcache.

Recent memcache DLL can be found here: http://downloads.php.net/pierre/

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.