HTTP 500 - PHP Access Violation on IIS w/ISAPI

[Dabbler]

Been struggling with a continuing issue of "crashes" on a new server.

Environment
OS: WinServer 2K3 SP1 (+ all updates)
Web: IIS 6
MySQL: 5.0.24
PHP: 5.1.6 as ISAPI
vB: 3.6.0

Issue appears to be a PHP bug, even though it may manifest itself as an IIS Services or Windows worker process problem.

Here are a series of apparently related bugs from PHP.net with a "best" recommendation for fixing (also summmarized below).

Faulting application w3wp.exe
http://bugs.php.net/bug.php?id=37575
BEST: downgrade to PHP 5.1.1

PHP5TS.DLL causes w3svc crash and application pool termination
http://bugs.php.net/bug.php?id=37483
BEST: Remove php5isapi.dll from IISAPI filters
(but leave dll in the .php mapping in the "application settings" Configuration).
BEST: Downgrade to PHP 5.0.3 solves problem

Worker process crashes after application pool recycle
http://bugs.php.net/bug.php?id=36853
BEST: DEP needs to be restarted clean so an IIS restart is not enough (masks problem only??)
BEST: Even with all PHP dynamic extensions turned off, crash occurs during IISreset or w3svc service restart.
BEST: back level server to .NET 1.0

Crash during IIS Restart
http://bugs.php.net/bug.php?id=35263
no useful info

IIS worker Process continually restarts
http://bugs.php.net/bug.php?id=33373
no useful info


OPTIONS:
The following were gleened as recommendations that others claimed to work. I have not tested any of these. I post them only as a guide for others.

1 - Move over to fast-cgi
2 - Downgrade to PHP 5.1.1
3 - Downgrade to PHP 5.0.3
4 - Downgrade to PHP 4.4.4
5 - Downgrade server to .NET 1.0

Also, there is no official PHP solution. Their public statement:
"We are aware of PHP's problems with stability under IIS and are working to rectify the problem."

[VodkaFish]

Thanks for putting this post together. I have the same environment as you do and during my own search I also found there seems to be no "real" answer.

My current options:
- Downgrade to 5.1.1
- Move to cgi - everyone mentions fast-cgi, but I only see things posted about it and PHP 4, do you know if it's fine with PHP 5?

One random thought: I was reading that gd2 isn't really thread safe and I know we both use it. I was going to try installing imagemagick to see if that had any effect on the crashes. Have you come across anything like this?

[Dabbler]

Move to cgi - everyone mentions fast-cgi, but I only see things posted about it and PHP 4, do you know if it's fine with PHP 5?

No experience. We used fast-cgi maybe 2 years ago on a much slower box and kept running into performance/load issues. Switching to isapi was a significant improvement so I've never looked back.

One random thought: I was reading that gd2 isn't really thread safe and I know we both use it. I was going to try installing imagemagick to see if that had any effect on the crashes. Have you come across anything like this?

No experience. I'd guess that disabling all of vB's gd2-related options and running that way for awhile would be a reasonable test. However, one php.net bug report post stated even with no extensions, there were still problem. See the last post of:

Worker process crashes after application pool recycle
http://bugs.php.net/bug.php?id=36853

[Dabbler]

I should note that I've tried all the simple config-related "fixes" and have not found any that help.

So at this stage I'm probably looking at a sw layer downgrade.

The switch to fast-cgi would probably not work well because of a largish database (1.8 million posts) and moderate visitor activity (250-500 visitors/members in any 15 minute window) unless someone knows otherwise.

Oh, and I suppose that switching to Linux is a viable solution as well.

[VodkaFish]

If I was more experienced with *nix servers, I have to admit I'd be tempted right now.

So what flavor of downgrade are you looking at?

[Dabbler]

PHP 4.4.4

The downgrades to the 5.0.x and 5.1.x flavors all seemed a little squirrelly to me. Plus you may be introducing new problems by abandoning fixes found in the current versions of 5.0 and 5.1.

[Ichneumon]

How many IIS6 worker processes are you running?

I had a stable 4.4.1 isapi php setup on the IIS6 server running my board for ages. However, I couldn't upgrade to anything newer than 4.4.1 without regular crashes of the IIS worker process (w3wp.exe), and regular php access violation errors .

In my case the solution was to switch back to using a single worker process. I'd been using 2 worker processes for years without issue. For I'm sure some esoteric thread safety/memory contention reason, switching to a single w3wp process made this problem go away and I was able to upgrade to 4.4.4 and it is running swimmingly again

[Dabbler]

Thanks for that information. I had been running an older vB 3 with PHP4 for a couple years and never had a problem. Had to upgrade to a new server and figured I would try PHP 5 as it was "recommended" by the jelsoft folks.

How did you set the number of worker processes?

[Ichneumon]

Open the IIS manager
Under your web server find Application Pools. Unless you've changed something you're using the DefaultAppPool. right-click on DefaultAppPool and click properties. You can change all kinds of goodies there, but the worker processes is on the Performance tab. The help file explains the individual items on the tabs fairly well.

[Dabbler]

There are 2 app pools.

One is the Default App Pool. It contains 3 Default Applications.
The only active one is just for the one web site that is active.
The other two Default Applications are for 2 web sites that are "stopped."
The max number of worker processes is 1.

The second App Pool is for MS SharePoint.
This box has an inactive instance of MSSQL Server installed.
Anyway, this 2nd app pool is "stopped."

[eva2000]

downgrade to PHP 4.4.4 would be my choice

[VodkaFish]

I downgraded to PHP 4.4.4 late last night.

As opposed to before, when I logged into my server, there were no errors popping up. I thought it worked until a few hours later I got slammed with one of these:
PHP has encountered an Access Violation at 7C8224B2

[mk132]

I'm running into the same problems. For the longest time (about a year), I had it under control by setting a time to recycle the worker process every day. You might want to try that.
(DefaultAppPool Properties>Recycle Worker Processes at the Following Times)

Lately the problem has gotten much worse and that old fix has stopped working for me. I am going to try two things:
1. Apache2
2. PHP 5.2.0 when it comes out (any day now). It supposedly gets around this vB bug, so it might help in other cases like it.

(I consider the "Access Violation" and "Stack Overflow" problems to be basically the same. The first happens to me on PHP 4.4.4 and the second on 4.4.2.)

[Dabbler]

I downgraded to PHP 4.4.4 late last night.

As opposed to before, when I logged into my server, there were no errors popping up. I thought it worked until a few hours later I got slammed with one of these:
PHP has encountered an Access Violation at 7C8224B2

Oh poo!
I had so hoped it would resolve things.

[Dabbler]

mk132, thanks so much for your comments!

I'm running into the same problems. For the longest time (about a year), I had it under control by setting a time to recycle the worker process every day. You might want to try that.
(DefaultAppPool Properties>Recycle Worker Processes at the Following Times)
Lately the problem has gotten much worse and that old fix has stopped working for me.

Hmmm. Any downside to just bumping the frequency of the recycle triggers? How about every 10 minutes?

I am going to try two things:
1. Apache2
2. PHP 5.2.0 when it comes out (any day now). It supposedly gets around this vB bug, so it might help in other cases like it.

(I consider the "Access Violation" and "Stack Overflow" problems to be basically the same. The first happens to me on PHP 4.4.4 and the second on 4.4.2.)

While I would love for 5.2.0 to fix things, the apparent inability of the php users/developers to produce a viable backtrace suggests that a fix would be mere happenstance.

Please keep us updated with your progress.