• Make sure you have a copy of your 20 Character Alphanumeric Keycode! Example:SA69-AAAA-A783-DE78-XXXX
  
• KEEP the computer online for Uninstall and Reinstall to make sure it works correctly
  
• Download a Copy Here(Best Buy Subscription PC users click HERE)
  
• Uninstall WSA and Reboot
  
• Install with the new installer, enter your Keycode and do NOT import any settings if offered by the installer; to as you can set it up as you like once it's done
  
• Let it finish it's install scan
  
• Reboot once again

This is still a problem for me.  Running version 9.0.28.39 and the block/allow list has many entries that point to non-existent directories.

I have home automation system with plugins.  Often when I update a plugin the file is temporarily stored in an ‘update’ directory.  WSA frequently changes the path in the block allow list to the temporary file location, even thought the directory no longer exists after the update is complete.

This means WSA seems to erratically block the installed plugin once it is installed.  My logs begin to show network communication errors.

If I uninstall WSA and reinstall, then re-add all the files to the allow list the problem goes away….until the next update.  So frustrating and makes WSA almost unusable for me.

And yes….I have tried numerous times to remove the entry in the block/allow list and re-add it.  But it always ends up pointing to the non-existent directory…...grrr!!!

I’m disappointed that this problem that way identified 3 years ago is still an issue.

Hello @mminehan 

It’s not a real Block/Allow list like other AV’s as WSA for Consumer doesn’t have one so it’s best to just remove all from the list unless you want to keep and eye on some untrusted programs/apps see here for more info: https://docs.webroot.com/us/en/home/wsa_pc_userguide/wsa_pc_userguide.htm#ManagingQuarantine/BlockingOrAllowingFiles.htm%3FTocPath%3DManaging%2520Quarantine%7C_____2

HTH,

Thanks for the very prompt reply.  I will give it a try.  But I do recall in the past I had issues with this and found that adding exceptions seemed to solve some problems.  But that was quite some time ago.

Anyway, I’ll see what happens after following your suggestion.

M

@TripleHelix Your advice seems to have done the trick as far as I can tell at this stage. 

But it would be good to get this bug fixed as it has been mentioned a few times in these forums. It's not reassuring if WSA exceptions, but especially blocks, and keep pointing at the wrong file. 

Thanks for your help. 

M

Hello @mminehan 

Webroot is always working on improving there product line and that’s great your issue hasn’t come back. I never had any of these issues and I have been Beta Testing WSA in early 2011 when the first version came out in the fall of 2011 and continue to do so.

Cheers,

Yes, this was an issue that bothered me some years ago though the case in issue was not the Block/Allow files but rather the Application Protection files.

The answer* was interesting. The path displayed is sometimes incorrect (which happens, as you have observed, when the real path changes). However notwithstanding this, the Application Protection still works. How can this be? What is happening is this: Webroot does not actually use the path to identify the file to be blocked but rather some kind of internal file identifier independent of the path. Presumably this will also be the case for the Block/Allow list.

Now you may say: Why then does Webroot bother to display the path of the file although that path may sometimes be incorrect or even non-existent? I agree with that sentiment. It seems completely crazy to me. However, I know that Application Protection works even when the path displayed is clearly incorrect, and I know that in the past when I have resorted to using Block/Allow to allow files it also has always worked for me (even though, as Triple Helix says, it is not an absolute Allow as the file, whilst Allowed and not Blocked, will still be monitored by Webroot for your security).

Now in your case, with your plugIns there apparently seems to be a problem. Maybe this is for the reasons that Triple Helix mentions, however if I was in your shoes I would certainly want to contact Webroot Support about this to see if they can help.

Hope that helps.

*not in this thread and unfortunately I no longer have the link

I think it is just messy and makes diagnosis of networking issues unnecessarily problematic. Even if the network/firewall issue isn't WSA the fact that a user sees a link to a path that doesn't exist means they will waste thier time trying to fix an issue that is effectively cosmetic. I certainly did, as have others. 

Surely it can't be that difficult to fix the piece of code that causes this problem, even if it's problem for a small minority of users. After all it has been known about for over 3 years.

WSA is a great product. I have it on 5 machines. But the antivirus software market is very competitive and this kind of thing only detracts from the overall impression of WSA. Over the years I have changed AV products based on ease of use, system overhead and reliability. 

Not a show stopper but this is something that should have been fixed a long time ago. 

I completely agree.