Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

Alas, I don't have a specific script; the error I am seeing occurs within a particular setup on WordPress + some plugins. 

The bug clearly presents itself when rolling to PHP 5.3.7 or newer, and disappears when rolling back to PHP 5.3.0 - 5.3.6. However, I don't have a simple test case; it requires WordPress + plugins (such as WP Super Cache) as described in the original report.

I have no idea about supercache or WP in general (well, to actually know what you 
are referring to).

But what's your configuration? Do you use impersonation? run php as a given user?

Thanks so much for your quick response!

The WordPress installations in question are set up on the following:

Windows Server 2008 R2 / IIS 7.5
PHP 5.3.9 running via FastCGI (php-cgi.exe)
URL ReWrite from IIS.net 
WinCache extension for PHP from IIS.net


The following non-default settings are in php.ini:
        open_basedir = "c:\inetpub"
	expose_php = Off
	max_execution_time = 300
	error_log = php_errors.log
	extension_dir = "ext"
	cgi.force_redirect = 0
	cgi.fix_pathinfo=1
	fastcgi.impersonate = 1;
	fastcgi.logging = 0
	upload_tmp_dir = "c:/inetpub/wwwroot/sites/_phptemp/" 
	upload_max_filesize = 8M
	allow_url_fopen = Off
        date.timezone = America/Chicago
	SMTP = localhost
	smtp_port = 9909
	session.save_path = "c:\inetpub\wwwroot\sites\_phpsessions" 

	extension=php_curl.dll
	extension=php_gd2.dll
	extension=php_mbstring.dll
	extension=php_mysql.dll
	extension=php_pdo_mysql.dll
        extension=php_wincache.dll

Each site has a unique Application Pool. The sites are set up so that, if Anonymous Authentication were allowed, all users would appear as the site's Application Pool identity. In this case, the plugins work with no problems, as expected.

However, when Windows Authentication is turned on and Anonymous Authentication is turned off, that's when the 500 errors occur. In this case, when using SysInternals Process Monitor, it looks like some requests are being made under the authenticated user's identity, and some are being made under the Application Pool identity.

So, the scenarios:
- If PHP 5.3.6 or older, WordPress and plugins work as expected with any authentication setting.
- If PHP 5.3.7 or newer, WP and plugins work as expected with Anonymous Authentication only.
- If PHP 5.3.7 or newer, WP and plugins fail with 500 errors with Windows Authentication.

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.