Thunderbird Not Responding with ESET antivirus

OK, I have had this problem for some time on a Win7 PC and it seems to happen when I restart Tbird for one reason or another during the day. However, if I can start it up after it has been off overnight and leave it running all day, the issue rarely occurs - unless after an update, which is why I tend not to update!

The other day, somehow, an update was downloaded. Having got fed-up of the constant nagging to install, I let it. Big mistake!! The update was to 68.6.0 but when that proved unusable, I took it further to 68.8.0. This was equally unusable, in that every I couldn’t even scroll down a list without it ‘not responding’ for ten seconds. Typing a one sentence email took five minutes - yes you read that right.

So off I went down the rabbit-hole of “things to try”. I rebooted the computer in various modes, no help. I spoke to my virus software company and tried some more things - nothing. I’m sure you’ve all been there.

Finally, on another hour-long trawl of ‘try-this’ links, I came across one that suggested turning off windows search - which made some sense. But windows search was already turned-off in Tbird, so I tried turning it off globally. Still no good, so I turned it back on again on the PC.

Then I noticed below that checkbox in the ‘Advanced>General>System Integration’ area that there is another checkbox entitled ‘Enable Global Search and Indexer’. This had always been checked, so I unchecked it and restarted Tbird.


Welcome Malcom. Thank you for posting your experience. Two questions:

  1. I don’t understand what you mean rebooting in various modes - there are 4-5 different ways to boot safe mode, but they are ALL safe mode as far as Thunderbird is concerned, so you only need one of them. Is there some confusion about the instructions for safe mode that we could clarify?

  2. Regarding Global Search, two questions a) in your profile what is the size of global-messages-db.sqlite and global-messages-db journal (you can find the profile from help > troubleshooting > profile folder) b) please describe the age, disk, CPU and memory of your PC.

  1. No
    2(a). global-messages-db.sqlite is 513Mb; global-messages-db journal does not exist. For info, we regularly archive old messages, and a manual archiving session was conducted yesterday as part of the troubleshooting process.

2(b). The PC is 2014, the hard disk this is on is 0.5Tb, CPU is i5-4570 @ 3.2GHz, 16Gb of Memory.

And yes it is an old PC, but it is fine for what it is used for; it will not be changed, but the email client can be - I just don’t need the faff of setting-up multiple email accounts in a new client right now, thank you.

This problem is entirely due to Tbird and specifically the latest update after which the application was completely unusable. The problem has emerged previously on occasion, but I have been able to overcome it relatively easily. This time it was persistent and pernicious.

An extra piece of info: about an hour after the original post, the problem returned but at a less disruptive level. Having once-again restarted the entire PC, I observed what was happening with no other user-applications running, and disconnected from the router to eliminate any spurious traffic. The result was consistent with a memory issue as Tbird worked normally for around ten minutes, then started to go unresponsive, but only for a split second or so.

After twenty minutes, these interruptions became more regular, and were occurring whether I was working in the application or not - as if the application was carrying-out a scheduled operation every few minutes but could not find enough spare memory to complete it.
Having looked at the settings again, in Advanced>Network& Disk Space>Disc Space neither of the options were ticked. The report was that the cache was using 362Mb of disc space, so I selected to override cache management and set it at 1Gb. This has once again resolved the issue completely.

Sure. I’m not suggesting that you change any hardware, but it is indispensable from my perspective to exactly understand the environment in which the problem appears.

You make an interesting observation about the cache setting, that it was using 362mb and you set the override to 1gb. Was there a lower override amount already set?

I’m still fighting this, although every positive change I make eases the problem. Meaning there is still an underlying issue that I cannot get to. It is interesting that you title this a ‘VSE Error’ but you haven’t asked what I use - ESET if it is of interest.

To answer your question, no there was no override set because the option wasn’t ticked, and 1gb was the default when I ticked it, so I took it.

I will be experimenting with settings today, but I am more concerned with why it is doing this and the candidates for me must be external processes that build large amounts of temp data. The most obvious are searches and scanners, which is why I honed in on the search parameters first. I will be looking at VSE as well today.

What I have now is an application that works fine for a while, then starts locking-up. If I close it, then reopen it, the pattern repeats; but not consistently - sometimes it behaves for half an hour, other times misbehaves almost immediately. And let’s be clear here, when it misbehaves it locks up every second word when typing an email - not convenient when you are trying to run businesses from home in a lockdown!!!

I am sure that the cache has something to do with it - as if it gradually fills and then runs out of space; this would suggest that the internal cache now has no way of discarding unused, or unreserved, space - ie it has worked relatively-fine for years, then suddenly it does this after an update. Ergo, Mozilla have broken it - no other possible explanation.

So, if somebody from Mozilla is reading this, this is your product I am troubleshooting for free. So feel free to join in - because the only reason I am doing this is that I have six-years-worth of business email traffic for multiple businesses that I run, invested in your application.

When I run out of patience, which I shortly will, then you will know it - big time.

My account name has nothing to do with antivirus, and I have no affiliation with VSE. You can see my profile at

The best way I can describe your problem is there isn’t yet a smoking gun that indicates why or what is happening, so as you can see these kinds of performance issues don’t always take a quick or smooth path to being resolved. There is a mozilla performance tool that we might be able to use. Until then, I need to ask, how much of you were able to work through?

Sorry, didn’t realise that was a username, thought that was wsmwk.

Answering your question, I haven’t worked through the link you provided, I have just been using my own processes.

I have now found the reason, and it is a memory issue and has been caused by Tbird’s newly-created incompatibility with antivirus scanning methodologies. I suspect that is the way it now automatically allocates cache space is being caught-out by large file sizes - hence why setting a higher fixed-cache value reduced the impact of the issue, but didn’t eliminate it.

I said in an earlier post that, having exhausted the possibilities with searches, I would be playing with VSE parameters today. First thing I did was exclude the profile folder from real-time scanning. This provided an immediate and total solution which I observed over more than two hours. I then narrowed that down to the Mail subfolder, and another two hours have elapsed with no problems whatsoever. So the files causing the issues are in that folder and, of course, it contains some large inbox files.

OK, can’t stay like that forever because it is a risk, but as all emails are already scanned on receipt, then there should be none in the storage that are infected as they would have been eliminated on the way in - hence OK for the purposes of troubleshooting.

So the next process will be to remove the fixed cache setting then reduce the file sizes by additional archiving - ie keeping messages in the inbox a shorter time, raising the compacting parameters, etc, and probably playing further with fixed cache settings until a happy-medium can be found where restarting the real time scanning on this folder does not reintroduce the problem.

Clearly if such a happy medium cannot be found, then its the end of the road for Tbird. Putting it bluntly, we have used this virus software for many many years, and have complete confidence in it. If it comes down to a choice between getting rid of it or another application that cannot be compatible with it, then the application loses that argument every time. Of course, if Mozilla decide to resolve this issue themselves before I get to the decision point, and let me know what update contains the solution, I will be happy to install it.

But let’s be completely clear here. I have been in IT since 1978, and one of the main criteria - certainly since the advent of the personal computer - has always been that any software product should not compromise security. If Mozilla cannot produce a product that is compatible with widely-used industry-standard security software, they shouldn’t be producing any products.