I don't need a tutorial on how to use Webroot's Block Allow Files.
In short, when I add a particular executable to Webroot's allow list, Webroot displays that executable as being in a directory that no longer exists on my computer.
This might be confusing because I blotted out certain directory and executable names for privacy, just bare with me please.
After I click to add a file in webroot, this is the directory I navigate to, and the executable is selected.
After I hit open, the block/allow files page shows up looking like this, with the bottom file supposedly being the one I've just added.
The directory that webroot is pointing to doesn't even exist on my computer anymore, it's pointing to the folder that executable was originall in when I downloaded the file, which I have since deleted.
I've cleaned up my registry and restarted my computer, but webroot is still pointing to the wrong directory.
Allowing these files through webroot is not doing anything, webroot is still closing the files instantly as i try to launch them without giving me a notification. Webroot is my only antivirus and the only firewall I have active. When I completely shut webroot down all of these executables launch completely fine with no problems.
If anyone has any idea what the problem could be here please let me know.
Best answer by Baldrick
Hi HoboNoah
Welcome to the Community Forums.
If I may add here...whilst I have heard of this 'issue' before I made a quick check of what you said in my systesm and can find no evidence of this happening to me. So it may just be related some particualr aspect of your set up...but either way that is not how things are supposed to work.
May I suggest that before the support ticker you try an uninstall/clean reinstall to check that the issue is not caused by a faulty installation or update? If you would like to try this then please follow the steps below closely!
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
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
Once all of that is done try checking things out again and seeing if you can reproduce the issue again. If not then all is well but I would still monitor for a reoccurrence. If you can reproduce the issue then I would open the support ticket as previously advised.
I'm sorry that your going through this difficult. I would sugguest you open a support ticket here https://www.webrootanywhere.com/servicewelcome.asp#and include a copy of your post that explains everything.
I hope this helps. Do post back here what support tells you.
If I may add here...whilst I have heard of this 'issue' before I made a quick check of what you said in my systesm and can find no evidence of this happening to me. So it may just be related some particualr aspect of your set up...but either way that is not how things are supposed to work.
May I suggest that before the support ticker you try an uninstall/clean reinstall to check that the issue is not caused by a faulty installation or update? If you would like to try this then please follow the steps below closely!
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
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
Once all of that is done try checking things out again and seeing if you can reproduce the issue again. If not then all is well but I would still monitor for a reoccurrence. If you can reproduce the issue then I would open the support ticket as previously advised.
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.
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.
@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.
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.
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.
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 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.
