Vipre conflict with Thunderbird

I had the same problem (Thunderbird froze + 100% CPU usage) with the latest definition (5024). As you suggested I went back to 5022 and it's all working fine now. But surely this is a temporary arrangement...since Vipre users also need to cancel automatic updates (which you did not mention). This is the second time in the last 6 months that Vipre has had a conflict with Thunderbird...not good! ( Delete or Edit)

Sorry to hear of your problem with Vipre,Unfortunately it's probably not your last. In my estimation Vipre is a bummer. I uninstalled Vipre three hours ago and my computer has never run better. ( Delete or Edit)

That stinks. :-( Have you tried something like GetDataBack or Recuva to get them back? I don't know if they're that important or if it would even work in this situation. ( Delete or Edit)

Thanks matt. I just tried Recuva, since I know the file names. GetDataBack looks more complicated than I can handle. I'll miss the e-mails, but think I can survive. ( Delete or Edit)

I didn't lose all of my mail. Just three folders worth. All the rest were still there. That's the good news. The bad is that those three couldn't be recovered. Sigh.

I'm not going to jump all over VIPRE yet--I've had lots of hassles with other anti-Virus programs, and VIPRE has been great for me, until now. I hope they can solve this one. ( Delete or Edit)

The conflict with Thunderbird appears to be fixed with 5030 update. The deep scan that was scheduled for Sunday morning did not happen. Waiting to see if the auto scan takes place Monday morning. ( Delete or Edit)

Caution: I forgot to mention another consideration. If you roll back the defs to 5022, and if the behavior of VIPRE hasn't changed from what it has been for at least months, then at some point VIPRE will stop checking anything because your defs are too far out-of-date. At least, months ago I had this kind of problem and I don't know if that has been changed. ( Delete or Edit)

Good. As for me, though, I'm still running into a problem with those half-gid pdf files, when I'm doing a Safe Mode deep scan. These scans used to take 2 or 3 hours. Now, I'm at the 3.5 hour mark, and the second of these files (I don't know if it handled the first, as I was not around. I revisited the computer first at the 3 hour 10 minute mark) has been in the scan at least 40 minutes. But, at least the filename is showing up in the Status line. Previously, only the folder name was showing. I'm going to give this another half hour or hour before deciding that I should count the scan as frozen. EDIT: Now, the "pause" button yields a response. That's an improvement, in addition to the filename's showing being an improvement. ( Delete or Edit)

At the 4 hour 10 minute mark, I visit the computer, and the scan is now at the 3rd of those enormous pdf files. So, the final word is in. The scan isn't stuck. It's merely having a heck of a time with these particular files. The old VIPRE (before 5019, and before 5023) didn't. Of course, from a user's point of view, there's no way of telling whether this change is a pure negative or a small price to pay for a substantial improvement in the process, or what. I hope Sunbelt comments on it. NOTE: I know this thread is about TB, not about scans. But, since I mentioned the port assignment (and port filtering) problem and the scanning of the big pdf's as the residual problems that I see, I'm following that up here. Should there be real developments, a new thread would probably be in order. ( Delete or Edit)

Development is still looking into the TB problems. We have a test environment set up to try to reproduce some of these issues. As for the scans getting stuck, we may need to look into that further. Please contact our support department so we can figure out what exactly is causing this behavior. support@sunbeltsoftware.com

~ Jason ( Delete or Edit)

On JasonL's comment:
To be clear, the scans are no longer getting stuck. This particular scan did finally complete. I had already indicated in the comment that JasonL was apparently responding to that it was NOT getting stuck. I wrote, "The scan isn't stuck. It's merely having a heck of a time with these particular files."
It was taking 30 to 50 minutes (several times longer than a week ago) to do a safe mode deep scan of each half gigabyte pdf file of a bilingual lexicon. Even earlier, I had written "But, at least the filename is showing up in the Status line. Previously, only the folder name was showing. I'm going to give this another half hour or hour before deciding that I should count the scan as frozen. EDIT: Now, the "pause" button yields a response. That's an improvement, in addition to the filename's showing being an improvement."
And, my guess and hope is that the slowness is due to more rigorous examination of those files, which may be complicated from the program's point of view. It would be good, though not necessary, to get Sunbelt's view of this. ( Delete or Edit)