HTTP 500 - PHP Access Violation on IIS w/ISAPI

[VodkaFish]

I was recycling every hour and/or 10000 requests I think. It did help extend the time in between crashes, but it didn't prevent them.

The only thing that seems definite is almost everyone was stable on 4.4.1. Somewhere in between there and 4.4.4, something got screwy.

[Dabbler]

I was recycling every hour and/or 10000 requests I think. It did help extend the time in between crashes, but it didn't prevent them.

So why not recycle every 30 minutes? Or 20?

[M33]

I had problems with this on my server (Win Server 2003 Web Edition). I just uninstalled IIS and installed Apache.
Apache rules!

[Ichneumon]

I just wanted to update. I've gone back to 4.4.1 for the moment because that is the last fully stable version I've been able to run on my server. I had 4.4.4 running better after changing the config of the system as I mentioned earlier in this thread, but it still would occasionally just bomb out.

Its a bummer because I just got the php cache running well too.

[mk132]

I want to report that I had a heavy traffic day and Apache2 survived the test. I'm not ready to recommend that you all move over to Apache just yet, but if things stay stable for the next week, then I would recommend it.

Strangely, Apache (2.0.59) crashes on me much more than IIS. It was crashing 4 times per hour when the server was under peak load, BUT Apache would restart immediately. The server might take a few seconds to crash, but once it crashed, it started a new process the very same second. In checking the logs, I saw on one occasion a 13-second delay between the last request before the crash and the first request after the crash. While not ideal, it is much better than me running to restart the server manually. Maybe with some more experience with Apache, I'll figure out how to stop the crashes, too.

If anybody wants to try this, here is my setup:
- PHP 4.4.4
- Apache 2.0.59 (I had tried 2.2.3 a couple of weeks ago and got the same errors and crashes as IIS.)
- Set Apache service to restart on 1st, 2nd and subsequent failures, and to wait 0 minutes before restarting.
- Till today, no APC or eAccelerator. I'm trying APC for Tuesday.

If you just want to test it (you can run it on port 8080 while IIS controls port 80), PM me and I'll send you the config that I'm using and a few more instructions to make it easy on you. Even if you don't use it, you will get plenty of ammunition to fight back against the "Apache rules!" crowd.

[Dabbler]

mk132,
Thanks for the update!

I want to report that I had a heavy traffic day and Apache2 survived the test. I'm not ready to recommend that you all move over to Apache just yet, but if things stay stable for the next week, then I would recommend it.

My initial concern is the unusual combination. It can be tough finding good supporting documentation for PHP/MySQL on WinServer/IIS. I imagine it is tougher still for a WinServer/Apache combination.

Strangely, Apache (2.0.59) crashes on me much more than IIS. It was crashing 4 times per hour when the server was under peak load, BUT Apache would restart immediately.

Any indication if "in process" transaction data is retained or lost? E.g., a submitted post.

Any indication yet what is causing the crashes? Is this a case where Apache is recovering faster than IIS from the same memory overflow?

[mk132]

Hi Dabbler,

It can be tough finding good supporting documentation for PHP/MySQL on WinServer/IIS. I imagine it is tougher still for a WinServer/Apache combination.

Actually, I think PHP is much closer to Apache and that there is more information on the Internet about it. There is even a nice forum dedicated to Apache on Windows and it seems to handle many PHP (WAMP) questions.

Any indication if "in process" transaction data is retained or lost? E.g., a submitted post.

Not yet. I have heard nothing from the forum members yet. These days they are accustomed to hitting F5 to resubmit their posts if something happens.

Any indication yet what is causing the crashes? Is this a case where Apache is recovering faster than IIS from the same memory overflow?

Half the Apache crashes come with this memory allocation error:
FATAL: erealloc(): Unable to allocate 1441792 bytes

Yes, Apache recovers faster, but it is different. IIS seems to never recover for me at times. It shows all users "access violation" or "PHP stack overflow" forever until *I* log in and restart the server. Apache2 seems to be catching PHP's errors first, and restarting on its own.

I have even better news (at least for myself) today. After enabling APC last night, Apache has only crashed twice and is breezing through my busy period right now. My experience with APC on IIS was not good (white pages), but it seems to have lessened the load on Apache and lessened the crashes. Knock on wood.

I thought of something else: if anybody listening has a desire to really troubleshoot IIS/PHP for everyone's benefit, an IIS/ISAPI developer wrote a How-To in his blog about tracking down Access Violations.

[Dabbler]

Looking through more bug reports at php.net, trying to connect some dots.

There is an unconfirmed(?) report (see bug 38190) that the problem is fixed in the 5.2.0 CVS {Sep 6}.
However, there are subsequent reports (bugs 38744 & 39163) that the problem is still there if using later 5.2.0 snaps.

Additional Related Bugs:

Invalid API call from php5isapi.dll causing IIS7 Application Pool failure

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

PHP 5.1.6 on Windows Vista RC 1 Build 56 (IIS7)

CVS 5.2.0RC6-dev dated Oct 16 2006 still has problem


PHP5TS.DLL causes w3svc crash and application pool termination

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

PHP 5.1.2 was OK.
PHP 5.1.6 crashes

CVS 5.2.0-dev dated Sep 13 2006 still has problem


IIS worker process crash on recycle/shutdown (with cause)

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

"Fix" is compiling in new xml libraries.

Claim by php.net on 6 Sep 2006:
"Fixed in the CVS. Will be included in upcoming 5.2.0 release
and should appear on snaps.php.net in a few hours."

However, the "fix" is a bit iffy.
Only one outside report that it works.


PHP crashes IIS worker process and application pool

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

Reports that #35612 claims it is fixed (but 35612 silent on "fix")

PHP 5.1.4 on WinServer 2k3 IIS 6
Problem in php5ts.dll

no other useful info


worker process shutdown

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

WinServer 2K3 IIS6
PHP 5.1.2 was OK.
PHP 5.1.6 crashes
no other info


PHP5TS.DLL causes w3svc crash and application pool termination

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

PHP 5.1.2 was OK.
PHP 5.1.3 crashes
PHP 5.1.4 crashes

PHP 5.0.5 OK??
PHP 5.0.4 crashes
PHP 5.0.3 OK

CVS 5.2.0-dev dated May 28 2006 still has problem
CVS 5.2.0-dev dated Jun 19 2006 still has problem

[Dabbler]

Based on the above, I think I'll give PHP 5.1.2 a shot.

If that doesn't pan out, I'll probably try fast-cgi next.

[Dabbler]

Since PHP 5.1.3 appears to be the 5.x ver where the isapi problems were introduced, I looked at the changelog for PHP 5.1.3 and it is huge.

http://www.php.net/ChangeLog-5.php

I see over 100 bug fixes and close to 75 additional changes and feature additions.

Phew! It looks like the php devs got a bit carried away.

[Dabbler]

8 hours since switching to 5.1.2 and so far so good.

[Dabbler]

I now have over 150 hour with this PHP downgrade.

The multiple daily fatal crashes requiring a manual restart of IIS (or some other web-related service) are gone. <<yea!>>

There are still some problems with PHP though. About once per day there is a problem that shows up in the event logs.

In the System Event log, I see:

A process serving application pool 'DefaultAppPool' suffered a fatal communication error with the World Wide Web Publishing Service. The process id was '4292'. The data field contains the error number.

And at exactly the same time, in the Application Event log, there is:

Faulting application w3wp.exe, version 6.0.3790.1830, faulting module php5isapi.dll, version 5.1.2.2, fault address 0x00002447.

There is no corresponding activity in the separate PHP error log.

The system does recover automatically in just under a minute. There have been no reported problems for users so far.

So all in all, this "solution" has been largely successful.

[neal007]

I've been using Windows 2003 and IIS6 for quite some time, never a problem such as this, except for one small period of time after which I enabled PHP error logging, saw the issue, corrected it. Running PHP 5.1.6, vB 3.6.2.

The issue I had was PHP was trying to access a resource such as a /uploadtmp folder or some folder specified that I had missing. If you enable full PHP error logging, it may unveil your issue, just a thought.

[Eagle Creek]

PHP 5.2.0 Released

[02-Nov-2006] The PHP development team is proud to announce the immediate release of PHP 5.2.0. This release is a major improvement in the 5.X series, which includes a large number of new features, bug fixes and security enhancements.
All users of PHP, especially those using earlier PHP 5 releases are advised to upgrade to this release as soon as possible. This release also obsoletes the 5.1 branch of PHP.

Is UPGRADING worth to try?
BugFix;
Fixed bug #35612 (iis6 Access Violation crash). (Dmitry, alacn.uhahaa)

[Dabbler]

I've been using Windows 2003 and IIS6 for quite some time, never a problem such as this, except for one small period of time after which I enabled PHP error logging, saw the issue, corrected it. Running PHP 5.1.6, vB 3.6.2.

The issue I had was PHP was trying to access a resource such as a /uploadtmp folder or some folder specified that I had missing. If you enable full PHP error logging, it may unveil your issue, just a thought.

Had/have PHP error logging enabled. Never saw an error that might be ascribed to an incorrect folder permission. You wouldn't happen to still have the log entry for that, would you?