Hello:
There is no 'Pause' button on a manually-started scan, only 'Cancel'. Is that right?
How does a user pause a currently-executing scan? WRSA.exe is using 99% CPU.. Attempts to lower task prioritiy from 'Normal' with Task Manager are blocked, "Access is denied'. I was 25 hours into this scan, and was not happy to have to cancel it to recover use of my workstation.
-- Roy Zider
Windows SP SP3
Latest version of WRSA (but no 'Help | About' tab to identify version)
Solved
No 'Pause' button on WRSA
Best answer by Kit
Hi!
Let's start at the beginning, and when we get to the end, we'll stop. :)
Item: No pause button
The lack of a Pause button is intentional. On the average properly-running computer running default settings and deep scans, the scan takes two minutes or less. The use of custom or full scans is explicitly not-recommended and the agent does, in fact, advise you of this.
Item: CPU Use of 95%
See: Settings -> Basic Configuration -> "Operate background functions using fewer CPU resources" (Applies to realtime operations) and Settings -> Scan Settings -> "Favor low CPU usage over fast scanning" for additional options to reduce CPU use. That being said, the system is running Windows XP on an AMD Athlon XP 2000+ single-core 1.66Ghz 32-bit processor, which was originally released in January of 2002. That's processor technology that's over a decade old. While the program will run on that, just like any application, running on substantially older, lower-end machines will take more of the resources and a longer time. Unfortunately, I can't speak for a diagnosis of the CPU use in the case of the scans as the logs you submitted do not include the actual scan logs, but only have the main program logs.
A deep scan cannot be run on an arbitrary location, mind you, so claiming that a deep scan was run on U: is not physically possible in the agent unless a file on U: is referenced in startup locations or auto-run locations. A quick examination of the logs indicates that the initial scan took 7m 42s to perform its deep scan, and a second deep scan thereafter took 3m 28s, and a third 3m 26s. A Quick Scan finished in 3s thereafter, followed by starting a scan of C:, 😨, E:, U:, and V: all in one scan.
This monolithic scan promptly began to detect the malware located in dormant places on pretty much every drive, and the moment it detects one thing, it goes into a more thorough mode, which will invariably slow down the scan as it begins to do extra investigation of files. Even without this extra investigation, doing a Full or Custom scan will invariably result in every byte of every file scanned being read from the disk for the purpose of generating the MD5 hash of the file. Disk performance will impact this of course, as will the older nature of the physical CPU. Combine that with extracting files from numerous archives and you'll note that the impact is even greater, since it's extracting the archives to the temporary folder after the initial hashing, followed by DiskKeeper evaluating the files that were just extracted for fragmentation, after which it then hashes the files that were extracted.
For even more fun, many of the files were double-archived. So you have the overhead of first extracting the .zip from the .rar, followed by extracting the .exe from the .zip. Older computers are not quite as fond of that. I'm even boggling at a case of a file inside a .rar inside a .zip inside a .rar. Bit overkill, maybe.
Regardless, nearly 800,000 files and a day later, the scan was cancelled. Yes, indeed, with extracting that many files from nested archives and processing that sheer a volume of data, it's going to take a long time and quite a bit of CPU on an older computer.
Item: The first scan, run on installation on 6/4/2012, was a deep scan on K7N system first time. It was aborted at 25 hours, only 43% done.
See above. The first scan run was a deep scan that took 7m42s. The scan you are referencing is a custom or full, which the agent specifically recommends against unless you are a network administrator for example or explicitly attempting to inventory the system.
Item: Checking the integrity of a drive with CHKDSK is generally a bad idea, a rookie mistake. The first check to run is for readability of all files – using CDCheck. Ran CDCheck last night, read the drive OK:
Validating the media is only a small part (and the longest part) of running chkdsk. CDCheck will indeed generally validate the readability of the media, however it will not validate the integrity of the file system, which is also important. The second thing that CHKDSK does that CDCheck does not do is communicate with the drive controller at a low level for the purpose of detecting recoverable errors that indicate health issues on the media. If the drive takes two seconds to read a sector but eventually teases the correct data out of it (according to the drive itself), CDCheck will consider that valid. By comparison, chkdsk will flag that as a failing sector and move the data off it while it still can be read. (I'll refrain from pointing out the errors indicated in the CDCheck paste because they may not be related, while by comparison a chkdsk result set is standardized.
Item: False Positives
Without full scan logs to investigate, I can't accurately comment on this. I can surmise, with no information, that there is either a good chance the command.com in question was in a non-standard location and really was a threat, or was hit by a file infector, of which you have a plethora detected in the aborted 25-hour scan that I have logs for.
Anyway, the primary issue that I see in this case is the use of the agent in a manner inconsistent with best practices and agent-given advice. While you can run a full or custom scan, it just generally normally shouldn't be and isn't necessary in common consumer user scenarios.
The recommendation in that situation is to, for normal use, leave it running a deep scan (about 3-4 minutes in your case) and utilize the settings described above to reduce CPU use on the older hardware.
The request for a pause button is (still) currently considered extremely edge-case and better solved with information.
I can't comment much on the alleged CPU usage without seeing scan logs from standard operation, however given that it was extracting four-layer nested archives and hashing everything as per operating parameters on a decade-old CPU that is highly sub-optimal for hashing, I would expect it. That is why the settings are available to reduce the CPU usage in those cases.
I will address the Deep vs Full/Custom in the other thread.
The post you made was very long, so I apologize if I missed anything.
View originalLet's start at the beginning, and when we get to the end, we'll stop. :)
Item: No pause button
The lack of a Pause button is intentional. On the average properly-running computer running default settings and deep scans, the scan takes two minutes or less. The use of custom or full scans is explicitly not-recommended and the agent does, in fact, advise you of this.
Item: CPU Use of 95%
See: Settings -> Basic Configuration -> "Operate background functions using fewer CPU resources" (Applies to realtime operations) and Settings -> Scan Settings -> "Favor low CPU usage over fast scanning" for additional options to reduce CPU use. That being said, the system is running Windows XP on an AMD Athlon XP 2000+ single-core 1.66Ghz 32-bit processor, which was originally released in January of 2002. That's processor technology that's over a decade old. While the program will run on that, just like any application, running on substantially older, lower-end machines will take more of the resources and a longer time. Unfortunately, I can't speak for a diagnosis of the CPU use in the case of the scans as the logs you submitted do not include the actual scan logs, but only have the main program logs.
A deep scan cannot be run on an arbitrary location, mind you, so claiming that a deep scan was run on U: is not physically possible in the agent unless a file on U: is referenced in startup locations or auto-run locations. A quick examination of the logs indicates that the initial scan took 7m 42s to perform its deep scan, and a second deep scan thereafter took 3m 28s, and a third 3m 26s. A Quick Scan finished in 3s thereafter, followed by starting a scan of C:, 😨, E:, U:, and V: all in one scan.
This monolithic scan promptly began to detect the malware located in dormant places on pretty much every drive, and the moment it detects one thing, it goes into a more thorough mode, which will invariably slow down the scan as it begins to do extra investigation of files. Even without this extra investigation, doing a Full or Custom scan will invariably result in every byte of every file scanned being read from the disk for the purpose of generating the MD5 hash of the file. Disk performance will impact this of course, as will the older nature of the physical CPU. Combine that with extracting files from numerous archives and you'll note that the impact is even greater, since it's extracting the archives to the temporary folder after the initial hashing, followed by DiskKeeper evaluating the files that were just extracted for fragmentation, after which it then hashes the files that were extracted.
For even more fun, many of the files were double-archived. So you have the overhead of first extracting the .zip from the .rar, followed by extracting the .exe from the .zip. Older computers are not quite as fond of that. I'm even boggling at a case of a file inside a .rar inside a .zip inside a .rar. Bit overkill, maybe.
Regardless, nearly 800,000 files and a day later, the scan was cancelled. Yes, indeed, with extracting that many files from nested archives and processing that sheer a volume of data, it's going to take a long time and quite a bit of CPU on an older computer.
Item: The first scan, run on installation on 6/4/2012, was a deep scan on K7N system first time. It was aborted at 25 hours, only 43% done.
See above. The first scan run was a deep scan that took 7m42s. The scan you are referencing is a custom or full, which the agent specifically recommends against unless you are a network administrator for example or explicitly attempting to inventory the system.
Item: Checking the integrity of a drive with CHKDSK is generally a bad idea, a rookie mistake. The first check to run is for readability of all files – using CDCheck. Ran CDCheck last night, read the drive OK:
Validating the media is only a small part (and the longest part) of running chkdsk. CDCheck will indeed generally validate the readability of the media, however it will not validate the integrity of the file system, which is also important. The second thing that CHKDSK does that CDCheck does not do is communicate with the drive controller at a low level for the purpose of detecting recoverable errors that indicate health issues on the media. If the drive takes two seconds to read a sector but eventually teases the correct data out of it (according to the drive itself), CDCheck will consider that valid. By comparison, chkdsk will flag that as a failing sector and move the data off it while it still can be read. (I'll refrain from pointing out the errors indicated in the CDCheck paste because they may not be related, while by comparison a chkdsk result set is standardized.
Item: False Positives
Without full scan logs to investigate, I can't accurately comment on this. I can surmise, with no information, that there is either a good chance the command.com in question was in a non-standard location and really was a threat, or was hit by a file infector, of which you have a plethora detected in the aborted 25-hour scan that I have logs for.
Anyway, the primary issue that I see in this case is the use of the agent in a manner inconsistent with best practices and agent-given advice. While you can run a full or custom scan, it just generally normally shouldn't be and isn't necessary in common consumer user scenarios.
The recommendation in that situation is to, for normal use, leave it running a deep scan (about 3-4 minutes in your case) and utilize the settings described above to reduce CPU use on the older hardware.
The request for a pause button is (still) currently considered extremely edge-case and better solved with information.
I can't comment much on the alleged CPU usage without seeing scan logs from standard operation, however given that it was extracting four-layer nested archives and hashing everything as per operating parameters on a decade-old CPU that is highly sub-optimal for hashing, I would expect it. That is why the settings are available to reduce the CPU usage in those cases.
I will address the Deep vs Full/Custom in the other thread.
The post you made was very long, so I apologize if I missed anything.
Hey FUBARinSFO,
Welcome to the Webroot Community!
While there is indeed no "pause" button you can click in the middle of a scan, there shouldn't be any need to pause a scan as a typical Webroot SecureAnywhere "deep" scan takes only 1-2 minutes.
Your issue is quite unique as I have never heard of one of our scans taking even a quarter of the that time! On that same note, WRSA.exe should only be using a tiny portion of your CPU so something is definitely not right here. We definitely need to investigate further and the best way to (more quickly) get to the bottom of this would be for you to open a support ticket so we can request the necessary log files from your computer and troubleshoot accordingly.
Please let me know if you have any trouble submitting the ticket or if you have any other questions.
Welcome to the Webroot Community!
While there is indeed no "pause" button you can click in the middle of a scan, there shouldn't be any need to pause a scan as a typical Webroot SecureAnywhere "deep" scan takes only 1-2 minutes.
Your issue is quite unique as I have never heard of one of our scans taking even a quarter of the that time! On that same note, WRSA.exe should only be using a tiny portion of your CPU so something is definitely not right here. We definitely need to investigate further and the best way to (more quickly) get to the bottom of this would be for you to open a support ticket so we can request the necessary log files from your computer and troubleshoot accordingly.
Please let me know if you have any trouble submitting the ticket or if you have any other questions.
Yegor -- I will open a ticket. Had to shut it down.
almost 25 hours into this scan (24:54) and only 43% done (793,169 files, 332 threats)
almost 25 hours into this scan (24:54) and only 43% done (793,169 files, 332 threats)
It's good to hear you're opening a ticket. I'd be curious to know the results of our threat team's findings. Around the same time you posted this thread, you also opened this one, to which I have responded in a bit more detail. It sounds like there is a lot of malware on this computer. I'm wondering if perhaps you're doing some testing on a purposely infected machine or if there are a whole lot of keygens we are picking up as malware on the computer. While we can deal with a lot of malware at once, sometimes that necessitates multiple scans. That however would not explain why a single scan would be so lengthy. Hopefully our threat team can get this worked out for you.
JimM -- how 'Reply' to this message? Get popup 'are you sure you want to navigate away from this page and lose ... " etc.
JimM:
'Reply' now, without popup 'Are you sure you want to navigate away from this page' warning.
I have posted a ticket, and completed the wsalogs upload. Unclear who to notify about the upload, so I just mention it here, mention it as reply to earlier post, and replied to email as well.
On the workstation in question (K7N), there are a lot of files. I'm not familiar with how Webroot counts 'files', when there are zip/rar/archive packages. It inspects them, I assume, and as it unrolls them it counts each file inside as a file as well.
Dir of the U: backup disk: Multiply this by 2, max.
343177 File(s) 353,505,742,756 bytes
This is not a threat detection platform per se. It does have keygen files. It is of course always the risk that a keygen.exe will infect a system. Many AV threat detection programs simply tag or reject them. That is not helpful.
-- Roy Zider
'Reply' now, without popup 'Are you sure you want to navigate away from this page' warning.
I have posted a ticket, and completed the wsalogs upload. Unclear who to notify about the upload, so I just mention it here, mention it as reply to earlier post, and replied to email as well.
On the workstation in question (K7N), there are a lot of files. I'm not familiar with how Webroot counts 'files', when there are zip/rar/archive packages. It inspects them, I assume, and as it unrolls them it counts each file inside as a file as well.
Dir of the U: backup disk: Multiply this by 2, max.
343177 File(s) 353,505,742,756 bytes
This is not a threat detection platform per se. It does have keygen files. It is of course always the risk that a keygen.exe will infect a system. Many AV threat detection programs simply tag or reject them. That is not helpful.
-- Roy Zider
Roy,
The message 'Are you sure you want to navigate away from this page' would usually indicate you probably started replying using "Quick reply" and then clicked "Reply," which necessarily takes you to the reply page and away from any content already typed into the "Quick reply" area. The notification is to alert you that you're about to lose any data you may have just typed into "Quick reply."
Regarding zip files, yes it does count the contents of those files as individual items in a scan count. However, it would not scan archives by default in a deep scan. It sounds like you have probably set it to run a full scan instead. While the program allows for this, it's not the standard scan method, and in terms of what is required to give your computer full protection, running such a scan isn't necessary to that end. Deep scans know which files pose immediate risk to the computer, and such scans will scan anything that poses immediate risk (stuff that is running now, stuff that could be running soon) and it rules out stuff that can't contain an infection, thus not wasting time on files that do not present risk. However, a full scan will scan every last file on your hard drive regardless of whether or not they present risk. Such scans are necessarily going to be more lengthy, though 25 hours is far too extreme to be considered normal. What we need to see to make an analysis of what is going on here is a scan log.
I pulled up the support ticket, and it appears the agent who has your ticket has requested logs already. Once he has the logs back from you, he can start making an analysis.
Regarding keygens specifically, different keygens are unique files with unique file signatures and are treated independently by SecureAnywhere. They are not all group-flagged as bad just by virtue of being keygens. So if we are flagging them as bad, they almost certainly are actually bad, but we can take another look for you manually if you'd like. Once again though, that will require sending back the requested logs.
I'll continue to keep an eye on the ticket for you as well.
*edit for new info*
It looks like we have the logs, but a message was never sent back to support to indicate the tool had been run, which delayed the response. I made the message on your behalf, and the ticket is now being reviewed.
The message 'Are you sure you want to navigate away from this page' would usually indicate you probably started replying using "Quick reply" and then clicked "Reply," which necessarily takes you to the reply page and away from any content already typed into the "Quick reply" area. The notification is to alert you that you're about to lose any data you may have just typed into "Quick reply."
Regarding zip files, yes it does count the contents of those files as individual items in a scan count. However, it would not scan archives by default in a deep scan. It sounds like you have probably set it to run a full scan instead. While the program allows for this, it's not the standard scan method, and in terms of what is required to give your computer full protection, running such a scan isn't necessary to that end. Deep scans know which files pose immediate risk to the computer, and such scans will scan anything that poses immediate risk (stuff that is running now, stuff that could be running soon) and it rules out stuff that can't contain an infection, thus not wasting time on files that do not present risk. However, a full scan will scan every last file on your hard drive regardless of whether or not they present risk. Such scans are necessarily going to be more lengthy, though 25 hours is far too extreme to be considered normal. What we need to see to make an analysis of what is going on here is a scan log.
I pulled up the support ticket, and it appears the agent who has your ticket has requested logs already. Once he has the logs back from you, he can start making an analysis.
Regarding keygens specifically, different keygens are unique files with unique file signatures and are treated independently by SecureAnywhere. They are not all group-flagged as bad just by virtue of being keygens. So if we are flagging them as bad, they almost certainly are actually bad, but we can take another look for you manually if you'd like. Once again though, that will require sending back the requested logs.
I'll continue to keep an eye on the ticket for you as well.
*edit for new info*
It looks like we have the logs, but a message was never sent back to support to indicate the tool had been run, which delayed the response. I made the message on your behalf, and the ticket is now being reviewed.
Sorry for the double-post here, but I want to make sure Roy sees this.
Roy, I sent you a reply via the ticket system on the 12th, but it doesn't appear you've looked at it yet. Just as a quick summary, it appears that 1. The issue is actually no longer persisting according to the recent scan logs, and 2. There is a lot of file corruption present on your system, so I recommended you run Check Disk in any case.
Please let me know if you're still running into any further issues.
Roy, I sent you a reply via the ticket system on the 12th, but it doesn't appear you've looked at it yet. Just as a quick summary, it appears that 1. The issue is actually no longer persisting according to the recent scan logs, and 2. There is a lot of file corruption present on your system, so I recommended you run Check Disk in any case.
Please let me know if you're still running into any further issues.
Jim:
I will have to get back to you on this. I can't tell when the 12th was from this message board, since the dates don't appear (on my screen). "the issue is actually no longer persisting' doesn't make sense to me, as neither does the file fragmentation (I run Diskeeper all the time, automatically). -- Roy
I will have to get back to you on this. I can't tell when the 12th was from this message board, since the dates don't appear (on my screen). "the issue is actually no longer persisting' doesn't make sense to me, as neither does the file fragmentation (I run Diskeeper all the time, automatically). -- Roy
+56Hello Roy,@ wrote:
Jim:
I will have to get back to you on this. I can't tell when the 12th was from this message board, since the dates don't appear (on my screen). "the issue is actually no longer persisting' doesn't make sense to me, as neither does the file fragmentation (I run Diskeeper all the time, automatically). -- Roy
This is what JimM meant about disk checking for possible errors! http://www.w7forums.com/use-chkdsk-check-disk-t448.html
HTH,
TH
Yes, thank you for the link and clarification. I am of course familiar with chkdsk. Diskeeper throws a warning when it discovers any sort of problem like that. But I will run some tests along those lines nevertheless. smartmontools monitors all my drives, runs short self-tests every night and extended self-tests once a week. That handles physical sector integrity.
In any case, I've removed and reinstalled webroot, and have started a custom scan on my U: (backup) drive. There is no "pause" scan button, only 'Cancel'. U: has 344,000 files or so. It is perfectly defragmented. We'll see how long the scan takes.
Total Files Listed:
344276 File(s) 366,443,560,831 bytes
83223 Dir(s) 56,196,329,472 bytes free
In any case, I've removed and reinstalled webroot, and have started a custom scan on my U: (backup) drive. There is no "pause" scan button, only 'Cancel'. U: has 344,000 files or so. It is perfectly defragmented. We'll see how long the scan takes.
Total Files Listed:
344276 File(s) 366,443,560,831 bytes
83223 Dir(s) 56,196,329,472 bytes free
Roy,
I'm afraid I don't understand what you mean that you don't know when the 12th was. I mean only to say that a reply went out to you via the ticket system on 6-12-12.
"The issue is no longer persisting" means that based on scan logs presented to us via the ticket system that scans have been completing for you in an average of 4 minutes time. The lengthiness and freezing during the scan was specific to the one time the issue was reported and has not occurred again since then according to the information in the logs.
The files in question may not necessarily be fragmented, but they are corrupted. That means they could for instance be sitting on bad sectors. Defragmentation is not the same thing as error-checking. The Windows defragmenter shuffles around parts of files to put everything in optimal order for quick access. Windows Check Disk on the other hand can check the disk itself for errors.
I'm afraid I don't understand what you mean that you don't know when the 12th was. I mean only to say that a reply went out to you via the ticket system on 6-12-12.
"The issue is no longer persisting" means that based on scan logs presented to us via the ticket system that scans have been completing for you in an average of 4 minutes time. The lengthiness and freezing during the scan was specific to the one time the issue was reported and has not occurred again since then according to the information in the logs.
The files in question may not necessarily be fragmented, but they are corrupted. That means they could for instance be sitting on bad sectors. Defragmentation is not the same thing as error-checking. The Windows defragmenter shuffles around parts of files to put everything in optimal order for quick access. Windows Check Disk on the other hand can check the disk itself for errors.
Adding just one note here:
A custom or full scan is a file surface investigation only, and is not the same as a deep scan. Scanning backup files will always take a long time because normally they will never be scanned because it's simply never necessary to scan them during the normal course of operation. Only files that will or probably will execute or be touched by the system itself are scanned. Anything that is sitting in storage is not going to infect your system while it's inactive. In the event that it's copied, run, or read, it's scanned at that time.
Scanning everything, no matter what, will take a long time and bog down the system. So why bog down the system when doing so won't provide any extra real benefit? The deep scans combined with the situationally-aware real-time protection touch a fraction of the files and provide full protection for the system without using an extra bunch of computer power to do so.
A custom or full scan is a file surface investigation only, and is not the same as a deep scan. Scanning backup files will always take a long time because normally they will never be scanned because it's simply never necessary to scan them during the normal course of operation. Only files that will or probably will execute or be touched by the system itself are scanned. Anything that is sitting in storage is not going to infect your system while it's inactive. In the event that it's copied, run, or read, it's scanned at that time.
Scanning everything, no matter what, will take a long time and bog down the system. So why bog down the system when doing so won't provide any extra real benefit? The deep scans combined with the situationally-aware real-time protection touch a fraction of the files and provide full protection for the system without using an extra bunch of computer power to do so.
Folks:
It appears to me we’ve got a bit of thread drift going on here with some round-and-round thrown in. I’ve run tests over the weekend which confirm the integrity of the files on the drive; they are not corrupted. I thought that perhaps I could respond to some of the loose ends by rolling them back up, but I’m anxious to avoid more round-and-round. The longer this goes on, the more issues are being raised and unanswered.
So to short-circuit this thread, and to reset the discussion, here’s where I am with this:
- There is no ‘Pause’ scan button for a running scan.
- The WRSA.exe scan task uses 95% or more CPU, and the task priority can’t be demoted.
I don’t want to be put in the position of having to contradict some of the judgments offered here, because they are obviously offered conscientiously. In fact, I would say that what impresses me (and causes me to run the tests I have) is that you obviously care about your product. But for the purposes of this thread only, the above are the two performance issues I’ve raised here. I have other issues, which I may also lodge, but if I do I will start a separate thread.
For the moment, the most helpful thing the developers could do would be to fix these two problems. Thank you.
-- Roy Zider
WRSA 8.0.1.193
Windows XP SP3
Below are excerpts from my notes from the past several days. Because I don’t seem to be able to post the screenshots inline with these comments, much of the visual support will be lost.
06/18/2012 18:47 lsz Webroot deep scan screenshots on K7N
D:DDandSBitBucketMyDox_ComputerSecurityWebrootDeep scans
SUMMARY
Deep scan of backup drive U: on K7N ran 32:44 hh:mm, scanned 883,359 files and detected 560 “Malicious Files”. In contrast, Eset NOD32 v4 (on MPX2) took 13:09, inspected 710,466 ‘scanned objects’ and flagged 215 files.
DISCUSSION
This is the second scan on K7N, to confirm the “long” run time of the scan run on installation.
WRSA 8.0.1.193
Windows XP SP3
The first scan, run on installation on 6/4/2012, was a deep scan on K7N system first time. It was aborted at 25 hours, only 43% done.
See log file embedded in
wsalogs_file1303@gmail.com_2012-06-06-17.15.21.7z
D:DDandSBitBucketMyDox_ComputerSecurityWebrootlogutil upload 1
.. beginning of WRLog.log:
Mon 2012-06-04 02:19:22.0406 Begin Installation
Mon 2012-06-04 02:19:22.0500 Installation successfully completed (WSAINSTALL.EXE/0)
Mon 2012-06-04 02:19:22.0515 >>> Service started [v8.0.1.184]
Mon 2012-06-04 02:19:23.0453 User process connected successfully from PID 2104, Session 0
Mon 2012-06-04 02:19:23.0765 Protection enabled
Mon 2012-06-04 02:19:23.0812 Scan Started: [ID: 1 - Flags: 551/16]
Mon 2012-06-04 02:19:23.0937 Connecting to 99 – 99
<skipped some entries>
Mon 2012-06-04 12:55:48.0781 Scan Aborted: [ID: 4]
Mon 2012-06-04 12:56:37.0734 Scan Started: C:|D:|E:|U:|V:| [ID: 5 - Flags: 256/288]
Mon 2012-06-04 13:26:47.0187 Infection detected: c:program filesflash renamerflashren.exe [MD5: 0DB3511FBF6EC1EBBB871F47FB4C13AF] [3/08080000] [W32.Malware.Gen]
.. end of WRLog.log:
Tue 2012-06-05 14:10:25.0234 Scan Results: Files Scanned: 797082, Duration: 25h 13m, Malicious Files: 332
Tue 2012-06-05 14:10:44.0531 Scan Aborted: [ID: 5]
Tue 2012-06-05 14:10:52.0859 Scan Started: [ID: 6 - Flags: 1575/16]
Tue 2012-06-05 14:24:07.0984 >>> Service started [v8.0.1.184]
-----------------------------------------------------------------
This initial scan used about 100% CPU, made system unusable. Posted note to forum about lack of ‘Pause’ button:
-----------------------------------------------------------------
Your Message (Jun 5, 2012 23:27)
No 'Pause' button on WRSA
Posted message in community about there being no 'Pause' button on WRSA 8.0.1.184. CPU running 99%, can't demote task priority.
Shut down almost 25 hours into this scan (24:54) and only 43% done (793,169 files, 332 threats)
Y.P.(?) suggesed this ticket.
-- Roy Zider
Windows XP SP3
WRSA 8.0.1.184
-----------------------------------------------------------------
This long time to scan files challenged by Webroot support. Attributed long times to fragmented or damaged file system or system drive.
To check this result, and obviate concerns about fragmentation and file system corruption, this second test was run. Ran a deep scan on the full K7N backup drive U: starting Saturday and lasting over the weekend. This 400 GB drive is virtually completely clean insofar as file performance is concerned:
<screenshots of Diskeeper on U:, showing clean defragmented drive>
Generally, the drive is very clean insofar as actual file fragments are concerned. The average number of fragments per file is 1.00:
But because there is so little free space, it’s performance for DEFRAGMENTING is lower. (note – this does not refer to file access/read)
A ‘Custom’ scan was selected:
<screenshot>
After 19 hours of scanning, it reckoned it was 60% complete:
But as before, it was using 95% CPU, rendering the system unusable:
Coming in today (Monday) to check the results of the run over the weekend, the scan was done but WRSA.exe was still using 94% CPU:
<screenshot)
There was no ‘Scan results’ panel to review, nor any indication of what was going on. For all practical purposes, the scan was over and done with, threats were detected, but no obvious indication of what was causing the CPU drain. In fact, here is says it needs to scan the computer because threats have been detected. So this is confusing as well.
Reviewing the first page of threats, I found that all were false positives:
<screen shots – command.com and qcmp.com>
Upon opening the scan log, I noted that WRSA.exe yielded to notepad.exe in CPU usage:
Checking the log itself, I confirmed that the scan had in fact completed, at 0058 this morning. So why the CPU usage was over 90% was still a mystery:
And here was another clue as to what might be driving the CPU % -- it had perhaps started another scan. It had been about 11 hours since the end of the weekend mammoth scan, but what the ‘Duration’ of 11h 13m refers to can’t be the ‘Most recent scan’ if it refers to completed scan. But it could refer to a current scan, given the indicated ‘Duration’:
<screenshots>
There is a ‘Scan Schedule’ panel, but the parms don’t seem to provide much support for a new scan starting right after the last one has completed:
<screenshots>
I didn’t note whether I tried to stop the scan or not (if that what was happening), but WRSA continuted to suck up CPU long after this:
<screenshots>
Examination of the tail end of the log shows nothing that would indicate a running scan of this intensity:
-----------------------------------------------------------------
Mon 2012-06-18 00:58:06.0529 Scan Results: Files Scanned: 883359, Duration: 32h 44m, Malicious Files: 560
Mon 2012-06-18 00:58:16.0436 Scan Finished: [ID: 3 - Seq: 38272419]
Mon 2012-06-18 00:58:20.0170 Scan Started: [ID: 4 - Flags: 1575/16]
Mon 2012-06-18 01:21:55.0170 Begin passive write scan (1 file(s))
Mon 2012-06-18 01:21:59.0889 End passive write scan (1 file(s))
Mon 2012-06-18 01:21:59.0904 Begin passive write scan (1 file(s))
Mon 2012-06-18 01:22:01.0904 Begin passive write scan (1 file(s))
Mon 2012-06-18 01:22:04.0045 End passive write scan (1 file(s))
Mon 2012-06-18 01:22:04.0108 End passive write scan (1 file(s))
Mon 2012-06-18 01:22:11.0920 Begin passive write scan (1 file(s))
Mon 2012-06-18 01:22:13.0170 End passive write scan (1 file(s))
Mon 2012-06-18 01:22:18.0936 Begin passive write scan (1 file(s))
Mon 2012-06-18 01:22:22.0373 End passive write scan (1 file(s))
Mon 2012-06-18 01:22:31.0092 Begin passive write scan (1 file(s))
Mon 2012-06-18 01:22:32.0358 End passive write scan (1 file(s))
Mon 2012-06-18 09:05:14.0483 Blocked process from accessing protected data: C:Program FilesIDM Computer SolutionsUEStudioUEStudio.exe [Type: 6]
Mon 2012-06-18 09:18:23.0717 Saved the product log to D:HSRCDSKSSecurityWebroot Secure Anywhere Complete 2012K7N-U 6-17-2012.log
-----------------------------------------------------------------
06/19/2012 8:47 lsz results from CDCheck scan of U:
Checking the integrity of a drive with CHKDSK is generally a bad idea, a rookie mistake. The first check to run is for readability of all files – using CDCheck. Ran CDCheck last night, read the drive OK:
-----------------------------------------------------------------
Info
- date: 06/18/2012
- process: Check
- source: U:
- source volume label: ST400-1
Basic statistics
- time elapsed: 02:52:10
- overall transfer [kB/s]: 34,689
- folders processed: 28315
- files processed: 347410
- source bytes read: 341 GB (366,968,705,096 bytes)
- source average transfer [kB/s]: 38,006
- source clean transfer [kB/s]: 46,364
Errors
- errors: 1
- warnings: 46
- other: 47
-----------------------------------------------------------------
Hi!
Let's start at the beginning, and when we get to the end, we'll stop. :)
Item: No pause button
The lack of a Pause button is intentional. On the average properly-running computer running default settings and deep scans, the scan takes two minutes or less. The use of custom or full scans is explicitly not-recommended and the agent does, in fact, advise you of this.
Item: CPU Use of 95%
See: Settings -> Basic Configuration -> "Operate background functions using fewer CPU resources" (Applies to realtime operations) and Settings -> Scan Settings -> "Favor low CPU usage over fast scanning" for additional options to reduce CPU use. That being said, the system is running Windows XP on an AMD Athlon XP 2000+ single-core 1.66Ghz 32-bit processor, which was originally released in January of 2002. That's processor technology that's over a decade old. While the program will run on that, just like any application, running on substantially older, lower-end machines will take more of the resources and a longer time. Unfortunately, I can't speak for a diagnosis of the CPU use in the case of the scans as the logs you submitted do not include the actual scan logs, but only have the main program logs.
A deep scan cannot be run on an arbitrary location, mind you, so claiming that a deep scan was run on U: is not physically possible in the agent unless a file on U: is referenced in startup locations or auto-run locations. A quick examination of the logs indicates that the initial scan took 7m 42s to perform its deep scan, and a second deep scan thereafter took 3m 28s, and a third 3m 26s. A Quick Scan finished in 3s thereafter, followed by starting a scan of C:, 😨, E:, U:, and V: all in one scan.
This monolithic scan promptly began to detect the malware located in dormant places on pretty much every drive, and the moment it detects one thing, it goes into a more thorough mode, which will invariably slow down the scan as it begins to do extra investigation of files. Even without this extra investigation, doing a Full or Custom scan will invariably result in every byte of every file scanned being read from the disk for the purpose of generating the MD5 hash of the file. Disk performance will impact this of course, as will the older nature of the physical CPU. Combine that with extracting files from numerous archives and you'll note that the impact is even greater, since it's extracting the archives to the temporary folder after the initial hashing, followed by DiskKeeper evaluating the files that were just extracted for fragmentation, after which it then hashes the files that were extracted.
For even more fun, many of the files were double-archived. So you have the overhead of first extracting the .zip from the .rar, followed by extracting the .exe from the .zip. Older computers are not quite as fond of that. I'm even boggling at a case of a file inside a .rar inside a .zip inside a .rar. Bit overkill, maybe.
Regardless, nearly 800,000 files and a day later, the scan was cancelled. Yes, indeed, with extracting that many files from nested archives and processing that sheer a volume of data, it's going to take a long time and quite a bit of CPU on an older computer.
Item: The first scan, run on installation on 6/4/2012, was a deep scan on K7N system first time. It was aborted at 25 hours, only 43% done.
See above. The first scan run was a deep scan that took 7m42s. The scan you are referencing is a custom or full, which the agent specifically recommends against unless you are a network administrator for example or explicitly attempting to inventory the system.
Item: Checking the integrity of a drive with CHKDSK is generally a bad idea, a rookie mistake. The first check to run is for readability of all files – using CDCheck. Ran CDCheck last night, read the drive OK:
Validating the media is only a small part (and the longest part) of running chkdsk. CDCheck will indeed generally validate the readability of the media, however it will not validate the integrity of the file system, which is also important. The second thing that CHKDSK does that CDCheck does not do is communicate with the drive controller at a low level for the purpose of detecting recoverable errors that indicate health issues on the media. If the drive takes two seconds to read a sector but eventually teases the correct data out of it (according to the drive itself), CDCheck will consider that valid. By comparison, chkdsk will flag that as a failing sector and move the data off it while it still can be read. (I'll refrain from pointing out the errors indicated in the CDCheck paste because they may not be related, while by comparison a chkdsk result set is standardized.
Item: False Positives
Without full scan logs to investigate, I can't accurately comment on this. I can surmise, with no information, that there is either a good chance the command.com in question was in a non-standard location and really was a threat, or was hit by a file infector, of which you have a plethora detected in the aborted 25-hour scan that I have logs for.
Anyway, the primary issue that I see in this case is the use of the agent in a manner inconsistent with best practices and agent-given advice. While you can run a full or custom scan, it just generally normally shouldn't be and isn't necessary in common consumer user scenarios.
The recommendation in that situation is to, for normal use, leave it running a deep scan (about 3-4 minutes in your case) and utilize the settings described above to reduce CPU use on the older hardware.
The request for a pause button is (still) currently considered extremely edge-case and better solved with information.
I can't comment much on the alleged CPU usage without seeing scan logs from standard operation, however given that it was extracting four-layer nested archives and hashing everything as per operating parameters on a decade-old CPU that is highly sub-optimal for hashing, I would expect it. That is why the settings are available to reduce the CPU usage in those cases.
I will address the Deep vs Full/Custom in the other thread.
The post you made was very long, so I apologize if I missed anything.
Let's start at the beginning, and when we get to the end, we'll stop. :)
Item: No pause button
The lack of a Pause button is intentional. On the average properly-running computer running default settings and deep scans, the scan takes two minutes or less. The use of custom or full scans is explicitly not-recommended and the agent does, in fact, advise you of this.
Item: CPU Use of 95%
See: Settings -> Basic Configuration -> "Operate background functions using fewer CPU resources" (Applies to realtime operations) and Settings -> Scan Settings -> "Favor low CPU usage over fast scanning" for additional options to reduce CPU use. That being said, the system is running Windows XP on an AMD Athlon XP 2000+ single-core 1.66Ghz 32-bit processor, which was originally released in January of 2002. That's processor technology that's over a decade old. While the program will run on that, just like any application, running on substantially older, lower-end machines will take more of the resources and a longer time. Unfortunately, I can't speak for a diagnosis of the CPU use in the case of the scans as the logs you submitted do not include the actual scan logs, but only have the main program logs.
A deep scan cannot be run on an arbitrary location, mind you, so claiming that a deep scan was run on U: is not physically possible in the agent unless a file on U: is referenced in startup locations or auto-run locations. A quick examination of the logs indicates that the initial scan took 7m 42s to perform its deep scan, and a second deep scan thereafter took 3m 28s, and a third 3m 26s. A Quick Scan finished in 3s thereafter, followed by starting a scan of C:, 😨, E:, U:, and V: all in one scan.
This monolithic scan promptly began to detect the malware located in dormant places on pretty much every drive, and the moment it detects one thing, it goes into a more thorough mode, which will invariably slow down the scan as it begins to do extra investigation of files. Even without this extra investigation, doing a Full or Custom scan will invariably result in every byte of every file scanned being read from the disk for the purpose of generating the MD5 hash of the file. Disk performance will impact this of course, as will the older nature of the physical CPU. Combine that with extracting files from numerous archives and you'll note that the impact is even greater, since it's extracting the archives to the temporary folder after the initial hashing, followed by DiskKeeper evaluating the files that were just extracted for fragmentation, after which it then hashes the files that were extracted.
For even more fun, many of the files were double-archived. So you have the overhead of first extracting the .zip from the .rar, followed by extracting the .exe from the .zip. Older computers are not quite as fond of that. I'm even boggling at a case of a file inside a .rar inside a .zip inside a .rar. Bit overkill, maybe.
Regardless, nearly 800,000 files and a day later, the scan was cancelled. Yes, indeed, with extracting that many files from nested archives and processing that sheer a volume of data, it's going to take a long time and quite a bit of CPU on an older computer.
Item: The first scan, run on installation on 6/4/2012, was a deep scan on K7N system first time. It was aborted at 25 hours, only 43% done.
See above. The first scan run was a deep scan that took 7m42s. The scan you are referencing is a custom or full, which the agent specifically recommends against unless you are a network administrator for example or explicitly attempting to inventory the system.
Item: Checking the integrity of a drive with CHKDSK is generally a bad idea, a rookie mistake. The first check to run is for readability of all files – using CDCheck. Ran CDCheck last night, read the drive OK:
Validating the media is only a small part (and the longest part) of running chkdsk. CDCheck will indeed generally validate the readability of the media, however it will not validate the integrity of the file system, which is also important. The second thing that CHKDSK does that CDCheck does not do is communicate with the drive controller at a low level for the purpose of detecting recoverable errors that indicate health issues on the media. If the drive takes two seconds to read a sector but eventually teases the correct data out of it (according to the drive itself), CDCheck will consider that valid. By comparison, chkdsk will flag that as a failing sector and move the data off it while it still can be read. (I'll refrain from pointing out the errors indicated in the CDCheck paste because they may not be related, while by comparison a chkdsk result set is standardized.
Item: False Positives
Without full scan logs to investigate, I can't accurately comment on this. I can surmise, with no information, that there is either a good chance the command.com in question was in a non-standard location and really was a threat, or was hit by a file infector, of which you have a plethora detected in the aborted 25-hour scan that I have logs for.
Anyway, the primary issue that I see in this case is the use of the agent in a manner inconsistent with best practices and agent-given advice. While you can run a full or custom scan, it just generally normally shouldn't be and isn't necessary in common consumer user scenarios.
The recommendation in that situation is to, for normal use, leave it running a deep scan (about 3-4 minutes in your case) and utilize the settings described above to reduce CPU use on the older hardware.
The request for a pause button is (still) currently considered extremely edge-case and better solved with information.
I can't comment much on the alleged CPU usage without seeing scan logs from standard operation, however given that it was extracting four-layer nested archives and hashing everything as per operating parameters on a decade-old CPU that is highly sub-optimal for hashing, I would expect it. That is why the settings are available to reduce the CPU usage in those cases.
I will address the Deep vs Full/Custom in the other thread.
The post you made was very long, so I apologize if I missed anything.
Kit - Prior Webroot Quality Assurance / Prior Webroot Escalation Engineer
Reply
Login to the community
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.