Jump to content

php-cgi.exe and/or php5.dll crashing - PHP 5.2.17, Win2k8 & IIS7


slowfib

Recommended Posts

A specific part of my PHP script crashes randomly and I'm not sure why. The only difference on this page and the rest of the pages, is that I'm doing a PDO SQLSRV call. But 80% of the time there are no issues, and then suddenly IIS7 will just start spitting out the odd 500 error message. If I recycle the app pool, it works fine again for a while.

 

Here's the error from the NT log:

 

HTTP Error 500.0 - Internal Server Error

C:\PHP\php-cgi.exe - The FastCGI process exited unexpectedly

Detailed Error Information

Module  FastCgiModule

Notification    ExecuteRequestHandler

Handler PHP

Error Code  0x000000ff

Requested URL  {removed}

Physical Path  C:\inetpub\index.php

Logon Method    Anonymous

Logon User  Anonymous

 

 

I'm running PHP 5.2.17 non thread safe, on Windows 2008 64-bit with IIS7.

The IIS App pools is set to allow 32-bit applications, and as far as I can tell, FastCGI is configured properly in IIS and php.ini

 

Would really appreciate any suggestions people have. Thanks.

 

 

Windows also generated this crash report:

 

Version=1

EventType=APPCRASH

EventTime=129647371568690873

ReportType=2

Consent=1

ReportIdentifier=360d3929-058c-11e1-8a87-0050569801cd

IntegratorReportIdentifier=360d3928-058c-11e1-8a87-0050569801cd

WOW64=1

Response.type=4

Sig[0].Name=Application Name

Sig[0].Value=php-cgi.exe

Sig[1].Name=Application Version

Sig[1].Value=5.2.17.17

Sig[2].Name=Application Timestamp

Sig[2].Value=4d25fde8

Sig[3].Name=Fault Module Name

Sig[3].Value=php5.dll

Sig[4].Name=Fault Module Version

Sig[4].Value=5.2.17.17

Sig[5].Name=Fault Module Timestamp

Sig[5].Value=4d25fd3b

Sig[6].Name=Exception Code

Sig[6].Value=c0000005

Sig[7].Name=Exception Offset

Sig[7].Value=00009043

DynamicSig[1].Name=OS Version

DynamicSig[1].Value=6.1.7601.2.1.0.272.7

DynamicSig[2].Name=Locale ID

DynamicSig[2].Value=1033

DynamicSig[22].Name=Additional Information 1

DynamicSig[22].Value=0a9e

DynamicSig[23].Name=Additional Information 2

DynamicSig[23].Value=0a9e372d3b4ad19135b953a78882e789

DynamicSig[24].Name=Additional Information 3

DynamicSig[24].Value=0a9e

DynamicSig[25].Name=Additional Information 4

DynamicSig[25].Value=0a9e372d3b4ad19135b953a78882e789

UI[2]=C:\PHP\php-cgi.exe

UI[5]=Check online for a solution (recommended)

UI[6]=Check for a solution later (recommended)

UI[7]=Close

UI[8]=CGI // FastCGI stopped working and was closed

UI[9]=A problem caused the application to stop working correctly. Windows will notify you if a solution is available.

UI[10]=&Close

Loaded\Windows\SysWOW64\Kerberos.DLL

LoadedModule[60]=C:\Windows\system32\cryptdll.dll

LoadedModule[61]=C:\Windows\SysWOW64\msv1_0.DLL

LoadedModule[62]=C:\Windows\system32\ntdsapi.dll

LoadedModule[63]=C:\Windows\system32\LOGONCLI.DLL

LoadedModule[64]=C:\Windows\system32\security.dll

LoadedModule[65]=C:\Windows\SysWOW64\schannel.dll

LoadedModule[66]=C:\Windows\system32\mswsock.dll

LoadedModule[67]=C:\Windows\System32\wshtcpip.dll

LoadedModule[68]=C:\Windows\system32\ncrypt.dll

LoadedModule[69]=C:\Windows\System32\wship6.dll

LoadedModule[70]=C:\Windows\system32\DNSAPI.dll

LoadedModule[71]=C:\Program Files (x86)\Bonjour\mdnsNSP.dll

LoadedModule[72]=C:\Windows\system32\Iphlpapi.DLL

LoadedModule[73]=C:\Windows\system32\WINNSI.DLL

LoadedModule[74]=C:\Windows\system32\rasadhlp.dll

LoadedModule[75]=C:\Windows\System32\fwpuclnt.dll

FriendlyEventName=Stopped working

ConsentKey=APPCRASH

AppName=CGI // FastCGI

AppPath=C:\PHP\php-cgi.exe

Link to comment
Share on other sites

php causing a crash under windows is usually due to having files of mismatched versions or type (non-thead safe v.s. thread safe) of php and it's .dll files. Did you get all the .dll files out of the same php package?

 

About the only other things that come to mind would be to search the php bug reports and examine the php change log, starting at the next higher version number, to see if there has been anything fixed that seems related to your error.

Link to comment
Share on other sites

Thanks for the Reply PFMaBiSmAd.

 

Everything is from the same package I downloaded from windows.php.net/download, and I'm using the Microsoft Drivers for PHP for SQL Server for PHP 5.2.

If it's a mismatch, shouldn't it crash every time?

I would suspect that the issue is either with the MS SQL Server driver or the MS PDO SQL Server driver, but have no idea how to tell this.

 

I was using the thread safe version and having the same issue and one thing I read in to is that I should be using the non-thread safe version, so I've switch to that, but the issue remained even after I changed.

 

I'm considering upgrading to PHP 5.3, but I know I'm going to have to upgrade some classes along the way to do it, so I've held off for now.

 

Would I be crazy if I set the IIS App pool to recycle every 2 hours? An App Pool recycle always fixes the issue for another 3-4 hours.

 

Link to comment
Share on other sites

A mismatch in file versions/types will only cause a crash when a specific portion of the the code is accessed (the crash should be repeatable.) You could also be up against a memory leak, where it takes a number of iterations/amount of data before the crash occurs.

 

I'm not sure why you would need to change any code in order to use php5.3. There are very few incompatible changes moving up in php versions and most code will work as is. You don't need to use any 'new' syntax or features and you could ignore depreciated things until you have a chance to actually update any out of date code -

 

Most improvements in PHP 5.3.x have no impact on existing code. There are a few incompatibilities and new features that should be considered, and code should be tested before switching PHP versions in production environments.

 

 

Link to comment
Share on other sites

Also, in case there are any php detected errors leading up to the problem, make sure that error_reporting is set to E_ALL (or even better a -1) and log_errors is set to ON and confirm that errors actually get logged by referencing a nonexistent variable in a test script to see if you get an undefined variable message in the log file.

Link to comment
Share on other sites

I didn't want to move to 5.3 because one of the Classes I'm using has a Deprecated function in it:

Assigning the return value of new by reference is now deprecated.

 

But I bit the bullet, migrated and updated the Class, unfortunately, the issue still remains.

 

I also tried to upgrade the "MS SQLSRV Drivers For PHP" from 2.0 to 3.0, but no matter what I tried, I couldn't get the PDO driver to load, so I had to rollback to 2.0. phpinfo() would always show "no value" under PDO. While other drivers (mysql, sqlite) would load just fine.

 

display_errors is on

display_startup_errors is off

log_erros is on

error_reporting is E_ALL

errro_log is commented out. Correct me if i'm wrong, but if I enable this, I will only get back error 500s, no?

 

A memory issue honestly sounds like the most likely cause here, but I'm not sure how to even troubleshoot that? Do you have any suggestions on how to deal with this?

report_memleaks is on if that helps?

Watching Task Manager when the issue happened, I could definitely see that php-cgi.exe *32 crash.

I'm also running Windows 2008 64-bit, though I don't think that makes any difference?

 

I'm thinking I might try to not use PDO and use the straight sqlsrv functions, though I'm not sure if that makes any difference?

 

I really appreciate your help so far PFMaBiSmAd. Thank you!

Link to comment
Share on other sites

Last week I replaced my PDO code to use just the sqlsrv functions, and since then I haven't seen a single crash of php-cgi.exe or any errors being recored in the NT logs.

 

So it looks like that is what finally resolved the issue, though I have no idea why.

 

I'll update again if this reoccurs. Hopefully this might be useful info for someone one day.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.