This is going to drive me quite nuts if it continues. When a manual override is placed on a monitored file, it doesn't override it and prevent monitoring. This is Very Bad™ when the monitoring causes the application in question to crash instantly with a BEX. The only solution is to completely shut down Webroot or have no use of the program until TR fixes it. Kind of odd too, since scanning the folder the program is in shows a [G] for the executable, but a deep scan still shows a . Gathering more information as we speak, however it appears that the deep scan and realtime shield are not honoring local overrides while custom scans of folders are.
Hmm... without being accused of giving the most mundane debugging solution imaginable, could you see if rebooting clears it? If the process in question is still active, or perhaps if WSA is still active, it could still be monitored before being refreshed. I'll take a look on my side to see if there's something causing overrides to not be applied properly. Thanks!
Well, along the lines of troubleshooting... 1: Shut down and restarted Webroot. Same behavior with the manually-allowed executable showing up as [G] in a targeted scan of the folder and in a Deep Scan. 2: Since the process crashes with a buffer overflow exception on start when Webroot was on, there was no way for the process to be still running. 3: As an additional test, I used Process Explorer to investigate all DLLs and file handles opened by the process and check them in Webroot's Deep and Targeted scans, just in case an nknown bit of code was being injected. But no luck there, everything came back clean. 4: If the process was started with Webroot shut down, and then Webroot was started thereafter, the process would not crash, but also never reached Type 8. When Webroot was started while the process was running, it was only monitored Types 3 and 4, however the MD5 matches the override: Wed 2014-04-02 14:34:21.0283 Determination flags modified: c:\zenimax online\the elder scrolls online\game\client\eso.exe - MD5: D5709A10A56AB0FAE78B11E79C23BA84, Size: 31373312 bytes, Flags: 00000100 Wed 2014-04-02 14:34:37.0791 Monitoring process C:\Zenimax Online\The Elder Scrolls Online\game\client\eso.exe [D5709A10A56AB0FAE78B11E79C23BA84]. Type: 3 (16481) Wed 2014-04-02 14:34:37.0791 Monitoring process C:\Zenimax Online\The Elder Scrolls Online\game\client\eso.exe [D5709A10A56AB0FAE78B11E79C23BA84]. Type: 4 (16481) Wed 2014-04-02 14:34:37.0950 Monitoring process C:\Zenimax Online\The Elder Scrolls Online\game\client\eso.exe [D5709A10A56AB0FAE78B11E79C23BA84]. Type: 8 (16481) The process instantly crashed as soon as Type 8 was performed by Webroot. TR has since determined the file, however based on other users of the file making reports, it was not a situation unique to me. Of course I also have taskmgr.exe being monitored Type 1 on a regular basis, so I can't say things are behaving normally necessarily.
The same happens here with this legitimate tv streaming app. I tried to allow the .exe and all associated .dll files (more than 20) but it crashes whenever I open it unless I shut down WSA: Sun 09-03-2014 17:31:37.0203 Monitoring process d:\programas\canal+ yomvi\canal+ yomvi.exe [5D7FA5CFA13144DFC894758FC7C12A5A]. Type: 9 (2353) Sun 09-03-2014 17:31:37.0203 Monitoring process D:\Programas\CANAL+ YOMVI\CANAL+ YOMVI.exe [5D7FA5CFA13144DFC894758FC7C12A5A]. Type: 3 (2353) Sun 09-03-2014 17:31:37.0203 Monitoring process D:\Programas\CANAL+ YOMVI\CANAL+ YOMVI.exe [5D7FA5CFA13144DFC894758FC7C12A5A]. Type: 4 (2353) Sun 09-03-2014 17:31:37.0203 Monitoring process D:\Programas\CANAL+ YOMVI\CANAL+ YOMVI.exe [5D7FA5CFA13144DFC894758FC7C12A5A]. Type: 5 (2353) Sun 09-03-2014 17:31:37.0203 Monitoring process D:\Programas\CANAL+ YOMVI\CANAL+ YOMVI.exe [5D7FA5CFA13144DFC894758FC7C12A5A]. Type: 7 (2353) Sun 09-03-2014 17:31:37.0468 Monitoring process D:\Programas\CANAL+ YOMVI\CANAL+ YOMVI.exe [5D7FA5CFA13144DFC894758FC7C12A5A]. Type: 8 (2353) Sun 09-03-2014 17:31:37.0468 Monitoring process D:\Programas\CANAL+ YOMVI\CANAL+ YOMVI.exe [5D7FA5CFA13144DFC894758FC7C12A5A]. Type: 6 (2353) Sun 09-03-2014 17:31:38.0796 Monitoring process D:\Programas\CANAL+ YOMVI\CANAL+ YOMVI.exe [5D7FA5CFA13144DFC894758FC7C12A5A]. Type: 3 (2353) Sun 09-03-2014 17:31:38.0796 Monitoring process D:\Programas\CANAL+ YOMVI\CANAL+ YOMVI.exe [5D7FA5CFA13144DFC894758FC7C12A5A]. Type: 4 (2353) Sun 09-03-2014 17:31:38.0796 Monitoring process D:\Programas\CANAL+ YOMVI\CANAL+ YOMVI.exe [5D7FA5CFA13144DFC894758FC7C12A5A]. Type: 5 (2353) Sun 09-03-2014 17:31:38.0796 Monitoring process D:\Programas\CANAL+ YOMVI\CANAL+ YOMVI.exe [5D7FA5CFA13144DFC894758FC7C12A5A]. Type: 7 (2353) Sun 09-03-2014 17:31:38.0875 Monitoring process D:\Programas\CANAL+ YOMVI\CANAL+ YOMVI.exe [5D7FA5CFA13144DFC894758FC7C12A5A]. Type: 8 (2353) Sun 09-03-2014 17:31:38.0875 Monitoring process D:\Programas\CANAL+ YOMVI\CANAL+ YOMVI.exe [5D7FA5CFA13144DFC894758FC7C12A5A]. Type: 6 (2353)
Another override that does nothing: I have just updated to the latest version of Malwarebytes Anti Exploit and WSA blocks it from loading in Chrome. The scan log shows this block: mbae.dll [Type: 11] I try to allow that file and the rest related to MBAE but the issue persists.
I have never been able to have a file whitelisted that way (including those in my post from two months ago, I still need to shut down WSA to use that streaming service), but I'll try again.