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:

Thanx for the quick answer dmendez,

I now switched to Background Application,
there are no CGI Errors, but i just could not stress test the server.
But it seems as if that solved the problem.


Previous Comments:
------------------------------------------------------------------------

[2002-10-25 10:15:11] [EMAIL PROTECTED]

Ewald, this setting is applicable to windows not to IIS.
Go to start button, control panel, system, advanced tab then
performance option.

good luck.
dmendez

------------------------------------------------------------------------

[2002-10-25 03:42:41] [EMAIL PROTECTED]

We have the same problem and the same configuration
Web server:
      Win2000 Server 
      IIS 5.0
      PHP 4.2.2  (CGI mode)

   Database server:
      WinNT 4.0 SP6
      MS-SQL 7.0

   Client:
      Win2000 Professional SP1
      IE 5.5 SP1

The CGI Error is apperaing now and then.
Tried all patches (MDAC 2.7 ...) and "Check File exists.."
but nothing really worked..
I would love to try to change these perfomance options as Ottawa
posted, but unfortunately I don't know where in IIS to set them! Could
somebody give me a helping hand on that ??
I will then test and post the results!

Thanks
Ewald

------------------------------------------------------------------------

[2002-10-10 13:15:46] [EMAIL PROTECTED]

Follow up: (VERY INTERESTING)

As previously posted, a client of ours installed our PHP application
and had CGI errors like crazy. They installed MDAC 2.7 and MS02-009 and
fixed the problem.

We recently were able to convince them to try a test for us (because
their machine is three times faster than anything we have!).

We had them change their Performance Options from "Background services"
to "Application"
RESULT: CGI misbehaved ERRORS ALL OVER THE PLACE!

Set back the Performance Options to "Background services". RESULT: NO
CGI ERRORS!

Scott is really onto something here. There is no question these errors
are directly related to Performance Options and the priviledges
associated with this setting. It's very interesting that IIS doesn't
even get to the point of launching PHP in Scott's tests.

I want to do some testing with running the IIS slot as an
Administrator. I will post my findings.

Ottawa

------------------------------------------------------------------------

[2002-09-24 20:46:08] [EMAIL PROTECTED]

Hi All,
I installed the patch for Q318089 (MS02-009) and the error still
occurs.

It's also interesting to note that after running IRIS (network packet
sniffer) it seems that IIS is not even launching PHP since the header
"X-Powered-By: PHP/4.2.3" does not show up.

I can only guess in that something with IIS/PHP/MSSQL connectivity, the
PHP executable (child handles/threads) are being locked in use which
prevents PHP from launching, however a local administrator on the box
has sufficient priviledges to over-ride these locks and PHP is
launched.

-- Packet from IRIS --
GET /image_viewer.php?strPhotoID=99cBiFieBDiBaHBHcBac&strThumb=1
HTTP/1.1
Accept: */*
Referer: http://website/test.php
Accept-Language: en-au
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
Q312461)
Host: website
Connection: Keep-Alive
Cookie: PHPSESSID=b3cfba912345ad3043a08bd6d6faf16d

HTTP/1.1 502 Gateway Error
Server: Microsoft-IIS/5.0
Date: Wed, 25 Sep 2002 01:18:12 GMT
Connection: close
Content-Length: 215
Content-Type: text/html

<head><title>Error in CGI Application</title></head>
<body><h1>CGI Error</h1>The specified CGI application misbehaved by not
returning a complete set of HTTP headers.  The headers it did return
are:<p><p><pre></pre>
---

Regards
David

------------------------------------------------------------------------

[2002-09-24 20:05:43] [EMAIL PROTECTED]

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

------------------------------------------------------------------------

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

Reply via email to