Someone updated some libs..assigned to that someone. :)

Please try using this CVS snapshot:

  http://snaps.php.net/php5-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.0-win32-latest.zip

tried the latest snapshot; I not longer get the access violation, however I cannot connect to any ldap server via LDAPS URI (says it can't contact server).

I did use ntfilemon to make sure the ldap.conf (and ldaprc) files were being read and they are. Not sure where the problem is though? I rolled back to the release version of 5.0.4 just to be sure it would still work and I can connect & bind to the ldap servers via LDAPS (& start_tls).

Just an additional idea/comment. If I go to 5.0.5 and replace the libeay32.dll and ssleay32.dll files with the ones included with the 5.0.4 release everything works fine.

Just a brief update: in 5.1.1 LDAPS URI's still don't work; the workaround I had for 5.0.5 doesn't work any longer either as we saw in the recent snapshots. I no longer get an access violation, however I cannot get a connection. 

Bbuie is correct, the problem doesn't actually present itself on the ldap_connect function, rather on the subsequent bind, search, etc.

I think the problem may be in the newer versions of openssl. What's leading me to this is that when I do a filemon trace as I execute a php script I can see it reading the conf file however it will never try to read or create the c:\.rnd file like it used to .. according to the openssl changelog I see this:
"In versions up to 0.9.6, RAND_file_name() resorted to file ".rnd" in the current directory if neither $RANDFILE nor $HOME was set. RAND_file_name() in 0.9.6a returned NULL in this case. This has caused some confusion to Windows users who haven't defined $HOME.Thus RAND_file_name() is changed again: e_os.h can define a DEFAULT_HOME, which will be used if $HOME is not set. For Windows, we use "C:"; on other platforms, we still require environment variables.
"

I've tried setting a RANDFILE env variable and that didn't help; I've also tried setting the TLS_RANDFILE in the ldap.conf file but that didn't seem to have any effect either.

just some additional information: if I try to use the ldap_start_tls() function I now get 
"Unable to start TLS: Not Supported"

maybe an error in the build process (i.e. not turning on TLS and or LDAPS)?

I've been experiencing essentially the same problems as zbowden when upgrading from PHP 5.0.4 to 5.1.1 on Win2003/Apache 2.0.49/ISAPI.  ldap_bind() breaks (returns message "Can't contact LDAP server".  Replacing libeay32.dll and ssleay32.dll with those distributed with 5.1.1 does not fix the problem, though I can confirm that ldap_bind in PHP 5.0.4 still works with the new dlls.

just tested this in 4.4.1 and I see the same behavior that I see in 5.1.1 (i.e. can't connect to server via ldaps).

I'm experiencing all of the exact problems zbowden mentions above. Running PHP 5.1.0 with Win2003/IIS6/ISAPI.

Please try using this CVS snapshot:

  http://snaps.php.net/php5.1-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.1-win32-latest.zip

Or for the inpatient the dll that should work with 5.1.x:

http://pecl4win.php.net/misc/php_ldap.dll

(Upgrading openssl in PHP distro is always troublesome)

The latest snapshot works for me (both ldaps and ldap w/ tls).

Thanks!