I followed all the hints here but IIS 5 and PHP 5 would still not behave.  What was necessary in the end was:
1) Set
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Script Map]
".php"="your path to php\\php.exe"

2) ensure there is not a php.ini in the windows system folder and that there is one wherever you've put PHP

3) edit php.ini and set cgi force redirect to 0 and 
cgi.rfc2616_headers = 1

4) Put the PHP scripts in their own folder underneath the inetpub root

5) Open the IIS console, right click your new php folder
In the Directory tab
 set application name to the name of the folder
 set executable and script as permission
 set application protection to low
Click configuration and check that .php is mapped to wherever you put PHP

Restart IIS

Try a very simple PHP page and it should work

Nigel

Saw the problem for two more days after installing PHP version 4.3.4 (replacing version 4.3.3), after that the problem completely disappeared.

I've had had this issue occur in my fresh installation of 4.3.6 (Win2K, CGI), even after applying all the recommended fixes/changes/configurations. So far, I've found that if I remove one particular image, the problem goes away.  Put the image back, and the problem creeps up again.  I've changed around the <img> tag, and still cannot get rid of the "...CGI application misbehaved...".

FWIW, this page uses SSL.

I can add onto / narrow down salmnarshad's info a bit:

I just had this error start popping up on pages where my main frame had images added to it. I've had an image on the menu frame (which does not get updated) and it hasn't caused any errors before.

In comparing against Salmnarshad's info my test cases are:
-Running PHP 4.3.4 on a 2000 server as CGI under IIS
-Running under 2 frames (only the main frame is being updated)
-I'm making MSSQL calls not MySQL calls on both the calling page, and the next page displayed
-Using a header("Location: yada yada") redirect to move between pages
-The MSSQL connection is being closed just before the redirect, and reopened right after it...it is not being left open
-Our server is running over 1ghz
-Pages are being viewed by client machines (errors have occurred haphazardly on different clients, we have been unable to replicate the error everytime)

Simplest solution seems like the easiest for me...I'm going to dump the images from the pages that are causing this problem to try and resolve it quickly on my end.

More information as I've had a chance to talk to our sa and users:

We've had the new pages (ones with images) up for a week and no one had a problem until our IIS server puked last night.

After the reset, the CGI errors occurred only once per page.

ie: User Jay clicks thru to one of the pages that fits the conditions described in this bug report...the server returns the CGI error. Jay goes back and tries the page again, everything works fine...every user after him sees the page okay.

But when a page is opened for the first time after the reset...it will throw an error...this is only for pages that satisfy the conditions I've posted earlier.

After about 28 hours from the reset, the users have self corrected the problem by using the system...this might be what happened to salmanarshad on his Jan. 27th post, but this doesn't explain why steve on Apr. 23rd kept receiving the error until he removed the image tag...

In my case, the problem disappeared mysteriously, after upgrading from PHP 4.3.2 to PHP 4.3.3; No single line of code was changed. phpMyAdmin and netOffice were the two applications that I had previously been using and they caused the CGI misbehaved error frequently, but then the problem disappeared after the upgrade.

Ok wait... I did other things too... upgrading php was a part of maintainance operations I did in that time, other things include removeing unnecessary programs, defragmenting hard disk, removing unnecessary databases from mysql. Now I am not sure which one worked... but I am not having that problem anymore. If I remember any thing else I'll add it here.

I need to retract my earlier statement of: 
"After the reset, the CGI errors occurred only once per page."

3 days in and we've had a couple reoccurring page errors...the frequency is going down, or people aren't getting back to me on the problem...the latter is most likely the case here.

I should also state that we are running IIS 6 on 2003(I previously wrote 2000...my fault)

I found that excluding c:\php\ from my (Norton) virus scanner fixed the problem.  Some comments led me to believe that windows was getting grumpy when multiple requests were being handled by php.exe.  This made me wonder if the antivirus was locking the file, since it was set to scan every exe upon execution.  Turning off scanning on the PHP folder has fixed this problem for me (iis5 / PHP 4.3.6).

PHP5 Release candidate 2 + IIS5 on W2K Advanced Server.

Still having the same problem.. The damned CGI misbehaved bla bla bla.. 

I need a complete SOLUTION for this, not WORKAROUND, if we're talking about a complete language.
What i did :
1.. Downloaded *latest* version of the PHP (5 RC2)
2.. Expanded zip file to the directory C:\PHP5\
3.. added paths to PATH as C:\PHP5;C:\PHP5\EXT as in folder tree.
4.. added extension .php and .php5 with c:\php5\php.exe %s %S
5.. added extension to HKEY_CLASSES_ROOT
6.. added pathinfo to HKEY_LOCAL_MACHINE
7.. gave permissions -full control- to IUSR_*, IWAM_*, EVERYONE on C:\PHP5 and c:\inetpub\wwwroot\PHP5SCRIPTS
8.. edited php.ini file 
a. cgi.force_redirect=0
b. ;doc_root=

so.. what's next?!?
1.. how should I get this system working with PHP?
2.. do I have to mess with these with every new installation/upgrade/system change?

thanks folks, for *not* helping us newbies by not providing an automated system for the installation process.

Onder

Hi, thanks for all the other posts and hopefully this can help someone else!

I also struggled with this problem of getting PHP to run on IIS.  I solved it slightly differently on my development server to the live production server, both running Win2003 Server (production being more patched, secure, etc).

1) Ensure anonymous access not allowed by editing the website details in IIS.
This solved my one server but not the other.  However, it all seems to stem from the security and permissions.

2) Try access the website using https:// instead of http:// ... strange, I know, but it worked for the production server (and saved me having to rewrite in ASP).

Gareth

Seems like php.exe in php 5 rc3 does not prepend any headers.
--> cgi error in IIS 
php-cgi.exe does... --> works fine for me now.

Example:

test.php 
 <? echo "hi"; ?>

C:\php>php.exe test.php
hi
C:\php>php-cgi.exe test.php
Content-type: text/html
X-Powered-By: PHP/5.0.0RC3

hi
C:\php>

I've solved me problem by adding a redirect file between my login page and start page. This way it seems that my use of header("Location: yada yada"); got some breathing room and could "catch" up and smoothly go to my start page instead of throwing a CGI error ...

I use IIS 5, W2000 server with frames on start page and got the error only when i used header-function above or when i refresh my page quickly. 

This is not the best solution, but could be usefull in login-situation where i now put some text to tell the user that the login is processing.

Redirect i used meta tag and only 1 sec delay.

Hope this might solve the problem for some of you.

People, please do not add comments to this bug report.  If you have a problem with the IIS documentation, see php bug #25863

The same problem was also noticed on Windows Server 2003 machine with IIS 6.0, php version 4.3.6, and mysql 3.2x.xx, faulting php application is moodle (www.sourceforge.net). The "CGI application misbehaved" error appears randomly on pages that contain lots of mysql_query() and header( "location: " ).

Hi!

I have come to this error all the time and finally decided to do something and **SURPRISE** it worked!!

And I say it worked because I tried it before and didn't work at all.

The solution is to install PHP under IIS as an ISAPI module and not as a CGI processor.

I have Windows XP, IIS, MySQL, PHP 4.3.4 and is working great without this problem.

Also, follow the exact instructions as they appear in the install.txt file in the php directory.

bye.

Another clue about this weird bug is....

If you make undefined or bad system calls on a Windows box the app will throw this error.  For example, in moving a PHP app from a *nix environment to a Windows2003 Server env. the following line of code WILL cause the "CGI Heart attack" to occur:

system("rm /usr/local/apache/sessions/$THIS_SESSID");

That dog won't hunt on an NT machine and causes this error to occur.  Remove the line (or rewrite it to use the proper NT syntax) and the error goes away.

This has occured in my applications that use PHP 4.3.6
with a MS SQL server backend.
Using Windows 2000 Server.

Hi All i have a windows 2003 sErver running IIS 6, I had the same problem with the cgi timeout, resolved by 
Downloading the IIS 6 resource kit. 
http://download.microsoft.com/download/7/8/2/782c25d3-0f90-
4619-ba36-f0d8f351d398/iis60rkt.exe  
With the IIS Metabase Explorer, go to the Server name,  Expand 
LM,  Go to W3SVC.   Find event CGI Timeout and change the 
default from 300 secs to whatever you need and it works

We have experienced similar probs here, except with Windows 2000 Server, CGI, and using MS SQL Server 2000.

I have a theory: 
The DB function calls are a red herring.
It's the redirection that's the problem.
IIS is telling the truth.
The location isn't valid.

Basis: 
Switched to FireFox, started getting messages about the location not being found (where usually I'd get the CGI error).  Looked at the code I use for redirection:
header("Location: http://" . $_SERVER['HTTP_HOST'] . dirname($_SERVER['PHP_SELF']) . "nextpage.php");
Found that dirname function was returning a "\" not a "/".
Rewrote this as:
header("Location: http://" . $_SERVER['HTTP_HOST'] . str_replace("\\","/",dirname($_SERVER['PHP_SELF'])) . "nextpage.php");

No. More. Probs. (as yet :-))
Needs testing on other setups, go ahead :-).

Damn.  Comment above isn't solution.  1 app appears to be okay , but another is still having problems.  The \ is not the cause.

The situation that I consistently see this bug in is:

  header("Location: http://site/");

The error does not occur every time.  To me, this does suggest a timing issue.  One piece of pertinent information is that the error is occurring on the page redirected to, and not on the page doing the redirection, as you can see from the following log entries.  Steps taken to generate this were: Open web browser to default page (index.php), click on link to home.php - which detects that I am not logged in and redirects to login.php (which then fails with error 502).

2004-10-15 23:37:39 192.168.20.9 GET /index.php - 80 - 192.168.20.11 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+.NET+CLR+1.1.4322) 200 0 0
2004-10-15 23:37:41 192.168.20.9 GET /home.php - 80 - 192.168.20.11 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+.NET+CLR+1.1.4322) 302 0 0
2004-10-15 23:37:41 192.168.20.9 GET /login.php - 80 - 192.168.20.11 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+.NET+CLR+1.1.4322) 502 2 0

It's a real pain - IIS doesn't give any detail in its logs about the error, there are no eventlog entries, etc., and running it through Zend Server Debugger shows no issues in the headers that I can see.

This is basically the code I am using to redirect:

    header("Location: http://" . $_SERVER['HTTP_HOST'] . 
       str_replace("\\", "/", 
       dirname($_SERVER['PHP_SELF'])) . $page);
    exit;

We've spent an extensive amount of time investigating this and have found a work-around for the PHP CGI error in the header("Location: <url>") redirect case.  In our experience, this was only encountered on Windows 2003 Server and IIS 6, however it seems others have experienced similar problems elsehwere.

First some observations:
1. As reported in bug #9852, changing the performance options fixes the problem on slower hardware.  With faster hardware, this had no effect.  Hence, it must be some kind of race condition.  (to change this setting r-click on My Computer -> Advanced -> Performance -> Advanced and select Background Services)

2. If the php cgi did an odbc connection, the problem occurs.  Without the odbc connection, no problem.

3. If the php cgi wastes some time in a busy loop prior to issuing the header() redirect, it works.  For us, doing for($i=0; $i<1000000; $i++) did the trick.  Issuing a sleep() did not work.  Strange, but again, seems to indicate a race condition in IIS.

4. One of the previous posts mentioned that re-directing to the IP address instead of the domain worked.  This was the primary clue to the solution.

Our solution:
The web browser will use the same TCP connection to send a subsequent request if it receives a Location: redirect for the same domain.  In observation #4 above, it works because the re-direct is issued to an IP address which causes the browser to think the redirect is to a different system and close the existing TCP connection and make a new connection.  It seems that IIS has a problem if (a) the initial CGI execution occurs very quickly and (b) a subsequent HTTP request is received over the same socket as the first request.  So the work-around is to force the browser to close the TCP connection and open a new connection when a redirect occurs.  This can be done by issuing a "Connection: close" header in addition to the "Location: redirect" header.  The following has solved the problem for us:

header("Connection: close");
header("Location: $url");

Hopefully some day Microsoft will fix this...

Hi all!

Actually, all you need to do is specify a MIME type.  Put this line at the top of your code, and voila!

http://bugs.php.net/bug.php?id=25863

Pretty simple really...   ;)

Whoops!

Here is the line to add:

print "Content-type: text/html\n\n";

I don't know if this has solved the intermittent problem I was experiencing with PHP 4.3.9/Server 2003/IIS6 on a dual processor system, but Microsoft have issued a hotfix for "Errors may occur when you run CGI applications on a fast multi-processor computer that is running IIS 5.0 and IIS 6.0". See Microsoft Knowledgebase article 884764.

It turns out, this is not a bug in PHP after all :)

http://support.microsoft.com/default.aspx?scid=kb;EN-US;884764

Thanks to php at bryans dot net for digging it up in their database.

I applied patch from Microsoft (http://support.microsoft.com/default.aspx?scid=kb;EN-US;884764) and it do not solved.

had that problem when I tried to debug pages to a local solve it by choosing manual setting in the Zend toolbar

I had this same issue; discovered the fault was a lack of permissions on the c:\windows\php.ini file.

i solved it be removing the php.ini file out of the sites root, i dont maintain 
the host but i was hoping that the admin could add user ini support so i uploaded 
it in anticipation, and this was apparently causing the CGI error.  check.  As 
the previous post mentions, check out the php.ini files.