The latest Webroot release 9.0.15.43 with its updated wrkrn.sys file seems to have caused some BSOD's with 2008r2 after our systems rebooted last night. I was able to delete the file from a repair command prompt and then reboot into normal operating mode.
I have a ticket in with Webroot support about this issue, but I thought my issue should be shared.
Update: I have talked with an MSP using Webroot who has had the same problem today. They also report that if you reboot your machine again after Webroot has a chance to reinstall the wrkrn.sys file it will start throwing up BSOD messages again.
Page 2 / 2
We have a new agent release:
Following reports of difficulties installing the latest Webroot SecureAnywhere Business (WSAB) update v9.0.15.43, a new agent release titled v9.0.15.50 has been deployed automatically to all of our WSAB customers on Thurs 2nd Feb 2017. This version provides relief to those customers experiencing installation problems.
Webroot apologizes for any inconvenience caused by this updated release. Our 24/7 Support team is briefed and available to customers who may have any questions or concerns about this update.
Webroot’s Business Technical Support - call 1-866-254-8400 or open a Support Ticket: http://mysupport.webrootanywhere.com/supportwelcome.aspx?SOURCE=ENTERPRISEWSA
Following reports of difficulties installing the latest Webroot SecureAnywhere Business (WSAB) update v9.0.15.43, a new agent release titled v9.0.15.50 has been deployed automatically to all of our WSAB customers on Thurs 2nd Feb 2017. This version provides relief to those customers experiencing installation problems.
Webroot apologizes for any inconvenience caused by this updated release. Our 24/7 Support team is briefed and available to customers who may have any questions or concerns about this update.
Webroot’s Business Technical Support - call 1-866-254-8400 or open a Support Ticket: http://mysupport.webrootanywhere.com/supportwelcome.aspx?SOURCE=ENTERPRISEWSA
is .50 a fix or just a rebranded 9.0.13.75?
Good question - here is some clarification from our product team:
The 9.0.15.50 release made available yesterday replaces the driver component with a known good driver used previously in v9.0.13.75 which had been operating successfully since November 2016. This means that 9.0.15.50 fixes the issue at hand by removing the code changes made in the v9.0.15.43 build, and will allow affected customers to recover with assistance from our support team.
The engineering teams continue to work on determining the root cause of the fault and whilst it was proving difficult to reproduce consistently a new built was determined to be the quickest method of restoring service to impacted customers.
The 9.0.15.50 release made available yesterday replaces the driver component with a known good driver used previously in v9.0.13.75 which had been operating successfully since November 2016. This means that 9.0.15.50 fixes the issue at hand by removing the code changes made in the v9.0.15.43 build, and will allow affected customers to recover with assistance from our support team.
The engineering teams continue to work on determining the root cause of the fault and whilst it was proving difficult to reproduce consistently a new built was determined to be the quickest method of restoring service to impacted customers.
Experienced the same issue yesterday on 3 servers.
1 SBS2008 - physical
1 SBS20211 - Virtual on HyperV
1 SBS20211 - Virtual on ESXi
Today I had a Server 2012 on ESXi
When virtual - Boot up the server with only the C Drive.
Windows will create a temp pagefile on C just to work.
Configure the Pagefile to remain on C Drive.
Shutdown and add the additional Disks.
1 SBS2008 - physical
1 SBS20211 - Virtual on HyperV
1 SBS20211 - Virtual on ESXi
Today I had a Server 2012 on ESXi
When virtual - Boot up the server with only the C Drive.
Windows will create a temp pagefile on C just to work.
Configure the Pagefile to remain on C Drive.
Shutdown and add the additional Disks.
If this is a fix, can we have a report of what was fixed? That release notes is more of a notification of a new patch with no new details.
There will be other areas where I will raise this concern, but this is all the more reason why Webroot should give its partners the ability to choose whether or not to push a release out selectively or fully. Auto-Update or No Update is not a great method when you are dealing with enterprise and large numbers of agents.
Is there a way to be notified when a new agent version is released so that we may test it?
There will be other areas where I will raise this concern, but this is all the more reason why Webroot should give its partners the ability to choose whether or not to push a release out selectively or fully. Auto-Update or No Update is not a great method when you are dealing with enterprise and large numbers of agents.
Is there a way to be notified when a new agent version is released so that we may test it?
+1 on this.
+1 as well
+1 as well, would be most useful to have
The Root Cause Analysis has been completed and the Engineering team is analyzing the results and assessing the impact on future code builds. We will provide details to customers via support tickets and make available a version for posting later this week.
While we put every release through rigorous testing, in this case a serious issue was discovered after release that was not seen during testing. Going forward, we are expanding our QA coverage to address an even broader range of customer environments. We will also improve communication to ensure customers are consistently notified of releases in advance, so they are able to control how they roll out updates in their environments. Specific details will be announced in the coming weeks.
While we put every release through rigorous testing, in this case a serious issue was discovered after release that was not seen during testing. Going forward, we are expanding our QA coverage to address an even broader range of customer environments. We will also improve communication to ensure customers are consistently notified of releases in advance, so they are able to control how they roll out updates in their environments. Specific details will be announced in the coming weeks.
I had this issue also. Just resolved it with MS's (paid unfortunately) assistance now.
Just curious how others nailed down the issue to webroot as my particular experience was that having a 2012R2 VM with paravirtual controllers on VMware 6.0. When it BSOD'd none of the disks were available to write any memory dumps to so I really was flying blind it would just flash up then reboot immediately without writing anything to disk (as it couldn't see them). While we were getting "IRQL NOT LESS OR EQUAL" as opposed to PAGE_FAULT, MS said that they are quite similar.
Issue was only resolved as MS "had many reports of this over the past week" and one of the first questions the tech asked "So.... do you have Webroot installed by any chance?" As soon as the Webroot drivers were set to 4/disabled in the registry accessed by the recovery environment was the issue resolved.
As with others it seems... our swap file was on a different volume and the machine rebooted itself every morning.
Just curious how others nailed down the issue to webroot as my particular experience was that having a 2012R2 VM with paravirtual controllers on VMware 6.0. When it BSOD'd none of the disks were available to write any memory dumps to so I really was flying blind it would just flash up then reboot immediately without writing anything to disk (as it couldn't see them). While we were getting "IRQL NOT LESS OR EQUAL" as opposed to PAGE_FAULT, MS said that they are quite similar.
Issue was only resolved as MS "had many reports of this over the past week" and one of the first questions the tech asked "So.... do you have Webroot installed by any chance?" As soon as the Webroot drivers were set to 4/disabled in the registry accessed by the recovery environment was the issue resolved.
As with others it seems... our swap file was on a different volume and the machine rebooted itself every morning.
Hey February, July here. Still having this issue.
Windows SBS 2008
Webroot: current as of 7/11/17
Page file on C and on another volume
Banged my head for a few hours chasing down BSOD's and swapping out memory modules. I couldn't get to the OS at all and finally used a recovery disk to get at a memory dump. After digging around I remembered news of WR crashing servers and started down that rabbit hole and ended here. Needless to say after renaming the WBkrn.sys file, my server booted fine. Uninstalled WR and things are running fine...however, my server is now unprotected so I still be up all night thinking about that. Yay.
My environment has never had an issue with WR and it's been about 4 years. This is the first, but it hurt...BAD.
-n
Windows SBS 2008
Webroot: current as of 7/11/17
Page file on C and on another volume
Banged my head for a few hours chasing down BSOD's and swapping out memory modules. I couldn't get to the OS at all and finally used a recovery disk to get at a memory dump. After digging around I remembered news of WR crashing servers and started down that rabbit hole and ended here. Needless to say after renaming the WBkrn.sys file, my server booted fine. Uninstalled WR and things are running fine...however, my server is now unprotected so I still be up all night thinking about that. Yay.
My environment has never had an issue with WR and it's been about 4 years. This is the first, but it hurt...BAD.
-n
A validated fix from development will be patched in the upcoming release.
Impressive, thanks! Looking forward to the release and thank you for paying attention.to a community forum :)
-Nic
-Nic
Any update on the the status of this release?
-n
-n
This was resolved in build 9.0.17.28@ wrote:
Any update on the the status of this release?
-n
SecureAnywhere Business Release Notes
Reply
Login to the community
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.