I migrate from version 4.80 on March 19. (Windows Server 2012 R2). No problems occurred during and after the migration.
For one week I get the following error message in the System log :
The Mercury32 service terminated unexpectedy. It has done this 1 time(s). The following corrective action will be taken in 60000 milliseconds: Restart the service.
The Mercury32 service is restarted either directly by the system or by the Zabbix monitoring system.
The problem is that each time Mercury32 is restarted, a new instance of the clamd.exe process is created and each instance takes 1 Gb of memory.
The only information I can find in the log is the Windows Event ID (7031). Does somebody know where I can find some more information to track the problem ?.
Many thanks for your help

Hi PHR,
The problem is that not Mercury service is being terminated by OS but only the GUI at the desktop. I know this problem since years. Read my old post in this regard:

Mercury running as a service

Cheers
Joerg

Hello Joerg,

Thanks for your message.
I run Mercury/32 only as a service without any GUI on the server desktop.

The explanation for EventID 7031 is as follows :
Event ID 7031 gets logged when a service crashes. The Service Control Manager logs this event when a service stops unexpectedly. The message says which service failed, how many times it failed and the corrective action that will be taken.
The diagnostic is confirmed by the Zabbix monitoring system that detected that Mercury32 service has stopped.

The problem for me is to find WHY the Mercury32 service crashed to give some troubleshooting informations to David Harris.

Regards,
Philippe

Apart from entries in Mercury log files at the time of a crash there might have been error dump files created. Please check for files with the .DMP extension in the main Mercury directory or in the DUMPS subdirectory. If there are any, please zip and email to <<address removed>> with a reference to this topic.

@Rolf Lindby : Many thanks for your information ...
No .DMP files in the Mercury main folder and in the dumps subfolder.
Waiting for the next crash ...

@Rolf Lindby
Hello Rolf,
Mercury/32 crashed again last night. I found in the Mercury folder the file deadlock.job.log with 3 entries corresponding to the dates and times of the crashes. As requested I sent this file to <<address removed>> with a reference to this topic.
Best regards,
Philippe

Hi Philippe,
any news from Rolf regarding your issue after providing him with your logs?

Hi @Joerg

David Harris proposed the following :

The solution in the first case is to exclude the Mercury queue directory
from your anti-virus system's real-time scanner (you can use the Clam-AV
antivirus plugin supplied with Mercury instead, because Mercury interacts
with it predictably, meaning the timeouts won't happen).

ClamAV was already active through the ClamWall interface. So I excluded the Mercury queue directory from the Kasperaky Endpoint Security real-time scanner. For the time being everything runs fine ...

Hi Philippe,
Yes, I know the oddities in connection with A/V scanners. But at our server, where Mercury resides, no A/V scanner is activated, also no ClamAV with Mercury. The A/V scan will be carried out 1. at ISP Mail Server and 2. at the Client machines, where finally the mails will be opened and attachments processed.
In past, when we used a separate A/V scanner at our client machines, Pmail often became freezed or slowly, so that we excluded the local mailboxes of our users from scanning. This helped.
In the meantime we are using MS Defender which comes with Windows10 and have no excludes in place. And all is working fine.

Hi. Is this problem fixed in 4.91? We had to switch back to 4.80 at that time because the error described here kept occurring with 4.90 even though no AV scanner or other blocking software is installed.

On our Windows Server 2016 Edition I've updated our Mercury to 4.91 two weeks ago. Only SpamHalter is still in place but no ClamWall or any other 3rd party A/V scanner.
Our Mercury is always getting started by an OS Service. But this service is only in place to guarantee a Mercury start when the OS has unexpectedly rebootet. Normally after an OS reboot I shutdown the Mercury service followed by a manual Mercury restart to get the GUI permanently presented on desktop screen. Email is our most important communication tool and I have to regularly check the GUI for proper function. This is more convenient for us than regularly checking the different logs of the Core system, SMTP server, SMTP client, IMAP server and POP3 client. On the GUI I see the normal function of each part at a quick glance.
Insofar I'm not able to tell you something about the stability of the Mercury Windows Service. But the manually started Mercury works fine and reliable without any problems so far.