The last known good version was 5.2.13 (which is faster than 3 seconds but adds a 
slow delay)

From OpenSSL 0.9.8q Sources :

The RAND_screen() function is available for the convenience of Windows
programmers. It adds the current contents of the screen to the PRNG.
For applications that can catch Windows events, seeding the PRNG by
calling RAND_event() is a significantly better source of
randomness. It should be noted that both methods cannot be used on
servers that run without user interaction.

This has been fixed in 5.3.4 (I patched curl). Which versions and builds do you use exactly?

Please comment this line to fix the problem :

php-5.3.4\ext\openssl\openssl.c PHP_FUNCTION(openssl_random_pseudo_bytes) line 
4898 :

#ifdef WINDOWS
        RAND_screen();
#endif

I'm using the 5.3.4-VC6-TS version (as Apache 2.2 module)

Here is an asm dump of lib_curl.dll 5.3.4 VC6 TS where RAND_screen is used :

0035DB10   > \E8 FF360100   call    <jmp.&SSLEAY32.#74>
0035DB15   .  E8 F4360100   call    <jmp.&SSLEAY32.#183>
0035DB1A   .  85C0          test    eax, eax                                                      
;  kernel32.BaseThreadInitThunk
0035DB1C   .  75 01         jnz     short php_curl.0035DB1F
0035DB1E   .  C3            ret
0035DB1F   >  E8 E4360100   call    
<jmp.&LIBEAY32.#3212_OPENSSL_add_all_algorithms_noconf>
0035DB24   .  E8 D9360100   call    <jmp.&LIBEAY32.#468_RAND_screen>
0035DB29   .  B8 01000000   mov     eax, 1
0035DB2E   .  C3            ret


A simple replace of E8 D9360100 by 90 90909090 will fix the problem... but maybe 
a call to the regular rand() function could be needed elsewhere...

If you want to try the difference, here is the patched php_curl dll.

http://tanguy.wdscript.fr/files/php_curl.534vc6ts.Patched.zip

I'm now compiling php with openssl comment... to check if its the cause of the 
problem... i dont understand why this code is in php_curl dll code...

Ok, hmm after a night of debug, i think the code is in the static libcurl_a.lib

i've tried to build a module with standard libcurl dlls (php_curl of 64k).... but 
seems to have a bad address for the curl_global_init() call

I think we need to follow this issue to curl team :p

Just to confirm :

I tried all 5.3.4 and 5.2.16 versions (TS/NTS VC6/VC9), even a self compiled one 
from sources and the problem always appears on Vista and Seven x86

I posted a bug report to curl team... but i cant find RAND_screen() call in their 
lastest release...

As I said, the libcurl previous release (for our build only) has been modified to do not call this function anymore. The latest libcurl release should have the fix too.

btw, I just applied this change to my tree as well:

https://github.com/pierrejoye/curl

nmake /f Makefile.vc9 WINDOWS_SSPI=1 USE_IPV6=1 WITH_DEVEL=g:\php-sdk\lib_builds\vc9\x86\deps CFG=release-ssh2-ssl-dll-zlib

to build it for PHP's VC9 (with almost all protocols, incl. ssh2). As long as you copied the dependencies in ..\deps (like for php's builds).

Thanks for these precisions.

But i use VC6 to use same apache DLLs (on a vista virtual machine to use the 
"recent" Win32 SDK)

Do you know where we can find the fixed lib for VC6 x86 ?
I ve used the 7.21.0 available here but i think its the old one :

http://pecl2.php.net/downloads/php-windows-builds/php-libs/VC6/x86/

Also, and i dunno why but phpinfo() curl block says libcurl 7.20 instead of 7.21

I need it to fix the problem on my Wamp package EWS (detected one year ago to 
check version informations)

http://ews.wdscript.fr

I will update teh VC6 builds later tonight.

However I would recommend to use the VC9 versions instead, VC9 builds of Apache can be found at http://apachelounge.com

Yea... i think i will. I was reading that on this site one hour ago ;)
i've seen mod_fcgid 2.3.6 and eAccelerator are available on this site...

its now time to switch and say goodbye to my VC6 VM :)

If you use fcgid with apache, then you can use VC9 php builds right now, without switching to a VC9 apache.

Hmm no, in fact i use mod_fcgid for another CGI... WDScript :) since 2010
http://sourceforge.net/apps/trac/wdscript/attachment/wiki/FastCGI/ProtocoleFastCGI
.png

PHP was used as apache module, to skip this kind of bug and reduce loading times 
;)

But i will also try a switch, now mod_fcgid seems stable on Win32 too ;)

My patch has been applied upstream as well now. Let close this one (both versions are fixed).

See http://sourceforge.net/tracker/index.php?func=detail&aid=3140533&group_id=976&atid=100976

See http://sourceforge.net/tracker/index.php?func=detail&aid=3140533&group_id=976&atid=100976

5.3.5 (vc6 ts) is affected too :( look like the libcurl was not updated...

Here is the patched php_curl.dll for VC6 TS (for PHP as Apache Module)

http://tanguy.wdscript.fr/?q=system/files/php_curl.535vc6ts.Patch_.zip

VC6 support is discontinued. So please try 5.3.6 only which is VC9.

The problem is not related to VC6 or VC9 version... but to the .lib used to 
compile PHP and/or extension.

So Apache's PHP handler is discontinued too ?

No, it is not. Please read the releases notes and the left column on 
windows.php.net.

We only stop to support VC6.

About the library, it is fixed, both in curl's release and php.

Also, its possible to use VC9 to compile with MSCVRT, i had made that for other 
projects. Borland C++ also compiles with MSCVRT.

But we loose Windows 2000 compatibility, working with XP yo Seven.

Windows DDK is required to do that..

but to my mind, i think VC10 is a better solution than VC9

CRT has nothing to do with win2000 compatibility, which was killed anyway with the 
release of 5.3.0.

It is nice and shiny to say than VC10 is better, but it was not ready last year in 
April.

Here is the call stack on PHP 5.3.6 VC9 :

008BF5E8   1004903E  RETURN to libeay32.OpenSSL_add_all_digests+13E from 
libeay32.EVP_add_digest
008BF5EC   6D553C3A  RETURN to MSVCR90.6D553C3A from MSVCR90.6D55CF25
008BF5F0   D1F10C83
008BF5F4   02079948
008BF5F8   1003FE95  RETURN to libeay32.1003FE95 from libeay32.RAND_poll
008BF5FC   6724EFA9  RETURN to php_curl.6724EFA9 from php_curl._RAND_screen
008BF600   67237DEB  RETURN to php_curl.67237DEB from php_curl._Curl_ssl_init
008BF604   5D660FB0  php5ts.tsrm_mutex_alloc
008BF608   67235D71  RETURN to php_curl.67235D71 from php_curl._curl_global_init
008BF60C   00000001
008BF610   5DB76E20  offset php5ts.module_registry
008BF614   02142E90
008BF618   00000000
008BF61C   5D585EB1  RETURN to php5ts.5D585EB1
008BF620   00000001
008BF624   00000020
008BF628   02142E90
008BF62C   5DB76E20  offset php5ts.module_registry
008BF630   02079908
008BF634   00000000
008BF638   02142E90
008BF63C   5D612FBF  RETURN to php5ts.5D612FBF
008BF640   02079948
008BF644   02142E90
008BF648   00000000
008BF64C   02142E90
008BF650   02142E90
008BF654   0000000A
008BF658   5D585FE9  RETURN to php5ts.5D585FE9 from php5ts.zend_hash_apply
008BF65C   5DB76E20  offset php5ts.module_registry
008BF660   5D585DE0  php5ts.zend_startup_module_ex
008BF664   02142E90
008BF668   5DB76E20  offset php5ts.module_registry
008BF66C   5D585F30  php5ts.zend_sort_modules
008BF670   00000000
008BF674   00000000
008BF678   02142E90
008BF67C   6D55F16A  MSVCR90.getenv
008BF680   5D64314D  RETURN to php5ts.5D64314D from php5ts.zend_startup_modules

A solution could be to prevent SSL initialization on module load, and only do it 
on first SSL request...

It is also possible to fix that in extension code, in interface.c
by replacing CURL_GLOBAL_SSL by CURL_GLOBAL_WIN32... 

	if (curl_global_init(CURL_GLOBAL_WIN32) != CURLE_OK) {
		return FAILURE;
	}

Related messages :
http://osdir.com/ml/web.curl.general/2004-05/msg00068.html
http://curl.haxx.se/mail/lib-2004-06/0133.html

The docs might be a bit sparse in this ares, yes. But the SSL bit should be set 
unless you have initialized the OpenSSL library already in some other way.

And the openssl module do the library init :

PHP_MINIT_FUNCTION(openssl)
...
SSL_library_init();