slowfib Posted November 3, 2011 Share Posted November 3, 2011 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 Quote Link to comment Share on other sites More sharing options...
PFMaBiSmAd Posted November 3, 2011 Share Posted November 3, 2011 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. Quote Link to comment Share on other sites More sharing options...
slowfib Posted November 3, 2011 Author Share Posted November 3, 2011 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. Quote Link to comment Share on other sites More sharing options...
PFMaBiSmAd Posted November 4, 2011 Share Posted November 4, 2011 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. Quote Link to comment Share on other sites More sharing options...
PFMaBiSmAd Posted November 4, 2011 Share Posted November 4, 2011 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. Quote Link to comment Share on other sites More sharing options...
slowfib Posted November 4, 2011 Author Share Posted November 4, 2011 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! Quote Link to comment Share on other sites More sharing options...
slowfib Posted November 10, 2011 Author Share Posted November 10, 2011 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.