ID: 9852 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: IIS related Operating System: Windows 2000 PHP Version: 4.2.1 New Comment:
After some further testing on this PHP bug, I'll have to claim my previous comment about upgrading MDAC to be a bit of a Red Herring. However, my comment about running the IIS slot as an Administrator is still valid, it seems that when the scripts are being executed as an administrator (either by setting the anonymous IUSR to be an administrator or removing anonymous access and authenticating with an administrator account), this bug didn't occur in the 200 or so requests that I made to the server yet when I drop the slot back to being run as the IUSR it fails immediately. The bug now seems to be not related to a Header redirect since I can replicate it almost every time without fail by browsing to one of my plain HTML pages which loads approximately 30 images by using a PHP script to produce the image. A database connection is created in that image script as it lookups the image's ID (a random 15 character string) which maps it to the physical location of the image. I have tried to throttle the bandwidth setting as mentioned earlier but with no success. I have also been seeing these "Application Popup Errors" at the same time that the PHP script returns its CGI Header error. This popups occur on the console and are exactly the same each time, they consist of; --- Title Bar: php.exe - Application Error The application failed to initialize properly (0xc0000142). Click OK to terminate the application --- Server Information: P3-1Ghz 512Mb RAM Win2000 Server (SP3), IIS5 Hotfixes: Q326830 Q295688 Q147222 IIS is configured to run as a host header server. Unfortunately in my circumstances, it prevents the company I work for the ability to allow our clients to use PHP on our live web servers until this bug is fixed up. If this bug can be re-opened and looked into, I'm sure we would all be very grateful for it. Cheers Previous Comments: ------------------------------------------------------------------------ [2002-08-28 13:59:31] [EMAIL PROTECTED] A few notes to add to the above comment. Our client does not have the Performance Option set to foreground. The CGI error doesn't happen any more thanks to either MDAC 2.7 or MS02-009. Wish I knew which of the two fixed the CGI errors ------------------------------------------------------------------------ [2002-08-28 13:52:53] [EMAIL PROTECTED] I agree with Scott. PHP should be made to work with enterprise products. Even if the problem is not PHP's fault we still need to know exactly what causes it. It's very interesting that when Scott sets Performance Options to forground it solves his CGI error completely. It's even more interesting that MDAC 2.7 doesn't help him. This is our latest experience with a client who just installed our PHP application. Client System Configuration: 1.4 GIG processor, M$ 2000 Server, IIS, PHP, M$ SQL Server. Client installed our application. CGI errors out the ying-yang (this error happens more frequently on a machine with a fast processor). Told Client to install MDAC 2.7 RTM. Unfortunately (or fortunately depending on how you look at it), the client also decided to install this patch at the same time: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS02-009.asp So, we've found some new, interesting information from Micro$oft: "Incorrect VBScript Handling in IE can Allow Web Pages to Read Local Files" Micro$oft also talks about third party scripting languages: "... Microsoft has become aware of a handful of third-party applications that depend on unforeseen behavior in VBScript that this patch disables." So good news and bad news. Bad news: We don't know if MDAC 2.7 fixed our clients CGI erros or if the MS02-009 fixed it. Good news: we've found yet another possible solution (MS02-009) If anyone has a really fast machine out there maybe they can test this MS02-009 fix. Please post your findings here. Ottawa ------------------------------------------------------------------------ [2002-08-28 02:28:14] [EMAIL PROTECTED] Hi all, As a followup a few weeks later, I can confirm that setting the server performance to optimise for 'Forground Applications' solves the CGI Error problem completely. My guess is that PHP is launched as a CGI in user space (owned by IUSR_*), so tuning the server this way gives it more processing time. I guess the MSSQL module likes it this way. I have also had emails from others asking for assistance on this, and have had positive feedback from them that it fixed their problem, too. Scott. ------------------------------------------------------------------------ [2002-08-05 02:14:38] [EMAIL PROTECTED] Further to my other posts, some more constructive data to add to the debug efforts: 1. I now can replicate this on my XP notebook, by setting performance options to 'background services' rather than the default 'foreground applications'. It seems that MDAC 2.7 has no effect on the problem occurring as it's bundled with WinXP. 2. It seems I can prevent the problem from occurring on the production box by setting it to 'foreground applications' rather than 'background services'. This is the most successful workaround to date (for me). It also confirms that the problem is related to processor speed or timing. Scott ------------------------------------------------------------------------ [2002-08-05 00:39:36] [EMAIL PROTECTED] I applied the MDAC 2.7 Refresh patch from Microsoft to our troublesome server, and unfortunately this did not solve the problem. On our new notebook (1.6Ghz P4, WinXP) the problem does not occur at all. XP uses MDAC 2.7, too... Could be that the notebook is slower (the production machine is dual processor P3 1Ghz). Still searching for an answer... By the way, has anyone tried using the ADO COM object? Scott ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/9852 -- Edit this bug report at http://bugs.php.net/?id=9852&edit=1
