Results 1 to 5 of 5

Thread: Query about updating

  1. #1
    Guest
    Join Date
    Oct 2005
    Posts
    34

    Default Query about updating

    I am currently using SSD 1.6.2.46 on Windows XP S3 HE, but some of the following applies also to 1.6.0 and possibly to older versions also. For the record, recent scans have required around 20 to 22 minutes to complete.

    I have long been troubled by instances in which scans run for twice as long as normally, up to 40 or 45 minutes. It has just dawned on me that many (all?) of the "slow" instances are associated with occasions when I update the program or its malware definitions and then scan immediately without closing SSD. If I then close the program, re-open it, and try another scan, the time drops back to the more typical low values. Is this plausible? Should users be told to close SSD after updating and then to re-open it before scanning?

    This morning, for example, immediately after updating to the 02/18/2009 definitions and updating the immunization, I ran a scan without closing SSD: I aborted this scan manually after about 37 minutes, closed SSD, abd cleaned my "trash" with CCleaner: this found < 1 MiB to remove. After re-opening SSD, a subsequent scan ran completely in just under 21 minutes. I had a similar experience last week after using the internal updater to update the program, rebooting; and updating the definitions to 02/11/2009. The immediate scan took just under 44 minutes; an independent scan took just over 22 minutes.

    FWIW, my impression is that SSD does not "freeze" anywhere; it just runs very slowly more-or-less everywhere.

    Again FWIW, I do not find similar behavior with other antimalware scanners, including Ad-Aware, SuperAntispyware, and MalwareBytes' Antimalware.

  2. #2
    Senior Member Matt's Avatar
    Join Date
    Aug 2006
    Location
    Bavaria
    Posts
    1,169

    Default

    Hi pudelein,

    I didn't have tried out this, so I can't say too much here.

    The only thing I recommend to you is to reboot your computer after downloading new updates or installing new releases.

    After reboot, you can be sure that Spybot and TeaTimer are updated and ready for a scan or protecting your computer against the newest variants of Malware.

    Best regards,
    -Matt-

  3. #3
    Senior Member drragostea's Avatar
    Join Date
    Jan 2008
    Location
    @Home
    Posts
    3,674

    Default

    We could try a simple diagnosis here... pudelein, how much RAM do you have on your machine and how fast is your processor?

  4. #4
    Guest
    Join Date
    Oct 2005
    Posts
    34

    Default

    My cpu is a 1.7 GHz P4 with 512MB of memory. But remember that the same machine is giving both the "22 min" and "42 min" scan times! And in the two experiments reported in my OP, they were done almost successively (the long run first after updating without closing SSD; the short run second after closing SSD and then restarting it). Note that rebooting the computer plays no part in these experiments. Closing SSD seems to be necessary for its updated definitions to be stored in an optimal form; if this is not done the scans take twice as long as they should; if it is done, the scans run quickly. The only difference is the closing of SSD.

  5. #5
    Senior Member drragostea's Avatar
    Join Date
    Jan 2008
    Location
    @Home
    Posts
    3,674

    Default

    Another user had a similar problem, so I thought I might relate to that... but their scanning time was ridiculous:
    http://forums.spybot.info/showthread.php?t=45974
    -
    It could be possible that your processor is at fault because it is 1.7Ghz.
    However, to me it doesn't seem to be likely to be the problem because of the comparison of closing then scanning compared to scanning right after update. Yet, I don't know if the size of the updates have to do with it at all...

    Hope someone has a better solution.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •