php fastcgi crash

Hello all !

Since we upgrade to php 7.1 our SuiteCRM keeps crashing from php CGI.

Our stack:

Operating System: Windows Server 2012 R2
WEB Server : IIS 8
Databse: MariaDB 10.1
PHP: 7.1.7

Does anyone know if this is a known bug or how to solve this?

I never heard of this, but then SuiteCRM is probably not very heavily tested on that combination (Windows + PHP 7.1).

Do you have any messages in the logs? If by “crash” you mean WSOD (white screen of death, blank screens in the app), those should be PHP Fatal errors and a message should come up in the Web server log…

On SuiteCRM logs nothing appears…

I’m trying to replicate the crash to join mor inflormation, but no nor WSOD ou any thing tha crash the machine. The crash I’m talking about isHTTP 500

No, not suitecrm.log… if it was Apache, I would look in php_errors.log. It’s the web server log, to get PHP errors.

I don’t know what the equivalent is for IIS. I would say it’s likely in Event Viewer.

This was the generated error for HTTP 500

Problem signature:
Problem Event Name: APPCRASH
Application Name: php-cgi.exe
Application Version: 7.1.7.0
Application Timestamp: 595e6e27
Fault Module Name: php_wincache.dll
Fault Module Version: 2.0.0.8
Fault Module Timestamp: 582a0182
Exception Code: c0000005
Exception Offset: 00010785
OS Version: 6.0.6002.2.2.0.272.7
Locale ID: 2070
Additional Information 1: eb23
Additional Information 2: 7df959767520cf13474da9cb27a9bcb0
Additional Information 3: 84a7
Additional Information 4: 02840bd0cfd0282b173bf291aace256c

That’s the executable crashing, it looks like a PHP bug, or a caching bug…

What I was hoping to find was a PHP error mentioning some file and line in SuiteCRM that we could examine for PHP 7.1 compatibility.

But with this, I don’t know what to do… maybe you can try Googling to see if it’s happening to other people?

your installation is quite similar to mine exept that I am using M$ sql
is your wincache the 64 bit version or 32 bits, as you know both are available
i run the 64 bits with almost no issue.
I get this when my server is under heavy use (during workday) and if i try to do a quick repair, it may took several times to get through.

Hello bmwtourer,

MariaDB is based on MySQL.

We are using a 32 bit version of PHP (supose 32bit version of Wincache) but they are both installed.

you might consider moving to php 64 bits (version 7 support this) and wincache 64 bits as well
this should enable better memory management which could cause your problem…

i am using my dev machine (Win10,iis, etc) to expose my point…
php 7.1 is located in C:\Program Files\PHP\v7.1
php 5.6 is located in C:\Program Files (x86)\PHP\v5.6 this is a php limited to 32 bits anyway

7.1 is available in both 32 and 64 bits.

for SuiteCRM we migrated a few months ago noticed quite a performance gain from 5.6

what is your session.gc_maxlifetime and memory_limit in php.ini?

mine are session.gc_maxlifetime = 1440
memory_limit = 256M

Hello all,

Our valuyes are:
session.gc_maxlifetime = 1440
memory_limit = 128M

We have change the PHP version for 7.1

you might try to bump up the memory limit if your system permits…

Hello bmwtourer,

We have increased the memory but it stills crash once in a time. But in fact at the time I cannot tell you how frequently it is crashing because I had to change a bit the focus of work. As soon as I get back to the GUI I’ll tell you if I still get problems.

Hello,

After a lot researching I still got this HTTP 500 error which is starting to put my project in question.

It apear’s ti is somthing related to the database connection or the requeste between IIS and PHP

Here is IIS log

Nombre de la aplicación con errores: php-cgi.exe, versión: 7.1.7.0, marca de tiempo: 0x595e6ac5
Nombre del módulo con errores: php_wincache.dll, versión: 2.0.0.8, marca de tiempo: 0x582a01d6
Código de excepción: 0xc0000005
Desplazamiento de errores: 0x0000000000012a8b
Identificador del proceso con errores: 0x594
Hora de inicio de la aplicación con errores: 0x01d414767f7a75a6
Ruta de acceso de la aplicación con errores: C:\Program Files\PHP\v7.1\php-cgi.exe
Ruta de acceso del módulo con errores: C:\Program Files\PHP\v7.1\ext\php_wincache.dll
Identificador del informe: c09cd89a-806b-11e8-80c5-00155df82411
Nombre completo del paquete con errores:
Identificador de aplicación relativa del paquete con errores:

Does anyone got this issue?
Can anyone tell me how is there is a tool which I can see the PHP/IIS tunning (like MySQL Tuner for MySQL databases)?

Thanks a lot,

Hi again.

Apache works well on Windows, don’t you want to consider switching?

If you really need to debug your issue, then I suggest using the tools from SysInternals which you can download from the Microsoft site.

Specifically, Process Monitor will let you attach to a process (php-cgi.exe) and check the calls it’s making into the OS, and their results. So you will probably find a Registry call or a file system call that is getting access denied (0x00000005), but you will have the exact path so you can try to fix it.

Good luck

more info please… when does this occurs?
did you recycle memory application pools, it helps … before I do " Quick Repair and Rebuild" I always recycle the memory pool first, 90% of the time the QRR runs fine after I recycled the momory
are your using a dedicated memory application pool for suitecrm (i do)

if you have access to a 64 bits instance, I would try it on the 64 bit platform, remember php7 can run 64 bits…

Hello all,

Thanks for your help.

@pgr
Although switch to apache starts to be an option, at this moment it is a bit complex once the 1st phase of the solution as already been delivered. I this change will imply modifications on things already implemented, like WEB Services.
I think changing to apache will be as the last resource.

I will check with SysInternals and i’ll let you know.

@bmwtourer
We already use 64bits version os PHP 7.1

I think this occurs every time the the CRM has to process information with database (like queries with lots of records, single inserts/updates, QRR)
If by recycling memory you are referring to the IIS reclining yes, it is enable, but it still with its default value (1740 minute seems to me a lot of time. Which is the best value?)

I do not know if the pool as dedicated memory, IIS has the default settings. I can I confirm and/or update it?

Regards

I recycle every 720 minutes (12 hours)

Hello,

These were the only access denied records that I found in with process monitor at the HTTP 500 error time slot (attach 2). Unfortunatly I do not understand much about this. Can any one help me to know if these is normal or if (and why) I am missing something.

I had also attached the IIS recycle settings (attach 1) to illustrate my answer to @bmwtourer

Regards

hello create a user, make it a member of IIS_USRS, no expiring password (!) and run the app pool with that user…
I would definetely reduce the recycle period…