lol i had the same Problem probing 2 hours to fix this Problem :D http://community.pmail.com/forums/thread/46400.aspx

i had no delivery file tamplate in the config so it always crashed but now we are happy :) 

This post follows on from the thread I started related to window sizing for some configuration windows.  Having apparently solved that issue, my Mercury server is now non-functional.  The issue is that, as soon as Mercury starts, I get a BEX (Buffer overflow exception error).  The only options available are to close Mercury or search for a solution (and none found).  This error occurs consistently every time Mercury starts, so I cannot use it.

It seems that BEX errors arise because of the built-in Data Execution Protection (DEP) feature of Windows 7 (64-bit).   With the 64-bit version of Win7, it is possible to selectively exclude programs from DEP.  I added the Mercury Loader to the exclusion list but the DEP management system wouldn't let me exclude mercury.exe.

I have tried a System Restore back to 20 June and restoration was successful, but that didn't cure the BEX problem.

I can't think of anything else other than to reinstall Mercury.  Any other suggestions would be most welcome.

Gordon

In case it is useful information, the following are the error problem details:

Problem signature:
  Problem Event Name: BEX
  Application Name: mercury.exe
  Application Version: 4.8.0.149
  Application Timestamp: 55d1ef44
  Fault Module Name: mercury.exe
  Fault Module Version: 4.8.0.149
  Fault Module Timestamp: 55d1ef44
  Exception Offset: 001d6512
  Exception Code: c0000417
  Exception Data: 00000000
  OS Version: 6.1.7601.2.1.0.768.3
  Locale ID: 4105
  Additional Information 1: 0144
  Additional Information 2: 0144d9298f77a7abfd8d147f88653a49
  Additional Information 3: a8c8
  Additional Information 4: a8c824dede43350c299989fbcc46ec20 

FWIW, two instances of Mercury are running on a Win7/64 machine here.  The enabled DEP option is the "essential Windows programs and services only" one.  Mercury is installed in C:\Mercury and C:\Mercury_E.  This PC does very little other than run Mercury and access online banking.

Wish I had something of substance to offer but I have nothing at the moment.

I just shared your problem with a co-worker who is more IT worldly than me and he commented that he has seen non-Windows fonts cause some really strange problems when used as system fonts.  Consider resetting the appearance settings to the defaults which is the "Windows 7" theme in the Aero section of Personalize.

Thanks again. The Aero theme was set to the default setting. I changed it and then switched it back to default and still no success.

I have also turned DEP off completely and still get the error.  Most of the information that I have found in various places connects BEX errors with the DEP setting but this doesn't seem to be the case here.

Gordon

So far (only 15 mins!), I now have Mercury 4.8 back up and running with no errors.

I tried a number of things .... turned off Windows Firewall, stopped initiation of my antivirus, started with a Clean Boot, all without success.

Each day I automatically save a copy of the complete Mercury folder and an image of the system disk,.to a separate drive.  I also have a copy of my previous Mercury (4.74) installation on this backup drive.  So, I copied the 4.74 Mercury backup onto the system disk and ran its mercury.exe.  It seemed to work without any errors.

Given the success with 4.74, I decided to re-install 4.80 on top of the existing 4.80.  I wasn't sure that I could do this, as I wasn't upgrading to a new version.  There were no complaints from Mercury about this not being an upgrade and the new install finished successfully.  On starting the new 4.80 everything seemed to start normally with no BEX errors.

So, I don't know what happened,  Maybe something became corrupted in the previous copy of 4.80.  The disk where the Mercury folder exists is monitored for its health and it is reporting 100% good, so I don't think that the disk is starting to fail.

Anyway, I am pleased to be back up and running again and will monitor the situation.

I don't know whether it is anything to do with what happened, but a folder has appears in the root of the system disk named BAD-16-06-24.1243.  It is an empty folder but it seems to be suspiciously named with the date and time when Mercury started to fail.

Thank to all who tried to help me!

Gordon 

Well, Mercury ran fine for a couple of days but now the BEX errors have returned and Mercury is unusable.  Whether this is some problem with Mercury or some more underlying problem on the server machine, I do not know.  I am somewhat at a loss to know what next to try other than to reinstall Mercury and hope that it functions for a few days.  Just in case, though I find it herd to believe that this is anything to do with malware, I have scanned the server with Malwarebytes and I am in the middle of a full system anti-virus scan.

I wonder if anyone has seen these BEX errors before with Mercury.

Gordon

Mercury should in my experience run fine with DEP set to "enabled for essentials Windows programs and services only". Traditionally most crash problems originate with over-ambitious AV software, but it's advisable to check for RAM errors and disk errors as well. You haven't mentioned running Mercury in a virtual machine so I assume that is not the case. If you have any daemons active verify it's a current version.

Thanks Rolf. DEP is set to "enabled for essentials Windows programs and services only" (level 2), although it had been set to AlwaysOn for some strange reason   However, with DEP at level 2, I am still getting a BEX error as soon as Mercury starts.  I am wondering whether Mercury is calling something in the system, which has been corrupted.

I will also run MemTest and run a disk check.

No, I am not running in a VM.

I am not sure about daemons.  I have done so in the past.  I'll have to remind myself how to check for this. 

Thank you

Gordon

The daemons that are bundled with Mercury can be updated from the Mercury installer, for other daemons it's probably best to check with the programmer what the current version is.

I don't think I am running any daemons, from what I recall.

I have checked the RAM and it passes MemTest.

There are two drives on the server machine; the system drive and one that I use for backups.  Both are Seagates.  The system drive passed the short SeaTools test with no problems but the backup drive showed a failure.   Also, the Windows CheckDisk utility hung when testing the backup drive.  I can't see what the backup drive has to do with the repetitive BEX errors from Mercury, as it is not involved in running Mercury.

For the time being, I will reinstall Mercury again and see what happens.

Gordon 

Rolf.  It occurs to me that, shortly before I started to get BEX errors, I made a change to Mercury.  I had asked in an earlier thread how to prevent automatic replies being made to spammers.  You suggested removing the Delivery confirmation and Delivery failure template file names from the Mercury core configuration.  I am wondering whether, if no filenames are found there during message processing, this could cause a problem.  As a result of this speculation, I have hard-coded one of my own e-mail addresses in place of the ~T variable for both template files.

I did a Windows System Restore to a date prior to when the BEX problem stated and Mercury has now been running without problem for almost 24 hours.

Any thoughts about this .... I realize that no confirmation or failure messages will be sent to bona fide message originators as a result of this.

Thank you

Gordon

Apparently Mercury really wants there to be a path to a failure notification file. It's OK to rename the file itself though (to failure.mer.x or something). Then there will be no crash and no notification. (I'll edit the post in the other thread accordingly.)

No more crashes now that template file names are in place, so I am hopeful that I've seen the last of BEX errors.

Gordon