500 internal error has got to be the single most hated thing in web development. It is a non-informative "this can't be done" report of an error in Perl, PHP, ASP.NET ... you name it. But they are preventable when running PHP on IIS7.
If you take a look at the GUI for setting error pages on an IIS7 web server you will see that it is very versatile and optionally secure. In a few seconds you will see why this is such a cool set up and how to get rid of the cryptic 500 internal server errors.
This is also the place you want to be if you are planning to do any custom error pages. A nice thing to do if you really care about your site visitors experience.
My reason for getting the 500 internal error was while following a tutorial on setting up PHP on IIS7 there was a step where you are asked to set the open_basedir to "c:\inetpub". Not paying any attention to the consequences I did this and so the websites created on another hard drive were not working. I would have noticed the error in judgement right away except for the fact that the 500 error had me seeing red. After getting rid of the open_basedir setting I set out to get rid of the 500 errors also. Everything I found and read at MSDN showed command line fixes. If I wanted to do command line then I would go back to Linux. Rather than do that I spent some time going through the IIS7 admin panels icons. And there is was! the setting.

The way to go is to first set up your php.ini file to do error reporting.
Choose the one that suits or is possible on your server.
error_reporting = E_ALL
display_errors = Off
log_errors = On
error_log = /path/to/php_error_log
Shared hosting users may not have the option of editing the php. ini file so doing in the PHP script is necessary.
error_reporting(E_ALL);
ini_set("display_errors", "off");
ini_set("log_errors", "on");
ini_set("error_log", "log");
?>
The first thing to do is to turn on "display errors" which is turned off by default to prevent secure information from being written to screen in a production environment.
Now after you get that done then you may notice that the detailed information about the error is not sent from the server. If you take a look at the GUI in the previous image you will see that the default setting is one that will not show detailed error information to the remote host. The only way to see this information in this setting is to be on the server and surf to the page using the localhost address. This is a good thing. It means that the developer can get the information needed to fix the error but does not have to expose it to the world. But sometimes this cannot be helped and so changing the setting is necessary.
I am using remote desktop to configure and run the IIS7 server so the default setting works for me. But if I was on a shared host I might have to have them change this because detailed error reports are critical to debugging.
IIS 7 handles the possibilities really well and is much more flexible and easier to work with than Apache. This is just another thing that makes running PHP on windows a better experience.
Happy Publishing!
“IIS7 is… much more flexible and easier to work with than Apache”?
I haven’t laughed so hard in weeks.
Please elaborate and let the rest of us in on the joke. Laughing is therapy that is best when shared ;)