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 1 / 2
Thanks, but either the notes are missing or I'm just not able to see them. Anyway you can provide the relevant change log here?
Thanks,
Nic
Thanks,
Nic
Userlevel 7
This was resolved in build 9.0.17.28@ wrote:
Any update on the the status of this release?
-n
SecureAnywhere Business Release Notes
Any update on the the status of this release?
-n
-n
Userlevel 7
Not a problem, we're always listening and willing to help in any way we can :)
Impressive, thanks! Looking forward to the release and thank you for paying attention.to a community forum :)
-Nic
-Nic
Userlevel 7
A validated fix from development will be patched in the upcoming release.
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
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.
Userlevel 7
+35
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.
+1 as well, would be most useful to have
+1 as well
+1 on this.
Userlevel 2
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?
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.
Userlevel 7
+35
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.
Userlevel 2
is .50 a fix or just a rebranded 9.0.13.75?
Userlevel 7
+35
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
Curious...were your servers rebooting because of installing Windows patches by chance?
Also wondering if anyone who has had this issue did NOT also have the January Quality update from Microsoft installed? I'm wondering if perhaps it was this version of WR and the Quality update.
We installed the security only update and so far to my knowledge have not had issues.
Also wondering if anyone who has had this issue did NOT also have the January Quality update from Microsoft installed? I'm wondering if perhaps it was this version of WR and the Quality update.
We installed the security only update and so far to my knowledge have not had issues.
I have a Win7 test machine at my desk that was at a BSOD 50 this morning and I just figured the hard drive finally crapped out until I saw this thread.
It did restart last night, but it shows version 9.10.21 in add/remove programs and the portal, so not sure if it tried updating or what.
Edit#1 I logged in in safe mode, added registry key to be able to run msiexec, uninstalled WR and rebooted. Went through finninshing applying updates and then rolled back, but then booted to Windows fine, so maybe not that version of WR, but a Windows update / WR combination.
Edit#2 This is the update that shows failed now fromlast night
January, 2017 Security Monthly Quality Rollup for Windows 7 for x64-based Systems (KB3212646)
It did restart last night, but it shows version 9.10.21 in add/remove programs and the portal, so not sure if it tried updating or what.
Edit#1 I logged in in safe mode, added registry key to be able to run msiexec, uninstalled WR and rebooted. Went through finninshing applying updates and then rolled back, but then booted to Windows fine, so maybe not that version of WR, but a Windows update / WR combination.
Edit#2 This is the update that shows failed now fromlast night
January, 2017 Security Monthly Quality Rollup for Windows 7 for x64-based Systems (KB3212646)
Userlevel 2
I have found that this seems to affect machines that have staticly set page files that are not on the boot volume.
We had a Windows Small Bsuiness Server 2008 machine crash 2 nights ago and are running from our backup device now.
I was able to only recreate the issue in a lab environment on 2012R2 if I set paging file staticly on the 😨 volume.
My account manager thinks this is related to an NVidia driver that has been out for 5 weeks, I don't quite agree with that
We had a Windows Small Bsuiness Server 2008 machine crash 2 nights ago and are running from our backup device now.
I was able to only recreate the issue in a lab environment on 2012R2 if I set paging file staticly on the 😨 volume.
My account manager thinks this is related to an NVidia driver that has been out for 5 weeks, I don't quite agree with that
I have verified that the default download link, http://anywhere.webrootcloudav.com/zerol/wsasme.msi, is pulling 9.0.13.75 again. I have not witnessed anything auto-downgrading yet though. I'm hopeful.
I heard a rumor that this update is being rolled back and prior stable version will be reverted to via AutoUpdate.
Has anyone seen that happening? Can this be confirmed?
-Mark
Has anyone seen that happening? Can this be confirmed?
-Mark
+2
Had this happen on one physical server this morning, renaming the driver resolved the issue. The page file on the system was configured to let Windows manage it, not customized to a specific location. The OS was 2012 R2.
We onboarded a new client last night, Windows 7, 8, 8.1, 10, Server 2012r2 all have the problems. Over 55 machines failed immiedately after install of Webroot. Have now have servers failr to recover in Azure as well. Tickets are placed, waiting to hear from someone at Webroot, ouitside of investigating ... if anyone in the community finds anything please share. Removing Webroot from the systems has not resolved the problems, when they reboot they are extended reboot loops.
Userlevel 5
Hi All,
Thank you for the great information. Please keep an eye out for the C:WindowsMEMORY.DMP file.
Thank you,
Johnny Shaw
Software Engineer | Webroot Inc.
Thank you for the great information. Please keep an eye out for the C:WindowsMEMORY.DMP file.
Thank you,
Johnny Shaw
Software Engineer | Webroot Inc.
Page 1 / 2
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.