** INTRODUCING: NEW BETA VERSION OF AVAST - NOW 6.0.1198 **

[spg SCOTT]

Am I the only one that is having trouble with exclusions not working?

http://forum.avast.com/index.php?topic=80315.msg661298#msg661298

[DavidR]

Well the exclusion would have to be on the object, as that is what is being detected. Malzilla.exe is only the process accessing/running the file/object.

Given the object name I rather think you haven't got that excluded and exclusions don't extend to what a file is doing only to the actual file itself.

[spg SCOTT]

The exculsion has always worked (the malzilla cache), and is this:

C:\Users\myname\Portableapps\malzilla_1.2.0\cache\*

In the these betas, it doesn't work.
I get a detection on: C:\Users\myname\Portableapps\malzilla_1.2.0\Cache\44d88612fea8a8f36de82e1278abb02

My other exclusion for C:\Suspect fails too...

[aglennon]

Hello - Have used Avast forever - never a problem until now.  I'm getting the impression that older systems are no longer going to be able to run Avast.

The BSOD is DRIVER_IRQL_NOT_LESS_OR_EQUAL Stop: 0X000000D1   The BlueScreenView shows Stop code differently for some reason:  Bug Check String is 0x100000d1  Not sure how to read BlueScreen data but the files in pink in lower window show hal.dll, hpt374.sys (hpt366.sys on other pc), ntoskrnl.exe and scsiport.sys

These crashes have occurred repeatedly since updating to 6.0.1125 and even with the new Beta 6.0.1148.  They tend to crash if the Welcome sign-on screen sits for about 10 mins.  Other times random BSOD.  It's the same crashes on two different machines.  Abit IT7 with two 250GB HD's and maxed RAM at 2GB, ATi Radeon 9600.  The other is Abit BE6 with 40GB HD and maxed RAM at 768MB, ATi Radeon 9200.  Two totally different chipsets, both systems have ran fine from day-one.  The only thing they have in common is both are XP Pro (SP3) and they both have Avast, ZoneAlarm Firewall, WinPatrol (did use TeaTimer from Spybot but disabled it to rule out).  I'm suspicious of XP Pro, because the other pcs that are running new Avast fine are an Abit IC7 (XP HOME) and an HP G71 laptop with Win7 64-bit.  No problems whatsoever.

It's the two older machines that have crashed so much that I finally had to give up and remove Avast!  I have fought with this for about three weeks now.  Tried every trick I know.  Have double-checked Windows Update (even installed "optional" updates to be sure) everything available is installed.  Have used SafeMode and Uninstalled Avast and ran the Avast Cleaner, restarted and even manually searched the registry for any remaining avast or alwil entries.  Also tried the Avast "Repair" option.  Have reinstalled 6.0.1125 and 6.0.1148 several times after cleanups.  Made sure both pcs were clean (as they always are) have ran DiskCleanup, Defrag, Scandisk, kept Internet Options cleaned out and ran CCleaner.  Have ran Spybot, Malwarebytes, Superantispyware (each even in SafeMode) and I've ran these disconnected from the Internet, just like I would if I were cleaning out an infected computer.  Have ran Avast Boot-time scans too since it finds the tough malware outside of Windows.

The Abit BE6 is old but I've never had any problems with it.  Yes, it's slow and it's rarely used, but I've always had Avast on it and never a problem until updating to 6.0.1125 and the Beta.  It's odd that the Abit IT7 has the same exact Stop codes, as well.  Why is the Abit IC7 unaffected?  I built each of these Abit systems and have had no hardware issues.  I keep tabs on any driver updates, especially ATi (AMD now) but they rarely release video updates now.  No RAM issues as MemTest86 is clean.

And thanks to all of the years that Avast has protected us so well.  We've never had any trojans/viruses, nothing.  But now, I guess as our machines get older, XP is going to start having issues as websites and applications begin to stop supporting this old O/S and that's when we start having problems.  It'll soon be like trying to get Win98 to work online now.  We can't afford to go out and buy new Windows.  Since both machines that run XP Pro have the same mysterious issue, I tend to think the crashes may have to do with some Windows Update between May and June - just a guess.

Thank You,
Alicia

[pk]

@aglennon, please send me the latest minidumps from \Windows\Minidump folder (kurtin@avast.com). Thanks.

[Asyn]

...and they both have Avast, ZoneAlarm Firewall...

I would drop ZA.

[Nesivos]

I suggest you test compatibility with Raxco PerfectDisk 12 Professional on Windows XP SP3 32bit.
For as long as i had this AIS beta installed, my netbook was grinding HDD badly on startup, everything took ages to open, PerfectDisk couldn't perform boot defrag. After i've removed avast!, everything was working again. I'm donwloading AIS beta again to doublecheck.

EDIT:
Not sure which avast! component exactly is causing it but yeah, i can confirm it's reproducable.
Installed it 3 times and each time after installation, awful HDD grinding and really bad performance. After i've removed it, everything was fine again. The latest stable version however doesn't seem to exhibit such problems...

I used Perfect Disk for years up through PD11 Home Premium.   I thought PD11 HP was buggy and start-up both W7 x32 and x64 took a long time.  I finally dumped it and replaced it with Smart Defrag. (It is free).  I have been using Smart Defrag for a few months and it does the job for me.  A lot lighter on resources and boots and restarts are faster.  JME

Well, that still doesn't change the fact that PerfectDisk 12 Pro was working fine with current stable version but doesn't with this beta which means there is something wrong with this beta.
Plus you can't just expect all the users not involved here to just stop using PerfectDisk because you happen to prefer SmartDefag. I've tried it and it's not bad but some will just prefer PerfectDisk and if they do, it has to work properly with avast!.

I don't believe in your post that I quoted that you mentioned PD had been working perfectly on computer with a previous version of avast!.  If you had and I had seen it I wouldn't have posted my response.  From all I knew from the post of yours that I quoted you had just starting using PD.

In addition when I used PD11 HP with a previous version of avast! I found PD clunky and it slowed down the computer's start-up etc.  I then switched to Smart Defrag about 3 - 6 months ago and I have not any of the HDD and memory usage problems that I had with PD11 HP and avast!.   

Bottom line:  When I removed PD11 HP my system showed noticeable improvement.  I never had to remove avast!, just replace PD11 HP with Smart Defrag and my computers' performances improved significantly.

[RejZoR]

Well, i have removed avast! beta after finding this problem and installed back the stable version. It's running just fine as we speak. I've verified it twice. It's not a random glitch that sometimes happens and is gone after you reinstall avast!. Every time i installed this beta along with PD12, HDD LED on netbook wasn't just blinking during startup as usual, it was on continuously for like 5 minutes. Everythng was slow during that time and PD12 interface took like 3 times longer to start with avast! beta installed than without it. And whatever i did it started grinding HDD badly, as much that HDD LED light was again continuously on, which usually never is.
If stable version works fine with PD12 and avast! beta doesn't, there is something wrong with avast! beta.

[NON]

Am I the only one that is having trouble with exclusions not working?

http://forum.avast.com/index.php?topic=80315.msg661298#msg661298

I am on the same boat...

[Vladimyr]

@aglennon
You're probably not going crazy

I've had a similar ongoing problem with every avast! 6 release on just the one XP Pro SP3 machine (and I'm not running ZA, Asyn). Every other machine I know of with AIS 6.0.1125 is fine, W7, Vista, XP Home & Pro but unfortunately it's my main PC that has the issue and so it's with mixed feelings I report that I've not had a single BSOD in the last few weeks since I've 'temporarily' changed to another AV while waiting for a 'breakthrough' in the next avast! release.

[pk]

Am I the only one that is having trouble with exclusions not working?

http://forum.avast.com/index.php?topic=80315.msg661298#msg661298

@spg SCOTT & NON, already fixed, thank you for your feedback!

@Vladimyr, we're working on this off the forum.

[Hermite15]

cancelled scheduled full scan is running

I cancelled it earlier today, and at the exact time when it was scheduled to run, I noticed (and still do, as that's now )a strong hard disk activity, confirmed by Avastsvc CPU load in task manager. The scan doesn't show in avastUI but it's definitely running.

[Vladimyr]

@Vladimyr, we're working on this off the forum.

I figured that you were.
I'm not bitter, just disappointed - and seeking to give a slightly more encouraging response to aglennon's problem than Asyn's well-meaning non-solution "drop ZA". (Sorry Asyn )

[sandeep108]

That's simple - the  "wouldn't exist" means it wouldn't be possible to have it even for US users. There is only one build of avast!, one installer - and it's not going to change (it would make many things rather complicated, both for the users and for us). Therefore, there has to be, and will be, checks for installed features inside (be it the various shields, language modules, Sandbox, SafeZone, firewall, antispam, webrep, Vista gadget... or anything else). It's the same as checking for the version of the operating system - that's also done on every start (instead of having separate installers for Windows 2000, Windows XP before SP2, Windows XP after SP2, Vista 32bit, Vista 64bit... that would be crazy, and you might have to uninstall and install a "new" product after updating your service pack, for example). Or, checking for the installed programs (Is Outlook installed? Fine, let's use the mail-scanning plugin. Is the filesystem NTFS? OK, let's use the persistent cache. Etc...)

The thing is that the mere considering such a check a problem is kinda ridiculous. The program performs thousands of similar checks on every start, new virus definitions regularly add operations that are orders of magnitude bigger and slower than that... and nobody notices. So this common one-microsecond check can hardly fit the MIB analogy, as you aren't bothered by that, and actually have no way of telling whether such a check has happened.
So this is not "fighting hard to leave the code inside" - it's fighting against doing a completely illogical thing (from the programming point of view) which would take effort to implement, increase the complexity of the code (bringing some more bugs), increase the size of the code - and in the end, the result would actually be exactly the same as it was before, just with one additional checkbox visible somewhere.

As for the "bad feeling"... well, not sure what to say about that. I'd probably just point out that the antivirus already checks files on your disks for malware, redirects and scans your network connections for malicious code, checks your e-mail... which is where the sensitive data really are, and nobody seems to have a problem with that. Yet a simple feature which does nothing at all when not registered, and when it is registered it only receives data, doesn't send anything anywhere... is suddenly a problem. I mean, we are trying to protect your data, not to compromise them... but if we (or any other antivirus or security program you might have installed) really turned "to the dark side" and wanted to harvest your private data (or whatever else that this bad feeling might include), it would be rather stupid to add a new suspiciously sounding feature to do that - when all the necessary mechanisms are already there for years.

Anyway, this is not my "decision" (and my work also doesn't include this particular feature), it was just my attempt to explain the technical background (i.e. basically a personal opinion of somebody who knows a bit about avast! internals). However, since it doesn't seem to be going anywhere, I suppose that's the last input from me on that topic as well.

You can keep defending this, but I still feel that if you keep adding 10 such features that we do not want, that 1 millisecond becomes 10 and I get another 10 log files hitting my SSD and so on and so forth. Then how is avast different from Norton or AVG who seem to take over me and my system? While I trust avast and have also paid for it, I, DavidR and others outside US feel that this is simply not done.

Please keep the installation code of this feature and others that avast may dream of, completely separate from your core AV program. I really do not want it on my system at all. Initially it was said there is only 10kb of code. And it does not get activated till it is opted in. But then we find that there is a start-up check as well. Then we find that there is a log file as well. Then there is talk of hiding the log file so that we do not know about it. What else is there in this 'feature'? even if not opted in?

I am sorry but this attitude and these replies does not help me to keep trusting avast.

[igor]

Please keep the installation code of this feature and others that avast may dream of, completely separate from your core AV program. I really do not want it on my system at all. Initially it was said there is only 10kb of code. And it does not get activated till it is opted in. But then we find that there is a start-up check as well. Then we find that there is a log file as well. Then there is talk of hiding the log file so that we do not know about it. What else is there in this 'feature'? even if not opted in?

I believe you don't understand what I'm trying to say (or possibly can't imagine how it looks like in the machine code, I don't know).
It doesn't get activated till it's opted in - and the check we're talking about is exactly the check whether it has been opted in or not, i.e. whether it should be activated or not. Turning it into a check "whether it has been installed or not" - is just calling the operation by a different word, without any change into the code. It simply has to be there, no matter how it's called (btw, I was talking about microseconds, not milliseconds, and even that might have been an exaggeration).
OK, this single check might be a bit too verbose in the current build, logging even the fact that it's being performed (which is kinda an overkill) - so the logging will be removed.