Retrospect 6.5 not working with update to Avast! 6.0.1203

Using avast! 6.0.1203 and latest virus defs (110705-1).

I know that Retrospect 6.5 is old but it works just fine on my WinXP system and I’ve also had multiple generations of Avast! running on the system for several years. But the latest program upgrade to avast 6.0.1203 is killing Retrospect. The symptom is that starting Retrospect takes several minutes (rather than a few seconds). During that time the PC is essentially unresponsive: e.g., task manager takes 30+ seconds to start; the avast! icon in the system tray is spinning very very slowly and jerkily; trying to open avast! take a minute or so; etc. The task manager shows no cpu load (System Idle Process at 98+ percent). Disabling the real-time shields clears everything up.

I haven’t a clue about how to diagnose this. I tried enabling the 8 shields one at a time. The File System shield certainly causes the problem but so does the Script Shield and I think others. The Behavior shield was OK. Turning the shields on and off finally caused Retrospect to generate an error claiming it couldn’t save my configuration and all of a sudden Retrospect was set back to a just installed condition with all my selectors (and other customizations) gone! So I quit the experiment of turning shields on and off and tried to reconstruct my Retrospect customizations. (I think I recreated the most important ones.)

Turning off the shields is not how I want to do my backups but I will if I have to.

I tried a System Restore to go back a few days but the restore acted flakey and I felt lucky I got a running machine back. Although System Restore claimed that the restore to the earlier date worked I still had the latest Avast program but I had an earlier definitions file (which avast updated quickly). And Retrospect was still hosed.

Suggestions what to look for?

–Larry

I posted a concern earlier today, similar to yours.
My application was Raxco’s Perfect Disk 7 (a defragger from 2004)
which I’ve had installed for years and has worked fine with Avast!
until this latest update.

IN my case disabling the shields didn’t affect the problem.
EDIT I was wrong, disabling the shields alleviates the problem.

I’m glad it didn’t break Norton Ghost (my “other” backup facility). But I’m still wondering if I will find some other apps that have been broken.

I don’t suppose that just a virus definition file update could clear things up?

–Larry

Do you see a process called “sf.bin” running during the wait?

Thanks
Vlk

No sf.bin during the wait. I didn’t see it at all.

I should also mention that the big slowdown does not clear up even after Retrospect has finally gotten started. For example, clicking the avast! icon opens the avast user interface but it takes a long time to open and then clicking anything in the avast interface is really, really slow. But so is clicking anything in the Retrospect interface.

Closing Retrospect takes a long time and then the system returns to normal.

–Larry

I have observed the same behavior as larrymcg.

Vlk, it should be easy for Avast! to recreate the problem? Seems to be a combination
of some specific programs, recent version of Avast! and XP.

Same issue here.
Win XP
Retrospect ver 7.6.123
avast free 6.0.1.203

Worked ok before the update to v203

I was able to determine that turning off 3 of the shields (file, p2p, and im) and leaving the others active took care of the issue, so there may be a common file or process in those 3 shields that is the cause.

The only solution as of now is to go back to the previous version of avast.

Can anyone from Avast respond to this issue?

Same, exact program versions and issues and solutions as major28.
Would like a better solution than turning off shields!

Hi everyone,

I’m running Retrospect Express 7.6.123 and seeing exactly this issue with Avast! Free 6.0.1203 in Windows XP SP3.

I would strongly suggest grabbing a copy of Process Monitor 2.95, found here:

http://technet.microsoft.com/en-us/sysinternals/bb896645

…and using it to observe what happens when Avast! 6.0.1203 is disabled vs. enabled while running Retrospect or anything else that seems to slow to a crawl with Avast!'s shields enabled, as I’ve been able to at least narrow things down a bit this way. I’ve also filtered things by process name, including only AvastSvc.exe, avastUI.exe (which I am using to selectively enable or disable various components of Avast! one at a time), and sf.bin (have not seen it but just in case) - in addition to retrorun.exe and Retrospect.exe, which are Retrospect’s processes. I also suggest enabling advanced output in the Filter menu of Process Explorer, and cross-referencing the operations detected with the descriptions found in these links:

http://msdn.microsoft.com/en-us/library/ff550710(v=VS.85).aspx
http://www.osronline.com/article.cfm?id=166

What I have found so far is as follows:

  • When Avast!'s shields are all disabled, I can run Retrospect with no issue; speed is fine. When it is running, I see Retrospect.exe checking the root directory of each of my drives, one after the other, apparently just making sure they’re available for use as far as I can tell - this is constant but pretty low level and causes no noticeable slow-down, so I presume it’s normal activity.

  • I can enable Mail Shield, Web Shield, Script Shield, Network Shield and Behavior Shield, all with default settings, without this changing.

  • When I enable File System Shield, P2P Shield or IM Shield - to be clear, enabling any of these individually with the others disabled causes the same result - Retrospect.exe goes absolutely bonkers, and starts pounding the MFT on my root drive with IRP_MJ_READ operations, in addition to simultaneously carrying out all kinds of FASTIO_ACQUIRE_FOR_CC_FLUSH and FASTIO_RELEASE_FOR_CC_FLUSH operations on various files, primarily Windows system files (i.e. in C:\WINDOWS\ and various subdirectories) with some additional action targeted at my Program Files (C:\Program Files*) and my local user profile (C:\Documents and Settings\Username*). What’s weird is that Avast itself doesn’t seem to be doing much at all during this time - perhaps I’ve missed a process, but I don’t see any activity at all, really. Based on my reading, I believe the IRP_MJ_READ operation to be just that - a read operation - so Retrospect is being induced to read the MFT of the partition on which it’s installed constantly. Also from my reading, the FASTIO operations above are designed to open and close the file in question for access - so Retrospect appears to be repeatedly opening and closing all kinds of files for access on my OS partition as well, without actually doing anything to them. Very odd.

I have tried disabling all features in the Expert Settings of each of the offending shields, to no avail - even then the same behavior occurs, so it’s something those settings do not touch.

I recently let Retrospect attempt a backup under these conditions; it ran incredibly slowly and generated 1017 errors indicating that it was unable to write to the catalog file, snapshot, and backup set due to insufficient permissions. I don’t find any problems with the permissions associated with these files.

At this point, I’m at a loss as to what else to try; nevertheless, I hope the folks will find this information useful and the Avast! staff can find a fix for this ASAP - as the other posters have said, this is seriously annoying >:( Even if it turns out to be the fault of the folks who coded Retrospect / other applications that experience this, I would emphasize that in almost two years of using Avast! and Retrospect together, this is the first I’ve seen of this, meaning it should be possible to alter Avast! to prevent it from happening; clearly, that’s what needs to be done. Would welcome comments from others as to whether they see similar behavior.

In the meantime, I intend to disable these shields temporarily to perform backups - this is going to require me to backup manually, which is extremely obnoxious, but it beats not having a backup at all.

Regards,

DS

DS,
What an amazing first post! Thanks!
I hope it helps someone get a handle on the problem.
–Larry

Same issue here. :cry:

Win XP
Retrospect ver 6.5
avast free 6.0.1.203

Hello again,

Quick update - with the File System Shield, P2P Shield and IM Shield disabled but the other shields running, Retrospect Express 7.6 was able to carry out my usual backup process successfully, in the usual time and without incident.

For those with issues running Retrospect, I would recommend doing the following: just before leaving your PC for sufficient time for your backup routine to complete (i.e. going to sleep, going to work, whatever), disable only the above three shields until the next restart (need to open the Avast UI to do this), run Retrospect manually, set it to shut down or reboot once finished, and disable any network services / file transfers from untrusted sources while this is going on. These procedures should minimize the security risks associated with this annoyance, and will save you from having to remember to manually turn the shields back on the next time you use the computer (plus if you run a server that’s set to execute on startup, it should come back as well).

PS - larrymcg, thanks very much for the kind and positive feedback! We are hoping for the same thing :slight_smile:

Regards,

DS

Well, I did suggest the solution.
Go back to the previous version of avast.
6.0.1125 works just fine…just set autoupdate virus definitions only, and to notify for program updates. That way you don’t install the buggy version.
The workaround posted by others is too messy.

Hmmm…actually, that gives me an idea… The release history for Avast! is here:

http://www.avast.com/release-history

The changes from 6.0.1125 (which behaves) to 6.0.1203 (which does not) are as follows:

improved compatibility with Windows Vista SP0/SP1 (activation issues)
attempt to solve the "Windows Media Player using a red skin" problem
Firewall: solved the compatibility problem with uTorrent
improved load time of WebRep IE plugin
fixed a bug in Google Chrome WebRep plugin causing excessive CPU usage
improvements in the silent installer
improved the CommunityIQ sample submission process
improved detection/removal of the most stubborn rootkits (TDL family)
various stability and compatibility improvements in the sandbox module
added new CreditAlert feature (US customers only)
added Thai and Serbian language packs

While code can be fickle, the vast majority of these changes would not seem to be the sort that would cause the issue we’re observing. My guess, therefore, is that this is the most likely culprit:

various stability and compatibility improvements in the sandbox module

Downgrading is a good stop-gap measure, but it’s clear that this problem needs to be identified and dealt with. Since the update cycle is pretty short for Avast!, hopefully this will not take too long; I imagine it should be possible for them to reproduce the issue, revert the above changes one by one, and see which one is causing it.

Regards,

DS

The latest program upgrade to Avast! 6.0.1203 killed Norton Ghost 12.0 for me. Reverted back to 6.0.1125 and Ghost is happy again. I am running 6.0.1125 with the latest virus defintions so it’s definitely the program and not the definitions. Hope the guys at Avast figure this out, so I can continue to keep my program up-to-date. For now I’ve switched off automatic program updates.

dustygold,

It doesn’t affect my Norton Ghost 10. Probably lots of changes between versions 10 and 12 of Ghost.

–Larry

This is also happening to me with SUMO (a program that helps you keep your soft up to date) on winXP 64. On win7-64 it works just fine.
I must say, though, that I DO see sf.bin opening and closing several times a minute while SUMO is running. All other progs work fine.
It worked fine before…

any clues as to this sf.bin issue?
It’s not only that sf.bin opens and closes continously, but that it slows down the PC to a crawl while it’s happening.

I also noticed that the Sandbox options are missing from the “additional protection” tab, only Webrep and URL Blocking.
So, no way to change the sandbox options. I suspect sf.bin is related to Sandboxing.
What is wrong here?
I even un-installed avast and re-installed b1023, to no avail.

any ideas?

We found the problem - you can patch avast (see here) or wait for next program update
Thanks!