Printable View
So this is odd...
I'm trying to run an AV scan on my machine with CA eTrust AV. It keeps freezing during the scan. I've booted up in safe mode, and it still freezes.
It's interesting where it froze up. I saved a copy of an Office 2003 cd on my desktop so that I could make a backup copy. The scan is hanging up somewhere in C:\...\Office 2003\FRONTPAGE\...
Get out of that scan, configure to avoid desktop, try again ...............:)
Get out of that scan, configure to avoid desktop, try again ...............:)
Hi,
1. How long have you left it.
2. Are you running resource meter............what is happening.
I have seen several AVs "choke" on huge compressed files.
You might look at your total RAM, and how much virtual memory you have allocated ;)
:)
Here's what I would do:
1. Get filemon ready.
2. Set eTrust to only scan that folder where it's hanging up.
3. Start filemon
4. Start eTrust
5. Check filemon logs for particular activity.
As mentioned, it could be a hugely compressed file, a corrupted file, or simply not enough time given to complete the scan based on the particular sized files in that folder.
I've noticed that some scans will *lock* up with not-responding but if I just left them alone they finally come around.
YMMV.
Eyup. It happened to me also (THE HANGING WHILE SCANNING) with Norton AV when passed by a large backup file (.ZIP FILE). Side-note: Especially with NAV (that eats a lot of resources in the first place).
By-The-Way, have you tried visiting CA's support site? Maybe they have something about the 'HANGING' issues.
-GONE
That did it. I told the scan to skip that one compressed file, and it ran successfully. Thanks!
In task manager, as often as not, "not responding" is a lie.... and whoda thought M$ would lie to you.... :rolleyes:Quote:
not-responding
It seems to be the result of a badly written App/routine that gets so "tied up in itself" it fails to make some required system calls that tell task manager that it is actually working or it fails to respond to the system calling it for the same reason - I have no idea which.
I first came across this "phenomenon" several years ago while programming some rather large databases in Access, (Yes, I know that was my mistake - but it's what I know and thus what I'm stuck with if development time < my lifetime.. ;)). I had to make large queries of the database across a complex set of tables sometimes with subqueries involved. They would take forever and I would think it had hung... Checking the task manager indicated "not responding" so I would kill the app thinking that I had screwed up the query. One day, after killing the app about 10 times I was called away for an hour, when I returned the query had completed.... Wrongly because of the changes I had made to "fix" it - but it had completed even after showing me "not responding". At that point I knew M$ was lying to me and I had to be more patient or, as Nihil, just stated in a diferent thread, cheat.... I created subsets of the data to test the queries before I tried them on the entire dataset..... it made my life much less stressful..... ;)
Never trust a "not responding" for an app in task manager.... look at the processes and see what the CPU usage is.... If you can make it fluctuate from 100% by doing something else the app is absolutely running fine.... It's just hogging resources and not "playing the game".
Hey Hey,
While what Tiger Shark is saying is true.. MS quite often lies about things that are "not responding" but in the case of eTrust this is a common problem. It seems to almost always be MS Office .cab files... and apparently the eTrust SP1 fixes the problem. Since appying it we haven't had any more user complaints, however that doesn't mean it isn't happening, we might just be lucky.
Peace,
HT
Darned right - if you're running eTrust 7.0 you''ll need SP1 which brings you to product version 7.0.142. The pre-SP1 eTrust (7.0.139) is very buggy and eats all your processor cycles when daylight saving time starts! Nice.Quote:
..and apparently the eTrust SP1 fixes the problem.
Most of people think that "Not responding" means "program hangs". That IS NOT true.Quote:
MS quite often lies about things that are "not responding"
Its not a Microsoft mistake. Instead, its a user mistake about the meaning of the message.
Every process that has a windows should "react" to windows events in a given time (i cant remember know how much time). When Windows detects that is a lot of windows events enqueued to a process, it marks that process as "not responding". When that queue fills up, Windows windows manager (or event manager i dont remember) just stop to try to send new events to that windows.
The kind of message is more a bad windows design (from the software vendor) that a Windows problem. When you write a Windowed process, you should give, from time to time, some process cycles to your windows task. On AK example (AntiVirus), AV is goind deeply on a nested packed structure (such as .cabs) and just stop (for a while) responding the "click" events (or other windows events, such as minimize, move and so on).
Never think that "not responding" means that "program stucked" and end it. Most of the times, is just a transient state.