Topic: Apache 2.4.6.0 crash due to a problem in php5ts.dll 5.5.1.0

[AlicanC]

Here goes my first post on this forum:

I am trying to update our production software to the latest stuff:

- Windows Server 2008 Standard SP2 (All recommended updates applied.)
- Apache 2.4.6 (httpd-2.4.6-win32-VC11)
- PHP 5.5.1 (php-5.5.1-Win32-VC11-x86)
- MySQL 5.6.12 (mysql-5.6.12-win32)
- WordPress 3.5.2

I get these crashes time to time which leave this log behind:
Faulting application httpd.exe, version 2.4.6.0, time stamp 0x51e43a85, faulting module php5ts.dll, version 5.5.1.0, time stamp 0x51e83970, exception code 0xc0000005, fault offset 0x0000d7d4, process id 0x2ad0, application start time 0x01ce88d76857db55.
Click for details...

Fortunately, this crash doesn't make httpd go down. I guess this just crashes a child process and the process gets created again.
Unfortunately, there is nothing to see about this in any of the logs.

I've searched a lot and I couldn't find any solution. Is this something known? Does anyone know the solution? If not, how can I debug this issue myself? (I can't even file a bug report like this since I can't even reproduce it. It just happens randomly.)

Edit:

Just got another four. This time ntdll.dll joined the crash wagon and completely killed httpd.

Faulting application httpd.exe, version 2.4.6.0, time stamp 0x51e43a85, faulting module php5ts.dll, version 5.5.1.0, time stamp 0x51e83970, exception code 0xc0000005, fault offset 0x00040a77, process id 0x1734, application start time 0x01ce89c78eefcd3b.
Click for details...

Faulting application httpd.exe, version 2.4.6.0, time stamp 0x51e43a85, faulting module php5ts.dll, version 5.5.1.0, time stamp 0x51e83970, exception code 0xc0000005, fault offset 0x0000d7d4, process id 0x1bd8, application start time 0x01ce89ca4e1d88db.
Click for details...

Faulting application httpd.exe, version 2.4.6.0, time stamp 0x51e43a85, faulting module php5ts.dll, version 5.5.1.0, time stamp 0x51e83970, exception code 0xc0000005, fault offset 0x00040a77, process id 0x19e8, application start time 0x01ce89cab128e96b.
Click for details...

Faulting application httpd.exe, version 2.4.6.0, time stamp 0x51e43a85, faulting module ntdll.dll, version 6.0.6002.18541, time stamp 0x4ec3e39f, exception code 0xc0000420, fault offset 0x000abc4f, process id 0xeac, application start time 0x01ce89c78e6f79ab.
Click for details...

[James Blond]

That is due a faulty php extension. If you need all the enabled extensions in your php.ini you may use php over fcgid instead of using is as module.

I also recommend to use php error log to maybe figure out what causes the crash.

Here is a link how to use php over fcgid. http://www.apachelounge.com/viewtopic.php?t=2394


if you still have a question please ask again.

[Smitty]

These are the classic errors you will see when running PHP as an Apache module. We struggled with these errors for months. Switching to using PHP via mod_fcgid (as James recommends) will fix all of these problems. Be sure you have the latest Visual C++ Redistributable package installed:

http://support.microsoft.com/kb/2019667

Also, I recommend switching to the 64-bit version of MySQL. No real reason to run the 32-bit version anymore.

[AlicanC]

Thanks for all the replies. I was using the module because I read somewhere that it provided more performance. 5 crashes per minute is not great performance. I will switch to FCGI as you suggested.

Since our WordPress installation does everything it can to make creating a development copy harder, I will have to take down the production server midnight and work on it when no one's around.

I'll report the results when I'm done.

Also, Smitty, should I use 64-bit Apache and PHP? (I guess not, but I wanted to ask anyway.)

[James Blond]

I use apache 64 bit and PHP 32 bit cause I can do it over fcgid

[Jan-E]

PHP X86 is still faster than X64, but that may change over time when PHP X64 becomes less experimental.

[Smitty]

I recommend Apache 64-bit and PHP 5.5 32-bit. They don't have to match since you're using mod_fcgid. Do be sure to download the 64-bit version of mod_fcgid.

[AlicanC]

Things are working pretty fine at the moment.

I have two questions/problems:

1- Our uncached WordPress page loads are still slow. We moved from:
Apache 2.2.22, PHP 5.4.3, MySQL 5.5.24
to:
Apache 2.4.6 x64, PHP 5.5.1, MySQL 5.6.12 (Not x64 yet, too lazy )

Isn't it right to expect some performance improvements? We didn't have too much improvement if any.

2- Every 5 or 10 minutes, we get this in Event Viewer:

[Steffen]

In the mod_fcgid download here is a readme with the default to use config:

FcgidInitialEnv PHPRC "c:/php"
FcgidInitialEnv PATH "c:/php;C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem;"
FcgidInitialEnv SystemRoot "C:/Windows"
FcgidInitialEnv SystemDrive "C:"
FcgidInitialEnv TEMP "C:/WINDOWS/Temp"
FcgidInitialEnv TMP "C:/WINDOWS/Temp"
FcgidInitialEnv windir "C:/WINDOWS"
FcgidIOTimeout 64
FcgidConnectTimeout 16
FcgidMaxRequestsPerProcess 500

<Files ~ "\.php$>"
AddHandler fcgid-script .php
FcgidWrapper "c:/php/php-cgi.exe" .php
</Files>

FcgidMaxRequestsPerProcess: please read the Special PHP considerations under the heading Examples at : http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html

Steffen

[AlicanC]

Thanks. My "modules-2.4-win64-VC11.zip" didn't contain any information regarding that. I also set "MaxConnectionsPerChild" to "0" and it's been like 50 minutes since I got the last of that error message.

We will face the true test tomorrow though.

[AlicanC]

We didn't face to true test that tomorrow but today. We went up to 170 active visitors (Google Analytics) and the site worked fine. We couldn't get the full potential from our content before because the site started to crash and slow down when we go above 150 visitors. Now our only bottleneck is the quality of our content

Also no errors in Event Viewer since we moved to FCGI and made the proper configurations.

Sweet!

Thanks for all the help

[Smitty]

I'm happy to hear your system is more stable now. Good luck tomorrow.

[Jan-E]