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
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
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
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.
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.
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.
It occurred to HyperV VM's as well
This could be a compatibility issue between webroot & VMware tools, this seems to be only effecting VMware VM's
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.
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.
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 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.
This fixed it for a few VM desktops, however not servers with pagefiles oddly, this was the first fix I tried.
FYI, we have also had this problem with Windows 7 machines. Same fix, boot to recovery environment and rename the c:windowssystem32driverswrkrn.sys file.
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.
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.
Relevent Eventlog ID:
219
219
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.
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.

My problematic servers were indeed not configured for the c: drive to have the pagefile.
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.
Userlevel 7
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
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
Page 2 / 2
Reply
Login to the community
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.