Hello @robertellis991  I will ping a couple of Webroot Staffers @coscooper  @JGiffard to help you, or you can Submit a Business Support Ticket and or call support nearest to you: https://www.webroot.com/us/en/business/support/contact

Note: When submitting a Support Ticket, Please wait for a response from Support. Putting in another Support Ticket on this problem before Support responses will put your first Support Ticket at the end of the queue.

Thanks,

Thanks Daniel

A ticket is already raised (#342297) 

Just thought I’d check in here as well for any possible assistance, as this issue is hurting us quite badly ATM in terms of unplanned unavailability of business systems.

Any help anyone can offer will be gratefully received.

Thanks

How about calling them? https://www.webroot.com/us/en/business/support/contact

We have a resolution, although it required 2 support engagements each lasting 2+ hours. Ultimately this issue cost us critical application availability over more than 2 business days, so we are somewhat perturbed but also relieved to seemingly have found the issue.

As I understand it (I wasn’t on the 2nd support call this evening) two “new” WR services, known as WR Sky and WR Core, had effectively blacklisted the relevant executable file. Once this was whitelisted on the backend, the problem was fixed.

This executable is not new or recently modified. It has been scanned and seen by our Webroot clients across all our desktops for months on end without incident. If the file were newly-discovered or modified, I’d be more understanding of this kind of “false positive”; but as it is, this looks like an arbitrary determination, which is, in my view, really quite concerning; especially given that no alerts or notifications were generated. If these “new” services aren’t capable of referencing previously-acquired business intelligence, it may lead to real trouble for customers. Not the end of the world of course, but I’d say our confidence is a little shaken.

So overall… an OK support experience. Problem seems to be resolved. But certainly we have something to ponder when deciding upon our next renewal, which perhaps we didn’t have before.

Kind Regards to all.

Hello @robertellis991 

Interesting as we Beta Tested those files during the past 9 months and not sure if all of these are in the Business version.

New files will be added in these locations:

• C:\ProgramData\WRCore\CoreService 
• C:\ProgramData\WRCore\CoreService\Components\FCS\WRFCSUser.x86(.x64).dll
• C:\ProgramData\WRCore\SkyClient\DB 
• C:\Program Files\Webroot\Components 
• C:\Program Files\Webroot\Core 
• C:\Program Files\Webroot\Core\WRCore.x64.sys

And two new processes will run: 

• WRCoreService.x64.exe 
• WRSkyClient.x64.exe 

Description of each of the new components:

• SkyClient is a new service used to communicate from the agent to our cloud backend. 
• WRCoreService is a new companion service that provides the foundation for our modular architecture.   
• WRCore.x64.sys secures inter-process communications and provides hash calculations.
• Files in C:\ProgramData are shared across users.  This includes determination database and logs.
• Files in C:\Program Files are the primary executables and libraries
• WRFCSUser looks for potentially malicious unknown processes and reports results to our Sky services.

Thanks for the info and update!

Folks,

Those two “new” services (WRCoreServices and WRSkyClient) are causing tremendous Windows 10 (version 2004) login slowdowns...like a factor of 5 to 10 times slower.  You will login, but very, very slowly.  I already have a tech support ticket and sent my log files to tech support and they want to “look” into my machine when I give them a date to meet online.

In the meantime, has anybody else noticed these changes to Webroot’s machine bootup functionality?  It all started for me on August 25, 2020 at around 2PM in the afternoon just as I was dealing with a GoToMeeting teleconference.  Turns out that is the exact same date and time when Webroot did an “update” on my machine with these two services.

Curious, rather than having Webroot go through my machine, did anybody get this issue and if they did, did they solve it?  Is it a reinstallation thing?  Removing a another driver (video?) from loading?  Delay loading their drivers?

Chris

Hello @cstocci 

Yes there are issues with the update to v9.0.29.51 but sorry you are having issues as many are seeing the same and only support can help you so please have some patience as they are busy with this issue!

Submit a Support Ticket to get help.

Note: When submitting a Support Ticket, Please wait for a response from Support. Putting in another Support Ticket on this problem before Support responses will put your first Support Ticket at the end of the queue, it should be 24 to 48 hours but could take a little longer because of COVID 19.

Sorry again,

Hi,

I think I am going to “sit this one out” as it is said.  I already have a ticket in and they want to get a date to work with my machine online, but I would rather not do that and just wait for a resolution as one always comes.  Besides, the OS and all of my applications that I am running are pretty mainstream and if it requires a big change in my system to operate correctly, then they are going to have the same issues for everyone, so best just to wait.

BTW, I have the same Webroot system running on a Windows 7 Professional 64-bit virtual machine (VMware Workstation Pro) with no issues and it has both of those Webroot services running in the background with no issues at all.  Granted, it is not my host’s Windows 10 Professional, but many of the drivers are identical in terms of the applications I have on that VM.

Chris

Hi Chris,

The thing is not everyone is seeing this issue but many are and they haven’t told us what the issue is and we Mods are Volunteers so they don’t tell us everything and personally I don't have this issue or on my Win 10 Pro VM running the Insider builds. https://community.webroot.com/tech-talk-7/announcing-windows-10-insider-preview-build-20211-2021-344960

I will ping @BradW  and if you really need help he can get it for you!

Thanks,

We are see this issue with Win 10 x64, Win 10 x32, Win 7x 64 and Win7 x32 workstations. 

“Fatal Application Error.

ThinApp has encountered an unexpected error.

Click to Abort close the application. Retry to debug. or Contine to ignore the error.

Support infor: PID=xxxx, RuntimeUtil.cpp@xxx”

Only workaround I have found at the moment is to boot into safe mode and disable WRSkyClient Service.

Have raised issue with Webroot support.

This is becoming bad, really. 
 

We are now experiencing an issue where Users are contacting us to say that, entirely out of the blue, they are being prompted to enter Webroot License keys when they open chrome. 
 

Is this some kind of random update? 
 

I am also wondering if this is an indirect result of the WR Support engineers asking Us to install the consumer version kernel instead of the Business edition - or whether there is something else just plain weird going on 

Rapidly losing confidence in WR  

If it helps 

On our support case they had us move from the business edition to the consumer edition thinking that would solve the issue. However this has been a red herring

Ultimately the issue was resolved by WR backend team whitelisting the thin app Executable. (They initially claimed that the executable had been modified, but it hadn’t - happy to send you our Support ticket threads if you want them. Just LET me know) 

Hello @robertellis991 

It’s possible read these and I will ping @coscooper for more info and I only seen this issue when first installing within the new Microsoft Edge but nothing since in any of the browsers mentioned.

For Firefox: https://community.webroot.com/web-threat-shield-131/adding-web-threat-shield-to-firefox-342501

Google Chrome: https://community.webroot.com/web-threat-shield-131/add-web-threat-shield-to-google-chrome-in-a-pc-342540

Microsoft Edge: https://community.webroot.com/web-threat-shield-131/how-to-add-the-web-threat-shield-extension-to-the-new-microsoft-edge-341874

HTH,

@robertellis991  - The extension validation is happening with Chromium based browsers, Edge/Chrome and FireFox, it’s believed to be related to a security feature that is not letting the extension update license information to get the key, so it’s being investigated. It does seem to be random and I do not have a consistent fix other than enter the key.  It’s not business vs consumer as extensions are handled the same. @TripleHelix  added the links for browser setups we have published to date.

Also, keep in mind, many issues that crop up are not always WR related, but related to the browser or OS manufacture/vendor who make changes that as a software vendor we may or may not be alerted to the change until it’s released, so often times, we have to modify code to address issues introduced by others. (It’s the software world!) 8-)

As far as the application crashing, submitting MD5’s will help and sounds like it was resolved. Application awareness and threat intelligence is an ever changing landscape with so many variables there’s often no one “fix”. “Application change” is a relative term. 8-)

Hi Robert

Appreciate the follow-up. Webroot support escalation finally resolved issue after they got to the bottom of it in the back end. Quote from support “ We've made some changes to the back end that may impact this behavior”. Once the endpoints configurations were refreshed they no longer were getting the ThinApp errors. Hooray!

Still experiencing the same issue with Thinapp packages

Each time we create a new package, WR client inappropriately injects itself and causes app to crash.

We have added Whitelist Overrides to try to prevent this, but they don’t work, so we are once again at the mercy of waiting for a Support ticket for a fix

Is there a plan from Webroot to fix this so that we can apply our own Overrides centrally, instead of having to raise a Support ticket every time we want to patch our own software?