Since it appears that you have isolated the issue to a  queue phenomenon, try running each module manually (note that you may have to press the poll button twice sometimes for it to complete its rounds). Before taking the turn from MercuryD to the Mercury-core, copy the queue files to another location. If the server crashes on every occasion when you poll the core with the queue in place, initiate Thomas or someone else on the beta team here for duplication of your error.

Searching through the forums I found the following thread (http://community.pmail.com/forums/thread/3702.aspx) pertaining to Mercury Mail crashing after upgrading to 4.51. I have been experiencing this same issue after upgrading to 4.52. I uninstalled and also ran the testing below with an old 4.51 version and got the same results. I am running Mercury S, P, E and D on my system. I have also installed Graywall.

Here is what I have Mercury running on:
HP dx5150 AMD processor
Windows 2003 Enterprise Server SP2
Trend Micro Officescan
Diskeeper 10

My initial thought before checking the forum (great addition to the site btw) was that there was something preventing Mercury.exe from running. I only mention the hardware above because the processor supports Data Execution Prevention (DEP). I tried adding exclusions for Mercury but to no avail. I eventually turned it off all together in the boot.ini. Still crashing.  I thought Trend was interfering so I set both the executables and the directory to be excluded from all scan types. No dice. The only other service which I know of that could potentially be locking the disk and preventing read/write access is Diskeeper which I disabled. No luck. I checked the forums and discovered that clearing the queue will resolve the issue temporarily. I went back and repeated those tests each time moving the offending files, restarting Mercury assuring it was up and working, dumping the bad mail back again, restarting and watching for it to fail.
I recently enabled Graywall and thought it may be the issue so I disabled it. I had also changed around the Connection Controls to be set to Only Authenticated SMTP Connections May Relay Mail. I played with the various options there (sorry to whoever got spam when I turned myself into an open relay). Same result. Well finally I found one item which seems to be causing the issue: when Mercury D grabs the mail from a 3rd party and places it in queue, the whole app crashes when it attempts to deliver it to the local user. I have tested this several times using both 4.51 and 4.52 and both have the same issue.  I'm happy to provide you with the 3rd party pop server name, but it doesn't seem appropriate in a public forum.  Using them with other pop clients (Outlook and Opera M2) I have not run into any problems.

Any help or suggestions as to what I can do to fix this will be greatly appreciated.  

Paul

P.S. To David and Team:  I look forward to the licensing getting up and running at the end of the month, buying manuals didn't seem like proper repayment for such a great program.

Here are some things to test:

- Turn on session logging in MercuryD and see if there is anything written to the log file before the crash.

- Check the disk for broken sectors.

- Disable the anti-virus software altogether.

- Verify that there is just one instance of Mercury running.

- If it's a dual core processor make sure Mercury is bound to one of the processors.

/Rolf 

[quote user="Rolf Lindby"]

- If it's a dual core processor make sure Mercury is bound to one of the processors.