im also having this problem

Hi,

I'm running Mercury 4.7.4 on XP32 with MercuryS, MercuryE, and MercuryI.  I'm having repeated crashing that seems to surround the MercuryI module, even when only one system is logged in, but especially if more than one device is trying to access an account.  The performance is also very slow for some reason.  I've disabled SSL, and pretty much every possible feature.  No virus scanner is running, Defraggler (a disk defragmenter) is running nightly (the crashes happen during the day or night) but I've set it to exclude the entire Mercury folder from the defrag.  GrayWall and ClamWall are disabled, the DNS entries are valid, there are no errors on the disk, I've run mailbox maintenance/repair, cleared the scratch folder, cleared the sessions folder, I've tried deleting the mercury.mer file, and I've increased the time-outs.  I'm sure there are many other things I have also tried that I'm forgetting, but nothing has stopped the crashing.  I'm not running stunnel, btw (I've seen that question asked previously.)  At this point, I would really be open to beta-testing v4.8, since I have nothing to lose.  If you can provide me with a download link, and/or an idea of what else I might be able to try, that would be great.  Some examples of the errors I receive are:

mercury.exe: The instruction at "0x021b2af1" referenced memory at "0x033ae224". The memory could not be "read".

mercury.exe: The instruction at "0x021aa7a7" referenced memory at "0x000000cc". The memory could not be "read".

mercury.exe: The exception unknown software exception (0xc0000027) occurred in the application at location 0x7c80df3c.

mercury.exe: The instruction at "0x021aa7a7" referenced memory at "0x000001a8". The memory could not be "read".

The above errors tend to happen when imap is being accessed.

Mercury also has sufficient (full) privileges to its folder, I'm running it directly from mercury.exe rather than the loader, and very often, when one system is accessing an imap account, another system won't be able to access the same account at all.  A lot of timeouts / abnormal connection terminations are happening.  The network hardware is in excellent shape, and this has happened with several different switches.  No other applications seem to be having any network trouble at all.

Sounds like a memory error. Please test your RAM with Prime95 or Orthos Multiprime.

All tests pass successfully.  I also have ECC-enabled RAM.  No other programs are crashing either.

About 7/10 of connections to Mercury are terminating abnormally.  I tried reverting to the default, basic mercury.ini, but no improvement.

Did you at all try the 4.80 beta that I emailed you about a few days ago?

I'd love to, but I didn't receive it.  Please send again.  Thanks!

Actually, never mind.  I checked my spam folder and it went there.  I'll give it a try.  Thanks again!!!

I've downloaded the files, but when I run m32-480.exe I receive a "WinZip Self-Extractor" error: "Error 0 running command .\setup.exe"

It looks like it was trying to run the setup from my temp folder instead of from my download folder, and a policy restriction was in place banning exe's from running from %temp%.  I was able to manually extract the contents with 7zip, and then ran the setup.exe directly.  I'll let you know how it goes.

That was interesting.  It seemed to be running fine, but suddenly it just instantly closed with no error message -- nothing in the event log either.  I started it again, connected a client to the imap server, and so far 2/4 connections have ended abnormally.

It crashed again, so I've disabled the MercuryI module, and I'll see how Mercury runs without it.

In case it reveals any greater detail about something going wrong, I've loaded Mercury.exe with IDA.  So far it revealed a few exceptions that didn't otherwise display:

mercury.exe: 0x7C812FD3: unknown exception code 406D1388 (0x7C812FD3)
mercury.exe: The instruction at 0x0 referenced memory at 0x0. The memory could not be written (0x00000000 -> 00000000)
mercury.exe: The instruction at 0x0 referenced memory at 0x0. The memory could not be written (0x00000000 -> 00000000)
mercury.exe: 0x7C812FD3: unknown exception code 406D1388 (0x7C812FD3)

I can give you the full IDA debugger log if you think it will help.

Do you have M$ DEP enabled?

Yes.  Would that cause the crash?  I'm assuming Mercury should be able to run without violating DEP.

Has anyone here had better luck, stability-wise, with any older versions of Mercury?  In particular, I'm interested in the stability of the MercuryI, MercuryS and MercuryE modules.  I'm on XP32.

Thanks in advance,

Tim

[quote]statistics since 6/9/2014 6:06 PM[/quote]

XP32 with Mercury modules S, C, D and I. The modules C and D communicate via stunnel to my ISP. The Mercury version is 4.7.4.

Thanks for the info and for the ideas.

I *may* have found a possible contributing factor to the crashing, but it's not at all definitive.  I discovered that XAMPP was referencing a junction point (to a folder,) created with the linkd.exe Windows Resource Kit tool (or "mklink /J ..." with later versions of windows).  The junction point ("D:\XAMPP\MercuryMail") actually pointed to a second junction, "C:\Mercury", which then pointed to my real "D:\Mercury" folder.  I thought I had done away with all such junctions except for the one in C, which I haven't been using.  For a lot of the time while struggling with this issue, I've been loading Mercury.exe directly from a command prompt, rather than through XAMPP or the loader, but now I wonder if somehow XAMPP was still causing problems (in combination with the junction points) through it's initial load in Windows.

My wild guess is that Mercury is using different functions in different situations to read path names of files and modules, with some methods retrieving the actual physical file location, while others retrieve the junction path name.  As a result, perhaps there could be some kind of conflict in either path name buffer lengths or (more likely) in file locking.  The system could think it's imposing a file lock in one location, for example, but could be concurrently accessing a file through a different path and not seeing the lock.  Again, these are just wild guesses, but since I found and stopped using the junctions and have more completely avoided the XAMPP interface for loading Mercury, I haven't had any crashing.  It's only been 14 hours though.  I opted not to disable DEP, since the errors aren't reported as DEP violations, and I don't think I should have to disable it.  I'll post any updates later.  Fingers crossed...

... One addition in case it helps Rolf.  I have seen similar crashing one time before with the Bitcoin client when using a junction to relocate the data directory instead of using the Bitcoin client's built-in method for setting the data location.  Perhaps this is a more wide-spread problem involving file-locking (or something else) in combination with junction points.  However, these are the only two programs for which I've witnessed possible junction point issues, and it's still not certain whether it truly is an issue with Mercury.)  I thought I'd throw the idea out there though, in case it helps.

34 hours and no crash yet.  I may have been on to something.

I may have spoken too soon...  It seemed to be stable, but then I enabled SSL on MercuryI and now it's crashing about twice a day.  Nothing special is running, the system has 4GB of ECC RAM and dual Opteron 250 processors, on XP32 Pro.  Maybe there's just something odd with my system...  Everything else is so solid...  When it crashes, it just closes without displaying any error message.  There's nothing in the event log or mercury logs either, but there are some new '.dmp' files, so I'll email those to Rolf and David.  I may try running Mercury.exe with IDA again to see if that reveals a clue.  I'm running out of hope though.

Did you disable M$ DEP?

 Do you see a change after pausing or shutdown the Defraggler tool?