Update on Winlogin 4005 & Terminal Servers - November 22, 2016

  • 23 November 2016
  • 35 replies

Show first post

35 replies

This patch does not work we still have servers crashing because of this.
Userlevel 7
Badge +31
Please contact our support team immediately so that we can troubleshoot your issue
Is there something else besides this patch that needs to be done?
Userlevel 7
Badge +31
The patch addresses a discovered resource leak which was discovered in the current release of WSA v9.17.28
Other areas
In GSM, create a policy for all of your terminal servers.  Make sure that you copy the settings in the default server policy exactly and then switch off the following:-
  • ID Shield
  • Web Threat Shield
  • Firewall
  • System Optimizer
  • Core System Shield
  • Scan Schedule 
Once you've done that, assign all of your servers to that policy.
This will have the effect of turning down the agent resource usage ( you still have a decent level of protection ).  If there is still an issue, we have a smaller feature area to focus on. 
If the everything is stable, start turning each setting back on, leaving a reasonable time gap between each to assess the impact.
Userlevel 5
Badge +24
We previously had an RDS server with the 4005 error, which we moved to Silent Audit mode as a result of the problem.  After installing, I moved the system back to our normal server policy.  So far no issues.
I have since updated all client RDS servers with this version and am monitoring further.
Userlevel 7
Badge +31
Working closely with our customers, Webroot has identified an issue that manifests itself in the form of existing Terminal Server sessions becoming un-responsive with users no longer being able to log in. The affected Terminal Servers have required restarting in order for normal service to be resumed. For customers who have experienced this, an update to WSA is available now and Webroot support will provide assistance as required. The fix will also be rolled into the next general release of WSA which is forecast to be automatically deployed in October. Forthcoming product bulletins will advise of the exact date.
Before applying the agent build we have created to address this issue, please ensure that you have applied the below Microsoft patches. These patches were designed specifically to address 4005 errors/RDS connection issues.
Before installing the following agent build please ensure that you have removed the agent currently installed and ensure that C:Program DataWRData has been removed (if not please delete this folder:
Please ensure that you reboot the server after applying the above update. If you experience any further issues, please update your support ticket and the escalation team will get back to you promptly.
Thank you for your patience whilst we have investigated and developed the update. It is deeply appreciated by us all at Webroot.
Webroot Global Escalation Team”
Userlevel 1
Thanks for the Policy suggestion.   I have created the policy and applied it to the single server causing me these problems.   I find it kind of unsettling that I have to disable so much of the product just to keep the client's server running.   Seems kind of counter-intuitive - "Please pay for this product, but don't use its security features or your server will crash!"
I have a single 2008 r2 RDS server that has been having these issues for some time - the Event ID 4005 and inability for users to log in.   (WR Agent  Server seems to be completely unresponsive when it happens.  I have to power cycle it to get it back up again.
I found a document somewhere a while ago suggesting an override for C:Windowssystem32winlogon.exe - is this advised, or was it an uninformed suggestion?   (No idea where I saw it...)
I find it amazing that this has been going on for so long without a resolution.    There's a document in this thread somewhere listing patches that are supposed to fix it, but they all seem to be for Server 2012 and r2 - not for 2008.
I am reluctant to do so, but am considering just removing WBSA from this server so I can stop getting urgent SOS calls from the client.    Understand that it is very difficult to recommend a product to my clients that has had an unresolved issue like this for so long.
Userlevel 7
Badge +31
winlogon.exe -  I'd avoid doing that. 
You're entirely right in saying that this has been going on for a long time.  No matter what we've tried in house, we can't reproduce this.  Some customers have Terminal Servers that rarely, if ever, see this issue.  It's been a pain in arse for everyone concerned, but particulary our customers. 
But there's some good news.  We've been given a full crash dump from a server that was experiencing a 4005 event and that's undergoing analysis at the moment.  I'm expecting that will give us direction as to what the underlying root cause is and then we'll be able to do something about it.  Given the past history, it's going to take a number of releases for us to flush out the solution. 
Hi is this stil happening? I have a terminal server that has been plagued with this issue for 6 months or more and we use webroot. I never thought to check that it might be webroot.
Userlevel 7
@, please reach out to our Support Team to look into this further for you.
Business Technical Support: Call 1-866-254-8400 M-F 7:00 AM – 6:00 PM MT
Open a Support Ticket