Community Discussions and Support
4.51 crashed? PLEASE Help!

[quote user="Thomas R. Stephenson"]

I many times have WinPMail, Thunderbird, OE and Eudora all looking at the same account at the same time using IMAP4 without problems.  All see the same new mail and folders.  There is a problem with deleting since Mercury/32 does not allow deleting when there is concurrent access but I see no other problem. 

I have all sort of problems with Outlook 2002 and IMAP4 , many times it simply crashes when trying to do IMAP4, but right now I have Outlook 2002, Thunderbid, OE, WinPmail all looking at the same account al all see the same new mail.  No problems at all.  Mercury/32 v4.52 running on a HP Workstation.

[/quote]

 

Yes, you are right. That is exactly the way I think it should work. In fact, it was, prior to 4.52. Oh well, I can try Tbird for a while to see if it grows on me. It may give me the feeling I am on one of my Linux boxes. And any time I get to spend away from MS is good.  Thanks for your input.
 

 

[quote user="Thomas R. Stephenson"]<p>I many times have WinPMail, Thunderbird, OE and Eudora all looking at the same account at the same time using IMAP4 without problems.  All see the same new mail and folders.  There is a problem with deleting since Mercury/32 does not allow deleting when there is concurrent access but I see no other problem.  </p><p>I have all sort of problems with Outlook 2002 and IMAP4 , many times it simply crashes when trying to do IMAP4, but right now I have Outlook 2002, Thunderbid, OE, WinPmail all looking at the same account al all see the same new mail.  No problems at all.  Mercury/32 v4.52 running on a HP Workstation.</p><p>[/quote]</p><p> </p><p>Yes, you are right. That is exactly the way I think it should work. In fact, it was, prior to 4.52. Oh well, I can try Tbird for a while to see if it grows on me. It may give me the feeling I am on one of my Linux boxes. And any time I get to spend away from MS is good.  Thanks for your input.  </p><p> </p>

Mercury 4.51 crashed last night for no apparent reason. I'm running under Windows XP, using NT wrapper, and the Event log reads:

PID:720 Terminated *not by NTWR C:\MERCURY\mercury.exe ExitCode:-1073741819

The PID I understand; NTWR means NT wrapper but I've no idea about the exit code.

I've been running Mercury 4.01 for a couple of years without problems, but upgraded the previous day to 4.51 - maybe that has nothing to do with it. Unless it happens again I'm not going to worry about it, but I'm posting this on the general principle that any unusual behaviour following an upgrade might be of interest to the community.

 Chris

<p>Mercury 4.51 crashed last night for no apparent reason. I'm running under Windows XP, using NT wrapper, and the Event log reads: </p><blockquote>PID:720 Terminated *not by NTWR C:\MERCURY\mercury.exe ExitCode:-1073741819</blockquote><p>The PID I understand; NTWR means NT wrapper but I've no idea about the exit code. </p><p>I've been running Mercury 4.01 for a couple of years without problems, but upgraded the previous day to 4.51 - maybe that has nothing to do with it. Unless it happens again I'm not going to worry about it, but I'm posting this on the general principle that any unusual behaviour following an upgrade might be of interest to the community.</p><p> Chris</p>

V4.51 is easily the most stable and tested version of Mercury there has ever been, but I don't rule out the possibility that there may still be some situations we haven't anticipated. If you see a crash frequently, please try to narrow down the circumstances in which it occurs (perhaps a particular message or type of message is being processed, perhaps a particular error condition has just been reported or whatever). Without some guide as to where to look, it is almost impossible for me to track down problems these days - crash dumps give me no information at all, and unless I can find some way of reproducing the problem here, it's highly unlikely that a solution can be found.

Cheers!

-- David --

V4.51 is easily the most stable and tested version of Mercury there has ever been, but I don't rule out the possibility that there may still be some situations we haven't anticipated. If you see a crash frequently, please try to narrow down the circumstances in which it occurs (perhaps a particular message or type of message is being processed, perhaps a particular error condition has just been reported or whatever). Without some guide as to where to look, it is almost impossible for me to track down problems these days - crash dumps give me no information at all, and unless I can find some way of reproducing the problem here, it's highly unlikely that a solution can be found. Cheers! -- David --

Me Too!!!!   I was doing just fine with the previous version but I just upgraded to 4.51 two days ago and now Mecury 32 Crashes every 5 minutes on its own. It gives me that send to Microsoft crap. The only thing I can see of relevance is something about the core module in mercury.exe.

I'll do anything, send you logs, crash dumps, anything but please Help!!!
Windows XP SP2 all patches and updates applied. 100% legal machine.

 

<p><b>Me Too!!!!</b>   I was doing just fine with the previous version but I just upgraded to 4.51 two days ago and now Mecury 32 Crashes every 5 minutes on its own. It gives me that send to Microsoft crap. The only thing I can see of relevance is something about the core module in mercury.exe.</p><p>I'll do anything, send you logs, crash dumps, anything but please Help!!! Windows XP SP2 all patches and updates applied. 100% legal machine.</p><p> </p>

First clear all queues.

Then turn on all session logs. Examine to see if a specific message is cause.

If not, proceed to see if a specific connection is cause.

If not, look at file / running processes to see if there is a conflict of access, either file based or memory.

<P>First clear all queues.</P> <P>Then turn on all session logs. Examine to see if a specific message is cause.</P> <P>If not, proceed to see if a specific connection is cause.</P> <P>If not, look at file / running processes to see if there is a conflict of access, either file based or memory.</P>

Thanks! I'll try that. So far I told norton to ignore the Mercury directory and I cleared 14,957 pop logs. I also disabled the authenticate via SSL pop before retrieving thing.

I have to go back today and see how is doing.

Will clearing the queue delete my messages?

thanks again. 

<p>Thanks! I'll try that. So far I told norton to ignore the Mercury directory and I cleared 14,957 pop logs. I also disabled the authenticate via SSL pop before retrieving thing.</p><p>I have to go back today and see how is doing.</p><p>Will clearing the queue delete my messages?</p><p>thanks again. </p>

Well, I tried what you suggested. 4 folders starting with the word BAD on them on the queue so I deleted everything out of that and started fresh with a new queue. I really though that was it but unfortunately it wasn't.  Mercury keeps crashing a couple times a day. There is nothing in the logs other than regular module processing. No errors are logged.

I also looked at the processes. Nothing denoting a problem there either.

Any other suggestions? 

<p>Well, I tried what you suggested. 4 folders starting with the word BAD on them on the queue so I deleted everything out of that and started fresh with a new queue. I really though that was it but unfortunately it wasn't.  Mercury keeps crashing a couple times a day. There is nothing in the logs other than regular module processing. No errors are logged.</p><p>I also looked at the processes. Nothing denoting a problem there either.</p><p>Any other suggestions? </p>

The only time I've seen Mercury crash is when the disk it runs on has bad sectors. Access conflicts with an anti-virus program could perhaps have the same effect. Make sure the disk is error free and test disabling the anti-virus software altogether.

Do you have any daemons or other help programs for Mercury running? 

/Rolf

 

<p>The only time I've seen Mercury crash is when the disk it runs on has bad sectors. Access conflicts with an anti-virus program could perhaps have the same effect. Make sure the disk is error free and test disabling the anti-virus software altogether.</p><p>Do you have any daemons or other help programs for Mercury running? </p><p>/Rolf </p><p> </p>

I have the plain Jane install of 4.51. I did not enabled any of the goodies. I do have Norton running but it is excluding all dirs related to Mecury.  I'll run a disk check with repair and a defrag, but I really think this is not the problem as 4.01 or what ever version I was on before ran flawless for over a year. Not a single problem  before the upgrade to 4.51.

I have the plain Jane install of 4.51. I did not enabled any of the goodies. I do have Norton running but it is excluding all dirs related to Mecury.  I'll run a disk check with repair and a defrag, but I really think this is not the problem as 4.01 or what ever version I was on before ran flawless for over a year. Not a single problem  before the upgrade to 4.51.

Just found these in one of the logs: Any Ideas?[:S]
 

07-08-03.2352: Restarted Mercury after apparent abnormal termination
07-08-03.2357: Restarted Mercury after apparent abnormal termination
07-08-03.2358: Too many abnormal terminations in time period - attempting recovery.
07-08-03.2358: No queue files to quarantine - no recovery performed.
07-08-03.2358: Recovery complete - attempting to restart Mercury.
07-08-04.0005: Restarted Mercury after apparent abnormal termination
07-08-04.0008: Normal operation restored - resetting counters.
07-08-04.0011: Restarted Mercury after apparent abnormal termination
07-08-04.0016: Restarted Mercury after apparent abnormal termination
07-08-04.0021: Restarted Mercury after apparent abnormal termination
07-08-04.0026: Restarted Mercury after apparent abnormal termination
07-08-04.0034: Restarted Mercury after apparent abnormal termination
07-08-04.0108: Normal operation restored - resetting counters.
07-08-06.0854: Restarted Mercury after apparent abnormal termination
07-08-06.0909: Normal operation restored - resetting counters.
 

This is just a bit. It goes on for miles.... 

<p>Just found these in one of the logs: Any Ideas?[:S]  </p><p>07-08-03.2352: Restarted Mercury after apparent abnormal termination 07-08-03.2357: Restarted Mercury after apparent abnormal termination 07-08-03.2358: Too many abnormal terminations in time period - attempting recovery. 07-08-03.2358: No queue files to quarantine - no recovery performed. 07-08-03.2358: Recovery complete - attempting to restart Mercury. 07-08-04.0005: Restarted Mercury after apparent abnormal termination 07-08-04.0008: Normal operation restored - resetting counters. 07-08-04.0011: Restarted Mercury after apparent abnormal termination 07-08-04.0016: Restarted Mercury after apparent abnormal termination 07-08-04.0021: Restarted Mercury after apparent abnormal termination 07-08-04.0026: Restarted Mercury after apparent abnormal termination 07-08-04.0034: Restarted Mercury after apparent abnormal termination 07-08-04.0108: Normal operation restored - resetting counters. 07-08-06.0854: Restarted Mercury after apparent abnormal termination 07-08-06.0909: Normal operation restored - resetting counters.  </p><p>This is just a bit. It goes on for miles.... </p>

That probably just means that Mercury has recognized that there has been a crash and attempted to clean up the queue directory, so it won't help us find the reason for the crash. We need to narrow it down to if it's hardware related or has to do with conflicting software. Is there maybe some entry in the event viewer logs in Windows that could have something to do with this?

As the purpose of anti-virus software is to intercept and scan different types of communication in a computer system it's a risk it might interfere even if the Mercury directory has been excluded from file scanning. I think it's at least worth trying to disable it for a while to see if that makes any difference.

/Rolf
 

<p>That probably just means that Mercury has recognized that there has been a crash and attempted to clean up the queue directory, so it won't help us find the reason for the crash. We need to narrow it down to if it's hardware related or has to do with conflicting software. Is there maybe some entry in the event viewer logs in Windows that could have something to do with this?</p><p>As the purpose of anti-virus software is to intercept and scan different types of communication in a computer system it's a risk it might interfere even if the Mercury directory has been excluded from file scanning. I think it's at least worth trying to disable it for a while to see if that makes any difference.</p><p>/Rolf  </p>

Honestly, I'd love to help you, but you'll *have* to give me more to

work with. I wasn't joking in my post above when I talked about

rigorously tested v4.5 has been; it runs here processing hundreds of

thousands of connections a day for weeks on end without ever crashing,

so it's not inherently unreliable.


Watch the system console windows for a while, until you see a crash. What windows are active when the crash occurs?

Like Rolf, my first instinct would be to disable anything running on the machine that might be interfering with Mercury - antivirus software is a key candidate. If you get crashes continuing even after you've disabled everything external that might interfere with the program, then try to narrow it down by disabling protocol modules one at a time until you work out which module is responsible for the problem. Once you've done that, enable only that module and see if you can work out what stimulus is causing the crash: is it a particular type of message? A connection from a particular host?

If we can narrow down what's causing the problem, and if it turns out that there's something I can fix, then I'll gladly fix it for you, but I'm going to need as much assistance as you can provide in order to find it.

Cheers!

-- David --

Honestly, I'd love to help you, but you'll *have* to give me more to work with. I wasn't joking in my post above when I talked about rigorously tested v4.5 has been; it runs here processing hundreds of thousands of connections a day for weeks on end without ever crashing, so it's not inherently unreliable. Watch the system console windows for a while, until you see a crash. What windows are active when the crash occurs? Like Rolf, my first instinct would be to disable anything running on the machine that might be interfering with Mercury - antivirus software is a key candidate. If you get crashes continuing even after you've disabled everything external that might interfere with the program, then try to narrow it down by disabling protocol modules one at a time until you work out which module is responsible for the problem. Once you've done that, enable only that module and see if you can work out what stimulus is causing the crash: is it a particular type of message? A connection from a particular host? If we can narrow down what's causing the problem, and if it turns out that there's something I can fix, then I'll gladly fix it for you, but I'm going to need as much assistance as you can provide in order to find it. Cheers! -- David --

Thank you both. I like M, and it is not my intention to bash it. As a developer or a few OS projects myself, I like to help figure this out. I am not saying is the software. What I am saying is that this box operated M 4.01 for over a year without any issues whatsoever in the current state. Even worst actually since I didn't even have Norton excluding anything.

No software or hardware has been changed in a very long time with the exception of this upgrade to 4.51. So you see, the process of elimination is a very fast one here.

None the less, I will comply, since once again, I want to help. I was also not kidding when I said, tell me what you need and I will supply it to you.

Yesterday I performed a very lengthy drive check and defrag on both drives. It shown nothing exiting. But, for the first time, I was able to presence the crash first hand, only it was not a crash but a restart though. The main window disappeared and another instance came up within seconds. No other app was running at the time. The only thing I could see generating any errors was the pop3 client. I did not write down verbatim but it was something to the effect of "Network Error: Delivering anyways" or something like that. Next few polls worked fine. Then another one of those, then some more good ones, so on and so forth until it restarts again. I don't know if there is a restart counter that tells how many times it gets to do that b4 it actually dies and Microsoft catches the exception with the "send it to them" dialog box.

I will, like I said, go back today and turn off Norton on that box, but I think you understand why I do not believe this is the problem. I will also look at the event logger but I think I already know what is going to say.  I'll report back the findings.

thanks again. 

<p>Thank you both. I like M, and it is not my intention to bash it. As a developer or a few OS projects myself, I like to help figure this out. I am not saying is the software. What I am saying is that this box operated M 4.01 for over a year without any issues whatsoever in the current state. Even worst actually since I didn't even have Norton excluding anything.</p><p>No software or hardware has been changed in a very long time with the exception of this upgrade to 4.51. So you see, the process of elimination is a very fast one here.</p><p>None the less, I will comply, since once again, I want to help. I was also not kidding when I said, tell me what you need and I will supply it to you.</p><p>Yesterday I performed a very lengthy drive check and defrag on both drives. It shown nothing exiting. But, for the first time, I was able to presence the crash first hand, only it was not a crash but a restart though. The main window disappeared and another instance came up within seconds. No other app was running at the time. The only thing I could see generating any errors was the pop3 client. I did not write down verbatim but it was something to the effect of "Network Error: Delivering anyways" or something like that. Next few polls worked fine. Then another one of those, then some more good ones, so on and so forth until it restarts again. I don't know if there is a restart counter that tells how many times it gets to do that b4 it actually dies and Microsoft catches the exception with the "send it to them" dialog box.</p><p>I will, like I said, go back today and turn off Norton on that box, but I think you understand why I do not believe this is the problem. I will also look at the event logger but I think I already know what is going to say.  I'll report back the findings.</p><p>thanks again. </p>

Install filemon from sysinternals maybe you can catch a conficting issue from its logs, and also enable transaction logging on MercuryP.

Since 4.51 is much quicker than its predecessor you're bound to have more conflicts with a real time AV-scanner that doesn't exclude all Mercury/32 used directories - you have to double check the config files and make sure all paths used by Mercury/32 is excluded from Norton real time scan.

<P>Install filemon from sysinternals maybe you can catch a conficting issue from its logs, and also enable transaction logging on MercuryP.</P> <P>Since 4.51 is much quicker than its predecessor you're bound to have more conflicts with a real time AV-scanner that doesn't exclude all Mercury/32 used directories - you have to double check the config files and make sure all paths used by Mercury/32 is excluded from Norton real time scan.</P>

OK guys, I have been running Norton free for about 4 days now. Mercury has not crashed since. Well, it crashed about 1/2 hour after I turn it completely off, but restarted Mercury once and has been up since. However, at the same time I swap memory sticks and went from 512MB to 2GB. So, re-enabling Norton should tell the tail on where the problem was.

The only thing that now happened is that Outlook IMAP seems to be feeding to one machine only.  To explain this better: There are three machines on MSOutlook 2007 polling via IMAP. Everyone is subscribed to the same folders. Even though Mercury connection monitor says all three are connecting fine, only one is getting the new mail in the INBOX. The others do not not show any new mail in that same INBOX folder. All other email is there, just not any new ones coming in.  If I shutdown the machine that is getting the new mails, one of the other ones will then pick up but not all three like it was doing before.

PS. filemon gave me a headache and I was pretty sure if I kept starring at it, it was going to cause me seizures.... ;)

 

<p>OK guys, I have been running Norton free for about 4 days now. Mercury has not crashed since. Well, it crashed about 1/2 hour after I turn it completely off, but restarted Mercury once and has been up since. However, at the same time I swap memory sticks and went from 512MB to 2GB. So, re-enabling Norton should tell the tail on where the problem was.</p><p>The only thing that now happened is that Outlook IMAP seems to be feeding to one machine only.  To explain this better: There are three machines on MSOutlook 2007 polling via IMAP. Everyone is subscribed to the same folders. Even though Mercury connection monitor says all three are connecting fine, only one is getting the new mail in the INBOX. The others do not not show any new mail in that same INBOX folder. All other email is there, just not any new ones coming in.  If I shutdown the machine that is getting the new mails, one of the other ones will then pick up but not all three like it was doing before. </p><p>PS. filemon gave me a headache and I was pretty sure if I kept starring at it, it was going to cause me seizures.... ;)</p><p> </p>

So you suspect it was a memory problem that caused the crashes? Let us know what happens when you start Norton again.

It would appear that the first Outlook client creates some sort of lock on the server and that the lock isn't removed after the check for new mail is complete. I don't know any details on how this is handled in Outlook or Mercury, though.

/Rolf 

<p>So you suspect it was a memory problem that caused the crashes? Let us know what happens when you start Norton again. </p><p>It would appear that the first Outlook client creates some sort of lock on the server and that the lock isn't removed after the check for new mail is complete. I don't know any details on how this is handled in Outlook or Mercury, though.</p><p>/Rolf </p>

you need to use filters with filemon. Since Mercury was crashing looking at the file access on those directories, would show if norton is intervening with the file access.

To be honest I've never used multiple IMAP clients connecting to the same maildrop at the same time. I'd expect headaches with such an action.

<P>you need to use filters with filemon. Since Mercury was crashing looking at the file access on those directories, would show if norton is intervening with the file access.</P> <P>To be honest I've never used multiple IMAP clients connecting to the same maildrop at the same time. I'd expect headaches with such an action.</P>

Well, after re-enabling Norton for about a week now, it seems that is not crashing anymore. I still don't don't know what the problem was. Unless 4.51 eats up a lot more memory now, 512MB on this XP machine served well with the previous version. I upped it to 2GB and is back to normal.

I still have the problem with Outlook clients now. I find it hard to believe that people out there do not have more than one machine polling for IMAP. It seems a logical thing to do to me if you have more than one machine. I have 5 myself all over the house and I used to be able to get email on all of them. The Inbox and all the folders where the same. Now, only one machine gets updated with the new incoming email. If I turn that machine off, another picks up the new email but the others don't, so on and so for.  All the clients are also all the same as they were before the upgrade, Outlook 2003.
Has anyone else seen this behavior before? 

Why would this setup be a headache? I am only one user but, how would a business with multiple users set this up then? OK, let's make it easy, multiple users but hitting only one mail account via IMAP. Mercury POPs email from domain X, delivers to a local share, 1 or more users with Outlook IMAP clients can, at any time open the INBOX to read emails. What is the right way to set this up?

<p>Well, after re-enabling Norton for about a week now, it seems that is not crashing anymore. I still don't don't know what the problem was. Unless 4.51 eats up a lot more memory now, 512MB on this XP machine served well with the previous version. I upped it to 2GB and is back to normal.</p><p>I still have the problem with Outlook clients now. I find it hard to believe that people out there do not have more than one machine polling for IMAP. It seems a logical thing to do to me if you have more than one machine. I have 5 myself all over the house and I used to be able to get email on all of them. The Inbox and all the folders where the same. Now, only one machine gets updated with the new incoming email. If I turn that machine off, another picks up the new email but the others don't, so on and so for.  All the clients are also all the same as they were before the upgrade, Outlook 2003. Has anyone else seen this behavior before? </p><p>Why would this setup be a headache? I am only one user but, how would a business with multiple users set this up then? OK, let's make it easy, multiple users but hitting only one mail account via IMAP. Mercury POPs email from domain X, delivers to a local share, 1 or more users with Outlook IMAP clients can, at any time open the INBOX to read emails. What is the right way to set this up?</p>

[quote user="wojeda"]

Well, after re-enabling Norton for about a week now, it seems that is not crashing anymore. I still don't don't know what the problem was. Unless 4.51 eats up a lot more memory now, 512MB on this XP machine served well with the previous version. I upped it to 2GB and is back to normal.

I still have the problem with Outlook clients now. I find it hard to believe that people out there do not have more than one machine polling for IMAP. It seems a logical thing to do to me if you have more than one machine. I have 5 myself all over the house and I used to be able to get email on all of them. The Inbox and all the folders where the same. Now, only one machine gets updated with the new incoming email. If I turn that machine off, another picks up the new email but the others don't, so on and so for.  All the clients are also all the same as they were before the upgrade, Outlook 2003.
Has anyone else seen this behavior before? 

[/quote]

 

I many times have WinPMail, Thunderbird, OE and Eudora all looking at the same account at the same time using IMAP4 without problems.  All see the same new mail and folders.  There is a problem with deleting since Mercury/32 does not allow deleting when there is concurrent access but I see no other problem. 

 

I have all sort of problems with Outlook 2002 and IMAP4 , many times it simply crashes when trying to do IMAP4, but right now I have Outlook 2002, Thunderbid, OE, WinPmail all looking at the same account al all see the same new mail.  No problems at all.  Mercury/32 v4.52 running on a HP Workstation.

 

.

 

 

[quote user="wojeda"]<p>Well, after re-enabling Norton for about a week now, it seems that is not crashing anymore. I still don't don't know what the problem was. Unless 4.51 eats up a lot more memory now, 512MB on this XP machine served well with the previous version. I upped it to 2GB and is back to normal.</p><p>I still have the problem with Outlook clients now. I find it hard to believe that people out there do not have more than one machine polling for IMAP. It seems a logical thing to do to me if you have more than one machine. I have 5 myself all over the house and I used to be able to get email on all of them. The Inbox and all the folders where the same. Now, only one machine gets updated with the new incoming email. If I turn that machine off, another picks up the new email but the others don't, so on and so for.  All the clients are also all the same as they were before the upgrade, Outlook 2003. Has anyone else seen this behavior before? </p><p>[/quote]</p><p> </p><p>I many times have WinPMail, Thunderbird, OE and Eudora all looking at the same account at the same time using IMAP4 without problems.  All see the same new mail and folders.  There is a problem with deleting since Mercury/32 does not allow deleting when there is concurrent access but I see no other problem.  </p><p> </p><p>I have all sort of problems with Outlook 2002 and IMAP4 , many times it simply crashes when trying to do IMAP4, but right now I have Outlook 2002, Thunderbid, OE, WinPmail all looking at the same account al all see the same new mail.  No problems at all.  Mercury/32 v4.52 running on a HP Workstation.</p><p> </p><p>. </p><p> </p><p> </p>
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft