PHP on Windows 2003 IIS 6 Displays 404 Page Not Found

After Installing PHP 5 using the Windows installer on Windows 2003 you may find that IIS displays a “Page Not Found” 404 error for every .php page. This is a perplexing error because is it not actually a real 404 error. The file is really there, but IIS is unable to process it based on how the installer configures the extension mapping. Instead of providing any useful information or even a 500 error; however, IIS throws out a 404.

Steps to Fix the Problem:

Before you troubleshoot further, you may want to read #5 about how the Application Pool effects PHP configuration changes.

1. Replace the old DOS format path to the PHP Executable with a full path w/ quotes
2. Move php.ini to C:\Windows
3. Edit php.ini to set cgi.force_redirect = 0 (only necessary for CGI mode)
4. Make sure php-cgi.exe and/or phpisapi.dll are included in Web Service Extensions
5. Recycle the Application Pool

1. Replace the old DOS Path Format

Edit Map

The default path to PHP is C:\Program Files\PHP. When creating the IIS extention mapping, the PHP Installer uses the old DOS format path to the PHP ISAPI or CGI executable such as “C:\PROGRA~1\PHP\PHP5IS~1.DLL”. IIS does not seem to like this format.

One simple solution for this is to simply reinstall PHP to C:\PHP, or another location that doesn’t use long filenames. This will generally save you a lot of grief as PHP and its installer do not seem to handle windows long file names consistently.

If you prefer to keep things in Program files, go to the IIS Extension Mapping screen and locate the value for “.php” (See screenshot above). Click the browse button, select the executable and put quotes around it the entire path. So the value for this field should look like this “C:\Program Files\PHP\php5isapi.dll” (WITH the quotes around it). If you have installed PHP in CGI mode instead, the file name would be php-cgi.exe instead of php5isapi.dll

While you’re at it you may want to check the box for “Verify that file exists” as well. This allows IIS to handle actual missing pages (ie broken links) and return a 404. Otherwise IIS will just pass the request to PHP without verifying the .php file really exists and PHP throws a CGI error when the file isn’t found. People seem to have inconsistent results with this setting.

If you recycle the app pool at this point (see step #5) you *may* solve the 404 error depending on what extensions you installed or whether you had re-run the installer and changed stuff. However, you may still have issues changing php.ini settings in which case keep reading.

2. Copy php.ini to C:\Windows

The PHP installer creates a php.ini file for you based on your selections in the setup process. However the installer saves the file in C:\Program Files\PHP. The problem is that PHP is looking in C:\Windows for the .ini file. So, you need to move the file php.ini to C:\Windows. This may be confusing because PHP seems to run fine. But if you look closely at the phpinfo() output, you may find that php.ini file is not being loaded and all default settings are being used.

One of the critical things when configuring PHP is to actually edit the .ini file that is being used by PHP. The installer creates a worthless file in a location that PHP won’t read and so you may waste a lot of time editing this file. PHP pretty much universally will check the Windows folder for php.ini on all varieties of Windows, so my advice is to use that location and delete any other php.ini files that are hanging around..

3. Set cgi.force_redirect = 0 (Only necessary for CGI mode)

Various people report that you need to edit php.ini and set:

cgi.force_redirect = 0

I haven’t noticed this setting having any effect on my installations, but many people claim it is necessary when you are running PHP in CGI mode. This setting will have no effect if you are running in ISAPI mode.

4. Make sure php-cgi.exe and/or phpisapi.dll are enabled in Web Service Extensions

In IIS Manager, click on “Web Service Extensions” This includes a list of all dll and exe files that IIS is allowed to execute. The extension mapping that is specified for .php files must also be added here. I prefer to just add both php-cgi.exe as well as php5isapi.dll here and enable them both so that if I don’t need to worry about it again.

If the handler is already in the list, make sure that it is “enabled” as well. The enabled services have a green overlay on the service icon.

Lastly, confirm that the file path is exactly the same here as it is in your .php extension mapping configuration. That includes the dos path formatting. If you use junctions, you need to be using the same path in both places. IIS seems to check the path rather than the executable. It will not recognize if you use a slightly different path, even if they both point to the same executable.

5. Recycle the Application Pool

In order for any PHP configuration changes to take effect in Windows 2003, you need to recycle the Application Pool. If you have made changes to php.ini and they don’t seem to take effect, this is likely the reason. Among other things, the pool caches PHP settings and you need to clear it before new configuration settings will take effect. You’ll read people telling you to restart IIS (which doesn’t recycle the app pool) or even reboot your machine (which is overkill). You don’t need to do either of those. Just right-click on the DefaultAppPool in the IIS management interface and “Recycle” is one of the options.

Recycle Pool

If I’m having trouble with the ini file, I like to have a typical phpinfo.php file on the server while I make some arbitrary change to the php.ini file (like the session timeout or the max upload size). I refresh phpinfo.php and verify that my changes are taking effect. You can also check the Windows Event logs under “System” which will sometimes report errors in the php.ini file.

Notes regarding re-running the PHP installer to make changes:

The PHP installer does not really handle changes all that well. For one thing it will overwrite the path to the PHP executable w/ the old DOS format so you need to fix that after you run it.

The 2nd thing is that it will write changes to C:\Program Files\PHP\php.ini – regardless of the fact that PHP is actually looking at C:\Windows\php.ini

If you had previously moved php.ini to the windows folder, when you run the Change installation feature, it will create a fresh php.ini file that only incorporates the most recent changes. (ie, if you had 10 extensions enabled and you make a change to enable 1 more, your new php.ini file will only have the 1 enabled and the previous 10 will no longer be enabled)

One way around this is to temporarily move C:\Windows\php.ini file to C:\Program Files\PHP. Then run in installer to make changes. The installer will write changes to php.ini in that location. Then, move php.ini back to C:\Windows.

18 Responses to “PHP on Windows 2003 IIS 6 Displays 404 Page Not Found”

  1. Dhiraj Gaur February 9, 2008 at 3:53 am #

    Thank you very much for this info I was able to help my friend in PHP installation using this page.

  2. falc0n February 18, 2008 at 2:23 pm #

    Hi,

    many thanks for the article. After reading your advices, I’ve been able to make php running on w2k3 server, but I’m still getting “404″ on w2k3 64-bit edition server.
    Does it matter if I’m trying to install it on x64 edition?

  3. Jason February 18, 2008 at 2:50 pm #

    hey falc0n – you might try installing in C:\php instead of program files, just rule out a path problem.

    aside from that, i’m not sure you might check the event log and see if there are any clues there as well. if you figure it out, please post a comment!

  4. cbright March 6, 2008 at 10:32 pm #

    thanks for this. I was banging my head against a wall for hours wondering how I could have taken a couple sites down with a minor upgrade.

  5. Emile March 12, 2008 at 1:52 am #

    You deserve a nobel prize for this article…. THANX A LOT!!! Saved me plenty of hours troubleshooting.

    I didnt have to change the cgi.force_redirect setting, probably because I installed the isapi module.

  6. Alan March 27, 2008 at 1:17 pm #

    Much thanks for the posting and posting it in a clear verbose style. So many other sites try to help but are so… economical… with their words that stuff gets left out.

    Again, thanks.

  7. Sam Dean April 2, 2008 at 2:33 am #

    Isn’t it time the PHP folk put an end to this ongoing misery with php.ini?

  8. Thomas April 26, 2008 at 7:28 am #

    With this instruction is truely was a “VerySimple” task to get it working. Thank you!

  9. Will June 24, 2008 at 3:39 am #

    Thanks for the tip on recycling the threadpool. Of note – if sites relying on PHP have dedicated threadpools, they will need to be recycled as well to see the changes.

    Thanks for pointing me in the right direction.

  10. Viv March 20, 2009 at 12:05 am #

    Application pool advise is perfect.. thanks very much

  11. Mills April 7, 2009 at 1:22 pm #

    Thanks so much!! Your suggestions worked like magic – wish i would have found before hours of going through the manual.

  12. Dustin July 20, 2009 at 9:39 pm #

    Thanks! Spent several hours looking all over the web… your advice fixed me up in less than 15 min!

  13. Joaquin October 5, 2009 at 12:58 pm #

    Hello,

    Thanks for the article. I could solve de 404 problem… but now I have another one. My php labels are not being executed. They get executed when I add the word “php” in the opening label: , otherwise it is not being processed.

    This is something I hadn’t faced in previous versions of PHP/Windows server. Any idea??

    ((This is a small problem actually, but if I don’t find a way to solve it, I’ll have to replace all my opening PHP labels from all my code.))

    Thank you!

  14. JG May 12, 2010 at 10:18 am #

    @Joaquin

    Your problem is that your new PHP configuration probably has the PHP short_open_tag parameter turned off. Locate it in the php.ini file and set it to On.

  15. lbatista May 14, 2010 at 10:28 am #

    Thankx. Two Thumbs UP!

  16. Richard Morris October 20, 2010 at 7:32 pm #

    Following your post, I was able to make php render in my browser. I had started with the Platform Installer for Joomla…mySql did not install properly. That was fairly easy to re-install. But PHP would not render on my browser. First I followed the clear steps on LearnIIS.net, and found some useful testing methods at php.net; but still PHP would not render. Finally, found this *very* helpful post. Thanks a million.
    step 1: I used FastCGI.exe instead; see http://learn.iis.net/page.aspx/247/using-fastcgi-to-host-php-applications-on-iis-60/

    step 2: copied php.ini to c:\windows (as recommended)
    step 3: Set cgi.force_redirect = 0 (Only necessary for CGI mode)
    step 4: Make sure php-cgi.exe enabled … The installer did not do this at all…
    step 5: Recycle Application Pool
    step 6: OK test of phpinfo() — YAHOO!!!

  17. Nick January 12, 2012 at 12:02 pm #

    At last! Someone who knows the answer. I’ve searched everywhere, followed loads of tutorials from all sorts of “experts” but got nowhere.
    Thanks Jason

Leave a Reply

Please leave these two fields as-is: