Solved

Webroot Client possibly (probably) causing App crash


Userlevel 1

We have a legacy VMware Thin App virtualised application which has been working until quite recently, i.e. just in the last day or so, users are experiencing app crashes when launching the virtualised app.

We have found that removing the Webroot client from a sample computer eliminates the symptoms of the application crashing and therefore we believe that the Webroot client is interfering with execution.

We have added Global Whitelists entries for the Application executable and for the UNC from where the Application executable is run and streamed, but this has not resolved the issue.

I suspect that somehow the Webroot client is interfering with the data streaming process upon which the ThinApp virtualisation framework depends.

This affected application is business critical, so I need to find a way to correct this behaviour, or we will be forced to abandon Webroot in favour of an alternative AV solution for all affected users.

 

I have a raised a Support ticket today and currently awaiting a response. 

 

Any ideas how we might be able to actively prevent the Webroot Client from scanning data that is streamed (or executed) from a UNC, beyond Global Whitelisting which evidently is not working for us? 

 

Many thanks

Robert

 

icon

Best answer by robertellis991 21 August 2020, 02:18

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.

 

View original

15 replies

Userlevel 7

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,

Userlevel 1

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

Userlevel 7

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

Userlevel 1

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.

 

Userlevel 7

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

Userlevel 7

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

Userlevel 7

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.

Userlevel 1

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  

Userlevel 1

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.

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) 

Userlevel 7

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,

Userlevel 6
Badge +25

@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-)

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.

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) 


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!

Reply