IIS 7 and Above
PHP-CGI processes all hanging
Last post Nov 17, 2013 01:42 AM by gezginrocker
Aug 18, 2010 05:07 PM|blanco360|LINK
IIS 7.5 2008R2 Standard Edition x64
This same problem happened with me on IIS6 too, but I thought an upgrade would solve it ... I was wrong!
Running with the defaults, everything will be going great, just 4 or 5 PHP-CGI processes spawned, when suddenly, WHAM, another 20 or 30 will load up and all the websites become unresponsive. The PHP-CGI sessions themselves use no CPU, just loads of 0% activity.
After a while (around 6 minutes, this could be the time in my request timeout actually) - suddenly they will all spring into life! With the redundant ones closing down.
Whilst this is going on, an IIS Reset seems to be the only way to get it going again.
Nothing crashes and there is nothing in either the event log, nor the PHP error log file.
Obviously this is not good ;) So any suggestions on how I can troubleshoot this?
Aug 18, 2010 05:19 PM|blanco360|LINK
Ok watching it now, it always jumps to exactly 20 PHP-CGI processes...
Aug 18, 2010 05:23 PM|Bret Bentzinger|LINK
Did you use the web platform installer to install PHP? If not, I would use the web platform installer(WPI) to install it. The thing that comes to mind when you mention this is that the wrong version of PHP is installed. I believe fastcgi requires the
non-thread safe version. WPI takes care of this for you.
If you used WPI to install, then it might be necessary to find out what is going on inside w3wp.exe and php-cgi.exe. You could use a debugger to attach, and debug the processes to find out what is blocking.
Aug 20, 2010 04:24 PM|blanco360|LINK
No it's the NTS version, latest one 5.3.3.
It happened again today, unfortunatly this time I was unable to reset it for an hour, so the machine just stayed "crashed" for this time.
Back watching it now, and the same thing is happening, but server is staying up. 20 processes are spawned, only 5 of which actually do anything. Eventually they all clear...
I wouldn't know how to debug it :( But I can follow instructions!
Aug 20, 2010 04:46 PM|Bret Bentzinger|LINK
If you could get dumps of the w3wp.exe process and the php-cgi.exe processes we could find out what is blocking. You will need the Debugging Tools for Windows installed, and you can run the following commands:
cscript.exe adplus.vbs -quiet -hang -p <PID> -o C:\Directory
cscript.exe adplus.vbs -quiet -hang -pn php-cgi.exe -o C:\Directory
<PID> is the process ID of the W3WP.exe
C:\Directory is where you want the files to be saved to.
Then make the files available, and I could take a look when I have time.
Aug 20, 2010 09:19 PM|blanco360|LINK
Oh thank you so much.
So just to confirm, I run these before or during the problem?
It just happened again now, and by using task manager to close down the "stuck" ones (ie the ones that showed CPU time I left open) it all started working again.
Aug 20, 2010 09:31 PM|Bret Bentzinger|LINK
During the issue would be great.
Sep 01, 2010 09:06 PM|robertwojo|LINK
Sep 13, 2010 08:10 PM|blanco360|LINK
Not heard back from you for a while, I'm wondering if emails aren't getting through, as I didn't receive a reply from Don either who was working on the site. Still the crashing going on :(
Did you get the PHP.ini files I sent?
Sep 22, 2010 07:48 PM|Bret Bentzinger|LINK
FYI, Microsoft is planning an october release of php wincache, which should fix this issue.
Jan 16, 2012 07:53 PM|blanco360|LINK
Jan 16, 2012 10:52 PM|HCamper|LINK
In answer to your last question the following information:
If your having problems with
PHP report the Bugs https://bugs.php.net/ here.
You can contact Microsoft Support and open a case
the Experts help.
Jan 17, 2012 06:35 AM|blanco360|LINK
Jan 17, 2012 06:56 AM|HCamper|LINK
The solution is report the bug with the data to get this fixed.
https://bugs.php.net/ "PHP Bug Tracking System".
Jan 17, 2012 08:41 AM|ma_khan|LINK
Jan 17, 2012 10:40 AM|blanco360|LINK
Jan 28, 2012 07:56 AM|HCamper|LINK
Feb 01, 2012 03:40 PM|HCamper|LINK
Your using IIS 7.5 Windows Server 2008 R2 Standard Edition x64.
Personal: Suggestion have created a report for PHP related issues https://bugs.php.net/
Personal: Have you opened a support call with the Experts at
to get advise and information ?
Personal: I agree "Obviously this is not good ;) So any suggestions on how I can troubleshoot this?".
Personal: Can you add a suggestion for how to better help you in troubleshooting and fixing the issues ?
This posting is provided "AS IS" with no warranties, and confers no rights.
Sep 25, 2013 05:26 PM|planck|LINK
We have the EXACT same situation. Fast-cgi PHP processes just stop responding, no errors shown or logged in PHP or IIS.
We haven't been able to track down what's causing it.
IIS 7.0 with PHP 5.3 and Wincache.
Is there a development over this?
Oct 17, 2013 12:46 PM|planck|LINK
I have actually managed to solve my issue.
Never use a web garden with PHP on IIS! It will not speed up your website, it will only create problems. I use only 1 worker process now and the website served is generating about a few thousands requests per minute; didn't say any difference in speed, actually
its more responsive with one worker process, and much more stable.
Make sure "Maximum Worker Processes" in the application pool serving your website is set to 1. I also have 0 MaxInstances in FastCGI settings , queue length 1000 and Instance MaxRequests 9999.
I haven't have a single hang since i switched.
This helped alot: http://blogs.iis.net/chrisad/archive/2006/07/14/1342059.aspx
Nov 17, 2013 01:42 AM|gezginrocker|LINK
I am experiencing this problem as well on a Windows 2008 R2 server. PHP, Fastcgi, Wincache & Wordpres all installed via Web Platform Installer.
Wordpress site is really fast & stable at the beginningi and this goes for about 15-20 hours.
But when I wake up the next morning I see that site has become unresponsive. When I enter the site address at the browser, it tries to load the site forever, but there are no error messages.
So I need to restart the site & application pool to return everything back to normal.
I've checked IIS & system logs but there's not a clue.This is really so annoying.
EDIT: Changing Max. Instances to 40 at FastCGI settings solved my problem. Running for weeks and not a single hangout since then.