Some background, I did a clean install of AIS on the PC in my sig. When I do a clean install I normally leave the firewall set to auto decide and after several days set it to ask. The only change to the firewall settings I made was to show notifications of newly created allow rules. What I’m finding is the firewall will intermittently create rules for programs that already have rules. The rule created will have the same exact settings as the existing rule. This seems to happen after boot up as it did today. If I remember correctly version 6 also had this problem.
Bill
I only have the issue with IE9 on W7, using beta build 1414 … repeated popups for newly created rules each time I launch it … never happened in V5/6 or previous versions of V7.
I wish it was only with a single program. Today it happened with five programs after booting my PC. Nothing was changed to cause this to happen. This also happened in Version 6 and possibly 5. I changed the firewall to ask then deleted the duplicates and forgot about it. I was just looking at the duplicate rules while writing this post and noticed for each double one shows complete details, description, company and signed by. The second entry is blank and signed by says no signature. This does not seem to cause problems but its sure weird. I never see more than doubles even though I have seen rules created for the same thing more than twice since installing 7.0.1407. The firewall even doubles Avast itself.
Looking closer it seems the firewall thinks these added rules point to a drive other than the drive windows is installed on. Windows is installed to C:\ and the firewall sees a path of S:. This is an external backup drive BTW. This drive is normally only on when backing up files. Last night I forgot to shut it off so it was on when I booted my PC today. None of the paths on S:\ exist. This is getting weirder by the second. I’m going to shut down then boot up with the external drive off and see what the rules look like.
Bill
Booting up without my external drive gives results I never expected. The rules that were pointed at my external drive S:\ Now point to my D:\ drive. My D drive is a second physical internal drive I install all large programs to, like games. None of the paths shown in the shall we say ghost rules exist on my D drive.
Shakes head,
I think I will delete all firewall rules followed by a reboot and see if I can reproduce this behavior.
Bill
After deleting all the rules and allowing AIS to rebuild the rules I ran check disk on all my drives including the external, no problems found. No ghost rules were added for several days with out my external drive in the picture. As soon as I boot my PC with my external drive on AIS adds ghost rules again. Turning the external drive on while windows is booted does not cause ghost rules to be created BTW. All I can say is there is a bug and it needs fixing. I can’t believe I’m the only one that has seen this problem.
Bill
Why not update to 7.0.1426, the latest version and see if the ghost rules you see are resolved. Or if you have modify the first posts title to reflect that this is still present in 7.0.1426.
I was running 7.0.1426 during the testing in my last post, subject updated to reflect so.
Bill
Hi, this seems to be a little different problem than the one Logos reported to me a few days ago.
In fact, this has a pretty easy explanation. The paths are stored in a way that kernel drivers understand them. So, and as you can verify, there are no drive names in the rules.xml file, where the rules are stored, instead links to the partition numbers on the disk are used instead of the drive names.
This is easier for the kernel component to find the files, and also gives some extra flexibility - when drive letters are changed, as long as the partitioning remains the same, the rules are still valid. In your case, however, adding and removing that external drive changed the partition numbers so much, that the entries were no longer found on the disk (i suppose you must have started the system once from the backup drive and let the rules be populated from that partition, or the disks must have somehow changed their places, boot order, etc.
So, once booted, your C: drive referred to e.g. the partitionnumber3, after reboot and disk configuration change, your C: drive ended on partitionnumber2 and 3 was now your drive with the letter S:, latter again with the disk removed, you ended up with D: letter occupying the partition with that number.
There are several disk identifiers available for the developer to choose from, either disk letters, partition numbers or even partition guids. For this specific example, I guess disk letters would work better, but there are other situations, where you might find nice that you can change the drive letter without invalidating all the rules.
Lukas
I looked into what you are saying as I was thinking the same. My 80 gig SSD is my boot drive aka C:. It is always ID’d as disk 0 in device manager and is on the Intel controller port 0. My other internal hard drive is a 500 gig WD partitioned 200 gigs as D:\ and 265 gigs as E:. Is always ID’d as disk 1 in device manager and is on the Intel controller port 1. I have 2 optical drives also on the Intel controller ports 4 and 5. The external drive is on a third party eSATA controller and ID’s as disk 3 in device manager. I have not tracked partition numbers or GUID’s. Might look into it but I have spent enough time already. In general its a bad idea to change drive letters on any drive that has programs installed on it. IMO Avast should look at drive letters not partition numbers or GUID’s. If someone goes through all the work the change drive letters on a program drive they can spend the time to fix the firewall rules one time. The way it is now my firewall rules get whacked every time I boot my PC with my external drive powered on.
Oh and no the only drive that is or has ever been bootable is my 80 gig SSD.
Bill
I did some testing last night on a friends PC that also runs AIS, W7 64 and has eSATA. This PC has never had an eSATA drive connected to it before. Having the eSATA drive powered on before boot up causes the same problem I see on my PC. This leads me to believe that the cause of the problem is bios or Windows related. Neither of which I would guess are fixable. Most likely by design. Avast needs to rethink their method of ID’ing drives. All I can say is this needs to be fixed. My 3 PC license expires in September and if this problem is not corrected before that time I will be forced to find a replacement.
Bill
Lukor I would think more people have external drives causing ghost rule problems than people wanting to change drive letters on drives that have programs installed on them? The average PC user would never change drive letters and power users would know better than to try/
Bill
I guess you are right, we will change this! Thanks, I must admit I haven’t realized the partition numbers do change with eSATA drives. I guess it is kind of a bad luck - meaning with different disk layouts/partitioning this might no happen, but still this seems to be a problem.
Thanks for helping me nail down the problem and also for the promise of a fix for it at some point. I wish all software developers were half as good as the Avast team and thanks for the great products!
Bill