Solved

Webroot doesn't like Google Chrome.

  • 7 February 2013
  • 23 replies
  • 9179 views

I'm trying to open Chrome and nothing will load! While this is going on a little lock appears on the Webroot logo. I think that Webroot doesn't like Chrome. What do? Please respond as soon as possible.
icon

Best answer by RetiredTripleHelix 7 February 2013, 05:45

View original

23 replies

Userlevel 7
Badge +56
Hello call541 and Welcome to the Webroot Community Forums.
 
Have a look at this Online Help file and make sure Chrome is under "Protect" and if it is and still doesn't work try under "Allow" and please report back.
 
TH
Nope, still nothing though the lock is gone. It's not my internet, otherwise I wouldn't be talking to you.
Userlevel 7
Badge +56
OK lets check if it's being blocked by the Firewall and also check if it being blocked here. If it's not being Blocked your going to have to Submit a Support Ticket for further help as they can gather some scan logs.
 
TH
Userlevel 7
The lock just signifies that the app is protected by the Identity Shield. Right-click Webroot and shut it down temporarily in your system tray. Then reopen Chrome. If Chrome still doesn't open, this issue does not involve Webroot causing the problem.
We have had this issue this morning and the it seems Webroot is blocking chrome dll files in the Identity Protection > Application Protection list.
 
The dll's blocked were (windows 7):
  • chome.dll in c:users<user>appdatalocalgooglechromeapplication31.0.1650.57
  • chome.dll in c:users<user>appdatalocalgooglechromeapplication32.0.1700.107
  • chome_child.dll in c:users<user>appdatalocalgooglechromeapplication32.0.1700.107
added them to allow and all fine again.
I have that exact problem too. Webroot blocks Google Chrome and also the different google docs applications. They don't even start.
 
abpbm's solution helped me so thank you very much.
Userlevel 7
Badge +56
@ wrote:
We have had this issue this morning and the it seems Webroot is blocking chrome dll files in the Identity Protection > Application Protection list.
 
The dll's blocked were (windows 7):
  • chome.dll in c:users<user>appdatalocalgooglechromeapplication31.0.1650.57
  • chome.dll in c:users<user>appdatalocalgooglechromeapplication32.0.1700.107
  • chome_child.dll in c:users<user>appdatalocalgooglechromeapplication32.0.1700.107
added them to allow and all fine again.
@ wrote:
I have that exact problem too. Webroot blocks Google Chrome and also the different google docs applications. They don't even start.
 
abpbm's solution helped me so thank you very much.

Hello abpbm & michelerosa and Welcome to the Webroot Community Forums!


 
I asume that Chrome has a new updated version out as I don't use Chrome? Can you please Submit a Support Ticket so they can get the new updated files whitelisted and that should solve your issues.
 
Thanks,
 
TH
The problem is not related to a new version of Chrome, it is something Webroot
just pushed out sometime between Saturday (Feb 1, 2014) and Monday night.  
I have not installed a new Chrome for many months.
 
On one of my windows 7 boxes last night, Chrome just stopped working.
I tried removing it and reinstalling a few times but it just never came up.
It never showed up in the task manager.  I was getting to thinking I would
need to do a full Windows 7 reinstall to clean up the machine.
Thanks to abpbm for identifying a cause.
In my case, besides two (slightly different) chrome.dll files and the chrome_child.dll, 
it was also "Deny" on setup.exe in c:usersxxxappdatalocaltempcr_53580.tmp
which I suspect is related to me trying to reinstall Chrome.
 
On the other windows 7 box, when I started Chrome I got the message 
asking if I wanted to install the Webroot Filtering Extension.   I declined,
and Chrome continued working.
 
I'm guessing that the Webroot Filtering Extension was already installed on
the first box, but not on the second, and when the webroot secureanywhere
update came out it blocked Chrome on the first box but tried to install the
filtering extension on the second box.  Just a guess.  
 
-CEM
 
Userlevel 7
Badge +56
Hello bendyarm and Welcome to the Webroot Community Forums!


 
Well I suggest you contact support also so they can have a look at your logs so they can nail down the issue.
 
Thanks,
 
TH
Userlevel 7
Badge +56
I forwarded this to the support team as well, just in case.  That way they can see which files need to be whitelisted.
Userlevel 7
I have been trying to re-create this issue myself but I cant replicate the issue. I use Chrome on two working PC`s and my home PC and havent had this issue. Even in the cases that I have seen the files have been good in the DB. If you have this issue please send in a support ticket so we can collect some logs.
Userlevel 3
Badge +12
Note how support does responsively act to whitelist & take care of any of these "problems." By the way, a note to the Chrome users having problems, I use Chrome with Webroot and have no problems at all, but I also use HTTPS, AdBlock, and Disconnect. When one suddenly has problems it's easy to understand the frustration and blaming Webroot (especially if you just recently installed or configured it), but my experience has been that Webroot Support is beyond excellent, and even more importantly, will work with you promptly to get to the bottom of your problem.
So its pretty odd because only moms computer has this issue. Event though we both have the plugin, win7, and similar computers. Only difference is mine is 64 and hers is 32.

We tried uninstalling, reinstalling, running as admin, running in safe mode, changing settings for firewall, manual shutdowns...etc but nothing worked until we did one more reinstall, restarted the computer, and then instead of installing the way we tried before, we did the offline install.

Somehow that did the trick, my only thought for why this happened had to do with webroot. So when it asked id we wanted to enable the plugin to install once chrome opened up we said to delete it. No problems so far, Ill update if it goes down again. Otherwise its the webroot, or that you can now switch between two google accounts on chrome. So we also made it only sign in her main.
Ever since I installed Webroot I've been getting "Authentication Errors" when using Gmail. Gmail itself appears to be working fine but the error messages are getting bothersome.
 
Anyone have any ideas??
Userlevel 7
Badge +62
Hello and Welcome to the Webroot Community Qasla820.
 
Sorry to hear you are having this issue. From my research I did find this
 
If you feel this is Webroot related please Submit a Support Ticket and they will check this out for you. Free of charge.
 
 
Hopefully this helps?
Userlevel 3

Wow. I found this thread while googling the topic.  8 years later and Identity Shield still blocks Google Chrome from opening.  All clients on the latest update that supposedly fixed it (9.0.30.72).  The annoying thing is when it intermittently affects random machines, so the only recourse is to disable it for the entire domain.  Sure wish they’d get this fixed!  :’(

This is the third or fourth time over the past few years I have had to fix this issue with Webroot and Chrome in one way or another.  I tried Bit Defender for a while and it was always in my face needing input or blocking something innocuous.  I don’t know what the issue is between Webroot and Chrome that this keeps happening, but it is getting old.  I spent an hour yesterday “fixing” it, then gave up and disabled Webroot, then spent 2 hours today, also giving up.  Moving on to another AV.  I have too many reasons to keep chrome and not enough reasons to keep Webroot.

Userlevel 7
Badge +33

@aprayzr 


Ensure you have the 9.0.30.75 PC agent version.

 

Perform an uninstall of the product and ensure you delete the WRCore and WRData folder under ProgramData if they’re still there after an uninstall. Also delete any Webroot folder under ProgramFile and ProgramFiles (x86).

Reboot, then perform a fresh install with the 9.0.30.75 version. That has the fix for the Chrome issue.

Hope this helps

John​​​​​

@aprayzr


Ensure you have the 9.0.30.75 PC agent version.

 

Perform an uninstall of the product and ensure you delete the WRCore and WRData folder under ProgramData if they’re still there after an uninstall. Also delete any Webroot folder under ProgramFile and ProgramFiles (x86).

Reboot, then perform a fresh install with the 9.0.30.75 version. That has the fix for the Chrome issue.

Hope this helps

John​​​​​

 

So, this solution = every time we run into this problem? Not a real solution

Userlevel 7
Badge +33

Well it works. 

Of course calling support so that the more people report the issue, the faster they’ll work on the fix is always best as well. 

Support ticket opened as this has happened several times this week for multiple Sites all with v7.0.30.x installed. Moving people to MS Edge as default browser is hard to convince some users but it’s one solution we’re using temporarily.

Userlevel 1

I complained about this ages ago, and still they haven’t fixed it. I can’t be bothered to complain any more, I am just not going to bother renewing my subscription.

It seems this issue has come up once again. SO glad I found this thread (thanks, Google!).

 

So - today is 9/10/21. Yesterday, and for the last several weeks, Chrome has opened with no problem. Today it opened a few times then refused to. I checked Task Manager, and sure enough each time I tried, another process would be spawned, but no visible would open. I canceled all Chrome processes, including the crash handler. THAT didn’t make a difference. So...I searched, found this thread and lit up, as I’ve been  WebRoot user for several years and thought this might be an answer.

changed one setting to “allow”

I changed this one setting to “allow” and Chrome immediately started working normally again.

 

It seems a shame, as this feature had been working for quite a while in “protect” mode, but apparently has a hairball today if I don’t explicitly allow the exe in the Chrome\Application directory. Disappointing, as I’d like to keep Chrome protected. It’s useless though, if this feature prevents Chrome from functioning.

Reply