I recently implemented a similar setup:
From my deployment notes, the install steps were:
- Download PHP 5.3.1 zip (http://windows.php.net/download/, note the "Which version do I choose?" section)
- Install into c:\php
- Test php -v works on the command line (in c:\php)
- Associate .php with FastCGI: IIS Manager -> machine -> Web Sites -> site -> right click, choose properties -> choose "Home Directory" tab, click "Configuration", Mappings tab. Config for .php looks like:

- Configure FastCGI's config file (C:\WINDOWS\system32\inetsrv\fcgiext.ini) with at least:
[Types]
php=PHP
[PHP]
ExePath=c:\php\php-cgi.exe
- Append/change the following to c:\php\php.ini. Without this config, my config bounces between giving blank pages and not loading at all (I guess this is your problem):
fastcgi.impersonate = 1
fastcgi.logging = 0
cgi.fix_pathinfo=1
cgi.force_redirect = 0
- Set
display_errors
on in c:\php\php.ini and uncomment extension=php_mysql.dll.
- Restart IIS for the site (click the stop/play buttons)
In this config, you've essentially got two components, the plumbing between IIS-FastCGI-PHP, and PHP itself. I'd recommend isolating which of these isn't working:
- Temporarily edit fcgiext.ini and point the PHP ExePath to something different, e.g. c:\php\nothere.exe. If the server starts returning "The FastCGI executable could not be found" for PHP requests, then I'd FastCGI was working correctly, and PHP is at fault.
- Run PHP with its default config, the fastcgi/cgi changes above and display_errors on. You'll need to restart IIS (and possibly kill off any php-cgi processes) for the site you're restarting for the changes to be recognised.
- Run PHP on the command line with a simple phpinfo(); script, to check basic operation, and note where the loaded php.ini is. This checks a rogue config file (e.g. in c:\, c:\windows etc) is not being used.
These steps confirm (at least) the PHP executable is being invoked, with the most basic config.
hope this helps,
Lockie