|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #25863 IIS: The specified CGI application misbehaved
Submitted: 2003-10-14 08:44 UTC Modified: 2005-01-21 15:26 UTC
Avg. Score:4.6 ± 0.9
Reproduced:41 of 42 (97.6%)
Same Version:25 (61.0%)
Same OS:34 (82.9%)
From: salmanarshad2000 at yahoo dot com Assigned:
Status: Not a bug Package: CGI/CLI related
PHP Version: 4CVS, 5CVS, 6CVS.. OS: win32 only
Private report: No CVE-ID: None
 [2003-10-14 08:44 UTC] salmanarshad2000 at yahoo dot com
This bug or issue has been around for quite a while and seems like nobody cares. The bug list is filled with hundreds of complains about the "The specified CGI application misbehaved ..." error each time these people have BOGUSed or CLOSEd saying things like "The version you are using is too old, please try the latest version ...", "This is not a php bug, please go to ...", "Not enough evidence ..." or "Problem with Windows, not PHP". Quite a few versions of php have been released in the meanwhile, but this issue hasn't been fixed, people who upgrade their php installation come back with the same complains. I see no good reason for this ignorance.

Problem Statement
When browsing a php application, the IIS server randomly throws the error message:

CGI Error
The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are:

This happened only when:
- PHP.exe is used as a CGI on IIS 
- The php scripts contained 2 or more frames (e.g. phpMyAdmin)
- MySQL operation was executed (update, insert, delete etc.)
- header("Location: ...") is used to redirect user after a MySQL operation to a page that also performs a MySQL operation
- The pages are viewed from local computer
- A very fast computer is used

This did not happened when:
- Apache server for windows with php support was used
- The php scripts contained 2 or more frames but all frames contained php scripts with Hello World and a random number
- Frequency of errors was much lesser when same pages were accessed from the network
- Pentium 2, 300 MHz was used (a slow computer)

Following bugs are all related to this problem. This is just a reminder for the fact that this issue has been discussed quite a few times and it is still present. People also found these interesting things that might help to get the problem solved.

- BugID #25567 getting errors when doing a mysql_db_query() and then header("location")
- BugID #24916 header("location")
- BugID #23208 using two or more frames
- BugID #19381 no details :(
- BugID #19676 works on one (slow) system but does not work on other
- BugID #18901 header("location") after delete or update, error occurs under under load
- BugID #16313 header("location") and db operations
- BugID #23050 mysql_query() followed by header("location")
- BugID #17468 header("location")
- BugID #9852  thousands of lines describing the problem, including frames, manually slowing down the script, pages work from outside the machine nut not locally, two database connections in rapid succession etc

Things that have been said earlier
"This is a problem with Microsoft OS"
No this is not, it works on exact same OS running on slower hardware or when the application is accessed across a network. And even if it is, the developers should try to find a work around instead of blaming M$ and telling it to fix it. After all, when you develop some app for an environment, you don't change the environment to suit your app (although sometimes it is easier to do so).

"This is not a php bug"
Well this could be right, since there is one other suspect, MySQL. But somebody please figure out where the problem is? Also, MySQL is now an integral part of php so problem could lie in the integration part.

My Opinion
May be php.exe is not fast enough to keep up with the pace at which IIS can throw requests at it. Or ... may be it is a problem with the MySQL connections ... attempting to create connections too quickly may be the cause. Users having same problem please feel free to contribute with their observations and suggestions.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2003-12-12 16:46 UTC] nigel dot salt at hotmail dot com
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

 [2004-01-27 07:06 UTC] salmanarshad2000 at yahoo dot com
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.
 [2004-04-23 08:39 UTC] steve at xcvr dot com
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.
 [2004-04-27 16:15 UTC] david dot blair at nsi1 dot com
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 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.
 [2004-04-27 18:32 UTC] david dot blair at nsi1 dot com
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 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...
 [2004-04-28 07:19 UTC] salmanarshad2000 at yahoo dot com
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.
 [2004-04-28 18:19 UTC] david dot blair at nsi1 dot com
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 fault)
 [2004-05-08 20:20 UTC] dmeeking at shaw dot ca
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).
 [2004-05-26 15:36 UTC] onderoz at zmail dot sk
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.

 [2004-06-23 18:38 UTC] tincanmann at hotmail dot com
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).

 [2004-06-29 12:03 UTC] closedbolt at gmx dot de
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.


 <? echo "hi"; ?>

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

 [2004-09-08 10:06 UTC] roger dot gusthage at home dot se
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.
 [2004-09-08 16:41 UTC]
People, please do not add comments to this bug report.  If you have a problem with the IIS documentation, see php bug #25863
 [2004-09-08 20:37 UTC] salmanarshad2000 at yahoo dot com
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 ( The "CGI application misbehaved" error appears randomly on pages that contain lots of mysql_query() and header( "location: " ).
 [2004-09-11 16:53 UTC] moricio at hotmail dot com

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.

 [2004-09-27 18:49 UTC] jvanhoy at archermalmo dot com
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.
 [2004-09-30 22:52 UTC] mlisondra at lisondra dot biz
This has occured in my applications that use PHP 4.3.6
with a MS SQL server backend.
Using Windows 2000 Server.
 [2004-10-05 00:13 UTC] true_weakness at hotmail dot com
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.
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
 [2004-10-14 07:49 UTC] winterpalace at netspace dot net dot au
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.

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 :-).
 [2004-10-14 08:25 UTC] winterpalace at netspace dot net dot au
Damn.  Comment above isn't solution.  1 app appears to be okay , but another is still having problems.  The \ is not the cause.
 [2004-10-16 02:04 UTC] marc at durdin dot net
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 GET /index.php - 80 - 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 GET /home.php - 80 - 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 GET /login.php - 80 - 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);
 [2004-11-04 04:12 UTC] mmyer at rightnowtech dot com
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...
 [2004-11-09 14:36 UTC] dan at hostway dot nl
Hi all!

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

Pretty simple really...   ;)
 [2004-11-09 14:37 UTC] dan at flowofchi dot nl

Here is the line to add:

print "Content-type: text/html\n\n";
 [2004-11-24 13:59 UTC] php at bryans dot net
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.
 [2004-11-24 15:35 UTC]
It turns out, this is not a bug in PHP after all :);EN-US;884764

Thanks to php at bryans dot net for digging it up in their database.
 [2005-01-21 15:26 UTC]
I applied patch from Microsoft (;EN-US;884764) and it do not solved.
 [2010-06-29 17:09 UTC] rodoprogramador at hotmail dot com
had that problem when I tried to debug pages to a local solve it by choosing manual setting in the Zend toolbar
 [2010-08-11 02:12 UTC] allan at eq dot edu dot au
I had this same issue; discovered the fault was a lack of permissions on the c:\windows\php.ini file.
 [2011-09-16 06:20 UTC] me at wolfdogg dot org
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.
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Sat Sep 24 23:05:52 2022 UTC