Is phpinfo() showing thar the correct php.ini being used?

Yes, it is using the correct php.ini file.  I even did a search of the entire hard-drive to see if there was another php.ini file but there was not.  I have since setup a second computer with just win2k, iis5 and php 4.3.6 to test this and it is happening there too.

Do you have error logging enabled, if so can the log file 
be written to? 

I had the same problem i changed display_errors = 0 and it worked with php 5, then i changed it back to display_errors = Off and that worked also, strange. maybe it was missing some kind of carriage return at the end of the line or something.

I had a similar problem.  IIS5, Windows 2000 Server.

Set:

display_errors = Off
log_errors = On

However, I did not specify where the log_errors should log errors to.

The result was that I got display errors in the resulting webpages.

Then I set this:

error_log = syslog

The display errors stopped after that. However, this really looks like we've happened upon a bug.  display_errors = Off means display_errors should off under all circumstances.  There is just no valid explanation for why I could set display_errors = Off and still get display errors.

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

I have done some more investigation and this is what I found.  If I set error_reporting = E_ALL & ~E_NOTICE instead of error_reporting  =  E_ALL the bug goes away.  It seems that only the Notices are slipping through to the webpages.

I also have error_log = php_errors.log to log errors and stuff to a file in the same folder as the script.

I just upgraded to php 4.3.7 on the off chance the bug was fixed but no luck.  It exists there too.

I have figured it out.  This is not a php bug but rather a Windows folder security settings issue.  Something in IIS is setting default to deny write access to some users like "Web Anonymous Users" and "IUSR_computername" accounts.  If the user "Web Anonymous Users" is denied write access to the folder then the output will be directed to the webpage.  When I manually remove DENY WRITE ACCESS from the folder where the phperrors.log file is to be then all is ok.  I still think this is a bug because it still allows erros to display even when display_errors = off.

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

When you specified a log file that can not be written to, 
it is better to display the error rather then hide it and 
lose the record that is had every occurred. 

On a production machine we cannot display errors to the end user because of the privacy and security risks.  I think if we put a comment in the php.ini file to warn windows users of this issue and also quietly discard the errors if the file cannot be written to then it would be more acceptable.

I still think we need to put a warning somewhere because this is a potential security risk.  Maybe we could let the user choose what to do by putting a setting in the php.ini file.

You just need to setup your server correctly, this has nothing to do with a "security" problem. Not a bug in PHP -> bogus.

Hmmm, kinda disagree about the "bogus" status.  It may be behaving "as designed" but it's an unclear design.  A tag that says display_errors Off should turn them off!  The tag isn't called display_errors_if_on_or_(if_off)_when_cannot_write_to_some_other_output.

At the very least, as jonathan suggested, there should be a comment in the php.ini that describes this behaviour.

--tristan

Just so we're absolutely clear on this: if a production server runs out of disk space or has permission issue which caused the logfile to be unwriteable, PHP will start displaying server errors to the end user?

This sounds exceptionally dangerous.