Hey there @stack888 ,

Great question! I’m going to ping one of our awesome product experts to see if he has an idea: @coscooper 

thanks khumphrey! I already tried this on one of the clients…

"C:\Program Files (x86)\Webroot\WRSA.exe" -poll

but still showing as not seen since Feb 11th.

@stack888  - that’s interesting for sure for an agent to just stop responding/communicating with the backend servers.

Is this a new install? Has it been confirmed to be installed with the key from your console? Inherited from another service or provider?

NOTE: The reason I ask above is, often when a device has been inherited with WR already onboard, it’s still communicating with the previous console. (So, just asking to clear that one out).

If it has the correct key and is truly tied to your console, then arbitrarily stopping communication is definitely a problem and not always the agent.

Considering you’ve already sen the poll command, something else must be getting in the way. Usually it’s a firewall or something on the network. Couple of things to check.​​​​​

1. FW rules - if any new inbound/outbound rules were put in place since last check in, could be something happening there. I can shoot over the specific URLs we typically need to make the agent work.
2. Local Windows FW - was it accidentally turned on? Blocking the agent?
3. If comfortable with Process Explorer (Free utility that dives deeper into various processors and great for troubleshooting) on a problematic device, you could look at the TCP/IP tab/stack part of the WRSA.exe process or child process and see if there’s any negative responses there. Often if the agent can’t communicate right after a -poll, the culprit will show up there.
4. Wireshark - goes pretty deep, but the packet capture file may provide a clue.

We usually find that FW or some kind of Network device is the culprit. If it’s not super clear, then bottom two network troubleshooting techniques may uncover the culprit.

HTH

~Shane

hi Shane,

many thanks for your help and ideas on this one.

So this is affecting probably 8 or 9 different PCs in our office, none are new, all established Windows 10 Pro HP PCs and have been running Webroot since installation. I noticed a number of them stopped communicating with the console on Feb 11th and a few others in the days after that.

I’ve logged onto 3 of them and been checking Event logs etc and can’t see anything obvious. I tried to run an uninstall command from the console to one of them but nothing as the link appears broken. 

I manage the firewalls here and there have been no new rules put in place for some time, certainly not since Feb 11th.

Local windows firewall is always on and its on on PCs that are working fine (I checked a couple just now).

There are Microsoft Updates but then again there are so numerous now, its hard to pinpoint any that might have an effect.

You mentioned the URLs to make it work - yes, if you could send me those that would be very useful to try.

I have process explorer and remote process explorer so I can do something there. I’ll take a look at the tcpip tab/stack, its not something i thought of looking at. Will let you know if i find anything there.

cheers

Here’s the standard URLs required for the agent to work.

BTW… if you run Wireshark and pull a PCAP file, we can do a support ticket and have someone look at it. Super odd to have an agent just “stop responding” - not something that’s common. But, stranger things. 8-)

*.webrootcloudav.com

Agent communication and updates

(Please note: Some firewalls do not support double dotted subdomain names with a single wildcard mask (i.e. g1.p4.webrootcloudav.com being represented by *.webrootcloudav.com) so some environments might require either *.p4.webrootcloudav.com or *.*.webrootcloudav.com)

*.webroot.com

Agent messaging

https://wrskynet.s3.amazonaws.com/*

https://wrskynet-eu.s3-eu-west-1.amazonaws.com/*

https://wrskynet-oregon.s3-us-west-2.amazonaws.com/*

Agent file downloading and uploading

*.webrootanywhere.com

Management portal and support ticket logs upload

WSAWebFilteringPortal.elasticbeanstalk.com

Web Threat Shield

thanks Shane, I’ll look into all you posted above. May take me a little while.

Attached is what i see on the console currently, i removed IP addresses etc.

But you’ll see on Feb 11th a bunch of PCs stopped checking in. And there’s more in other groups doing the same. It was a thursday, not aware of anything changing in the network environment at all. Strange for sure.

And manually uninstalling and reinstalling would be a real pain as you need to go into safe mode to uninstall Webroot. and when i’m contacting a remote location with no user present,  if i boot to safe mode I can’t then remote to the PC again to change it back.

Anyway, i’ll investigate as per your links above.

thanks again!

in process explorer, when i look at the child process of WRSA.EXE and click on properties and then TCPIP, its just blank. Is there somewhere else where it should be showing data? I’ve tried polling whilst that window is open but it stays blank. If I do properties on the parent WRSA.EXE process it crashes processexplorer every time.

Hm… I just checked it on a test device I have and it reports success establishment of 3 way handshake with positive/green highlight while connecting and then keeps it in the list showing it’s good. I think if it’s bad or doesn’t go through, it turns red.

Here’s screen shot from a minute ago after doing “Refresh Config” in system tray menu.

It was on the main process, not child… so, not sure why it’s crashing. I know there’s three versions, 32bit, 64bit and AMD.

thanks Shane, trying the 64 bit version now and its working better. I see some data in there too.

wow, thats quite interesting results in processexplorer. On a machine thats not checking in with the console, I see 2 entries, one listening and one established. But no new entries when i click update configuration on the webroot icon.

however, on a working machine I see 3 entries, 1 listening and 2 established and then more entries appear when i click update configuration. Not sure this helps me but i can see a difference in behaviour at least.

with Shane’s help above and that of a webroot support engineer, we determined the issue was a registry key that pointed to a Proxy Server (which we don’t use). Once the data in this key was deleted, the endpoint could communicate with the Console again. The other solution is to uninstall (using custom uninstaller from webroot) and reinstall the webroot client.

I suspect the cause of this erroneous registry entry is a result of third party penetration testing that occurred that day.