Skip to main content
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.
Our Team is currently investigating this issue.



Please reach out to Support at your earliest convenience for further instruction:

Business Technical Support: Call 1-866-254-8400

Open a Support Ticket: http://mysupport.webrootanywhere.com/supportwelcome.aspx?SOURCE=ENTERPRISEWSA
We also experienced this issue accross MANY servers.  Issue seems to revolve around the page file being set to another drive.  We could resolve by removing the drive and booting server back up causing it to recreate it.  Temp resolution is to move page file to C drive.
My problematic servers were indeed not configured for the c: drive to have the pagefile. 
The driver that is failing to load is HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumSWDWPDBUSENUM{dd7ac8b4-8c50-11e3-80b6-005056945bb1}#0000000000100000

Driver:

WudfRd

Service:

WUDFWpdFs

 

This is the driver that loads the pagefile and is the Windows Driver Foundation - User Mode Driver Framework.

 

Related Processes:

WUDFHpst.exe

wpdfs.dll

WudfRd.sys

WudFPf.sys

 

Since this service is failing to load, its not able to load the page file.

 
Relevent Eventlog ID:

219
defconoi,

 

Do you or anyone else in this thread have a kernel memory dump from the BSOD you can provide to me? They are normally located at C:WindowsMEMORY.DMP. They are written when the BSOD occus, if it isn't present you may have forcefully restarted your computer before allowing the dump to complete or it was purposfully disabled in the system configuration (sysdm.cpm > Advanced > Startup and recovery > Settings...).

 

If anyone is able to reproduce this make sure that "Complete memory dump" is set and the dump file is set to "%SystemRoot%MEMORY.DMP". Also make sure the DisablePagingExecitve registry key is set to 1.

 

Thank you,

Johnny Shaw

Software Engineer | Webroot Inc.
FYI, we have also had this problem with Windows 7 machines. Same fix, boot to recovery environment and rename the c:windowssystem32driverswrkrn.sys file.
This fixed it for a few VM desktops, however not servers with pagefiles oddly, this was the first fix I tried.
We did both, I added the Disable Page exec key in recovery mode to the system hive and checked for a memory.dmp, it was crashing and not dumping memory.  Also verified all servers have memory dump of kernel log enabled.
After crash

File System Filter 'WRkrn' (6.1, ?2016?-?11?-?18T12:49:11.000000000Z) has successfully loaded and registered with Filter Manager. 

Before crash

File System Filter 'WRkrn' (6.1, ?2016?-?09?-?14T17:14:42.000000000Z) has successfully loaded and registered with Filter Manager.
WE have 50+ servers this happened to and can submit logs or assist in the matter.  We need this resolved becaue this effected dozens of our customers.
This could be a compatibility issue between webroot & VMware tools, this seems to be only effecting VMware VM's
It occurred to HyperV VM's as well
We are also seeing this with several Windows 7 desktops and Server 2008 R2 servers (non-VM).   But in one of the server cases, we thought it might have been a failing hardware piece and attempted to boot it on a DR appliance as a VM, and that too suffered the same PAGE_FAULT error 50 result.  So then we knew it was not the hardware, but something software based going on.  And led us here.   In all cases, renaming wrkrn.sys to .old has allowed the machine to boot.  For now on the impacted machines we've uninstalled Webroot to prevent it from happening again until this is figured out.

 
Move the Page file to the C: drive and you can keep Webroot installed and reboot at will.  Uninstall Webroot before reconfiguring the page file.  
The servers in question do have the page file on 😨, so that fits the bill.  Haven't had a chance to test moving it yet.   However in the cases of the Win 7 desktops having the same behavior, they only have a C: drive, and no customizations to the page file itself.   Yet they too crash with the error 50.

 
Webroot released a routine update on Tuesday January 31st, containing general fixes and minor feature enhancements. For most of our millions of customers, the service has run as normal. However, some customers have experienced a problem with the update, so Webroot’s 24-hour support team has been working with them directly to remedy this quickly.

 

If you are one of those customers, we sincerely apologize and ask that you contact Webroot’s Business Technical Support team by calling 1-866-254-8400 or by opening a Support Ticket: http://mysupport.webrootanywhere.com/supportwelcome.aspx?SOURCE=ENTERPRISEWSA
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.
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.
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.
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
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 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
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)
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.

Reply


Terms & Conditions