Skip to main content
To Customer Support To Customer Support
After updating to Windows 10 Fall Creators, users may get notified that access to files and or folders was denied.  Typically, this will happen when creating, updating, moving or deleting existing files and folders.   

 

We’ve identified the root cause and have created a patched version of WSA that is currently undergoing QA testing.   Once all testing is complete, the patched version of WSA will be made available to our customers for manual and automated installations using GSM.  We are closely monitoring the inflow of support calls and may push the patched WSA to all customers if the need arises. 

 

The next version of WSA, due around December this year, will have the fix included and customers will receive it then as part of the normal deployment processes.

 

There are two workarounds that can be used until the patch version is available.

 

Workaround 1 – If you run agents with an unmanged policy, perform the following on each device


  • Open the Webroot SecureAnywhere agent by double clicking the System Tray icon in the lower right of your screen or by using the desktop icon.
  • Click the Advanced Settings button in the upper right of the window that appears
  • Click the Shields button on the left side of the options window
  • Remove the check mark next to “Check files for threats when written or modified”
  • Click the Save button at the bottom of the options window and enter the code when prompted
 

Workaround 2 – If you run agents with other policies, perform the following steps


  • Sign into the Webroot SecureAnywhere portal by visiting http://my.webrootanywhere.com
  • Navigate to the Policies tab and select the policy used by your agents
  • Click the Realtime Shield option on the left
  • Set the Draft changes for ‘Scan files when written or modified’ to Off
  • Click the Save Changes button, then the Promote Draft Changes to Live button
  • Once the agents check in, they should receive this new policy and apply it correctly.
 

In both cases, note that the application or process that reported the error will need to be completely restarted. The simplest way to achieve this is by rebooting the computer.

 

Key points


  • Only Windows 10 with Fall Creators update installed are impacted
  • The issue does not affect all Windows 10 with Fall Creators update installed
  • Workaround is available
  • Patched version of WSA is on the way
  • Patch available for manual or automate installations using GSM
  • Fix will also appear in next release of WSA , due December this year
UPDATE!

 

We’ve been working on a patch and wanted to update you with the latest information about this. The patch release is ready.

 

WSA 9.0.18.44 patch release is available for the following issues that have been reported by customers who have updated to Windows 10 Fall Creators Release.


  • Fixes issue with file operations after the Windows 10 Fall Creators Update ( typically these are permission issues )
  • Resolves an issue where VMWare Workstation (Viewer) 14 displays an error after updating to Windows 10 Fall Creators Update 
  • Prevent blocking of deletion of sandbox for 3rd party app Sandboxie after updating to Windows 10 Fall Creators Update
 

There are various mechanisms available to fix these issues and affected devices manually. For example:

 

 

Key points


  • Only Windows 10 with Fall Creators update installed are impacted
  • The issue does not affect all Windows 10 with Fall Creators update installed
  • Workaround is available
  • Patched version of WSA is complete
  • Patch available for manual or automate installations using GSM
  • Fix will also appear in next release of WSA , due later this year
 

If you’re still experiencing problems, please contact Customer Support as they will be able to assist you further.

 

Thank you!

 
Hi,

 

Will this update get applied automagically to all deployed systems in the consol?

 

Thanks

 
@, no, you will need to follow the steps in the post above. The reason why we haven't pushed it out fully is because it's a patch release and should only be applied to impacted devices (i.e. Windows 10).
Hi,

 

When can we accpect this to be solved in an automatic update?

Now we have to wait for the customer to be affected and then solve it, not a good solution for relationship we the costumer.

Or heavely reduse the protection whith the workaround i the policy.

 

Regards

Anders 
I agree with the above comment... this should be auto deployed via auto updates

 

It took me a week to add 2 + 2 = webroot, I thought it was my 'dodgy' system and only found out by rebuilding it and all was fine till webroot was installed...

 

So who else/how many people are thinking it is their dodgy system and not dodgy antivirus software?
The fix is in the next full release of WSA and that will be autodeployed.  For the moment, you will need to use the console to deploy and we would advise you do so only to impacted devices i.e Windows 10.  

 

If you have any scripting tools, then these can also be used to deploy the update.  

 

Next full release is due later this year / very early Q1 2018.  

 

 

Regards,

 

Jonathan

 
Can someone provide clarification on these statements with regard to the bugfix?

 

Key points


  • Only Windows 10 with Fall Creators update installed are impacted
  • The issue does not affect all Windows 10 with Fall Creators update installed
@ wrote:

The fix is in the next full release of WSA and that will be autodeployed.  For the moment, you will need to use the console to deploy and we would advise you do so only to impacted devices i.e Windows 10.  

 

If you have any scripting tools, then these can also be used to deploy the update.  

 

Next full release is due later this year / very early Q1 2018.  

 

 

Regards,

 

Jonathan

 

Interesting.  I've just had a couple of newly onboarded systems show up as having the .44 client, and I have done nothing special (our other techs deployed the antivirus, and I've issued no documentation about .44 yet within our company).  Could .44 be deploying by accident?
What I can't see here is a fix for files that have been screwed up.  I'm assuming the fix below will stop Webroot from borking permissions on future files but what about broken files?  None of the standard processes (i.e. take ownership, etc.) work to regain access to these files and folders.  And they've replicated to other computers as they existed in my OneDrive folder so the problem exists for me on computers that don't have Webroot (switched to other AV solution months ago).
Yep - any new install gets 44
@ @ @ @ 

 

I haven't had any issues with this update rolling out in my environment pretty widely, even on non-Windows 10 machines.  I don't expect to really have any issues either since "the bug" will be in the next general release.  However, it does appear to be rolling out automatically regardless of O/S. 

 

In my agent spread, I'm about 50/50 between X.34, and X.44 - some of that is my own doing, but it appears to be rolling out automatically across the board.  Just an observation.
This patch update has worked on all of our 10/1709 workstations. Thanks!
Is it OK to apply this patch to Windows 8.1 or Windows 7?
The issue didn't involve WSA changing file or folder permissions - WSA was locking the file / folder and hence other processes couldn't access it for activities such as deletion / moving etc... 

 

Once the fix was applied or WSA was removed, the issue was resolved. 

 

 
You could do that but there's no advantage in doing so. 

 

 
Drew,

 

This put me through a significant amount of heartburn this morning after the Windows 10 Fall Creators Update installed.  I'm glad that this patch is available but I had a difficult time tracing this issue back to Webroot.  Originally I assumed something had gone horribly wrong with the Windows update because I was getting permission denied messages in multiple apps and VMware refused to start any VMs and nothing pointed directly to Webroot.

 

This is such a major compatibility issue that Webroot should have been far more proactive in alerting customers to this problem.  The issue has been known for two months, has serious adverse effects, and yet Webroot didn't push this fix out to the endpoints or even alert its customers via e-mail?  I find this to be extremely troubling.

 

I urge Webroot to do a much better job in the future of being proactive with its communications on issues like this rather than burying the info within community forums.

 

Paul
100% agree with you, I have just sorted another one out after our customer was back and forth to their 3rd party software vendor for two weeks, it finally dropped on my desk and got fixed.

 

now I need to answer diffulicult questions from a major customer... what do I tell them, its webroot's fault here is their number, but good luck at getting an answer or a patch for a known problem they fixed months ago!!

 
Hi Gurus,

 

I have just encountered an issue with Windows 10 Fall Creator that is somewhat related to this thread hence my post, I would like some feedback before making any assumptions or spending too much more time on it.

On a fresh install of Windows 10 Fall Creator that has NOT had webroot installed.

Then attempting to install Webroot is unsuccessful.

What I am finding is that you instigate the installation from the wsainstall.exe and nothing happens.

Checked processes, nothing. Checked event viewer, nothing.

 

Can anyone provide any feedback to this?

 

Cheers
it's not the standard windows block? Right click the EXE then properties and there may be an unblock button.
Thanks for the response but unfortunately it is not that (I had done that already). I retested just then to be sure tho. 🙂

Reply


Terms & Conditions