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…
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.
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
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.
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)?
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.
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…
@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?
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
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…