locked
Server 2012 RDS WinLogon process crashing Event ID 4005 Black Screen RRS feed

  • Question

  • We have this issue on many 2012 RDS session hosts. The issue has been seen at different clients with different set ups, some have a simple 1 session host RDS server, some have 4 or 5 session hosts in a load balanced farm with RD gateway, connection brokers, RDWeb, ect. The problem in simplest explanation:

    A user will call the help desk saying they cannot access the server. They will get an error when RDP is trying to connect. 

    We check the session hosts, and will find many errors:

    "Event ID 4005 - The Windows logon process has unexpectedly terminated"

    At that point in time, users who are currently logged in may be able to still work, or their session may lock up (it is not consistent). 

    Regardless of the current users logged; after the logon process crashes, it continues to crash upon every user attempt to log on. It will happen indefinitely until the server is rebooted. We can not log in, not even via console until the server is rebooted.

    Then, everything works fine for some amount of time (not consistent) it may be a couple of days, or it may be weeks, or a month even. 

    We have had the case open with Microsoft for about two months and they cannot determine what is wrong. 

    I believe I may have found a possible cause; Webroot Secure Anywhere antivirus. Since we have tried everything from moving from roaming profiles to local profiles, removing all printers, blocking inheritance of GP, fresh server builds with minimal software, ect - it has to be something that is consistent across the board on all servers. 

    The only thing I can find consistent across the board is the Antivirus; Webroot. 

    I am curious if anyone else is having this issue? I would like to pin point this to something but it is so intermittent and we cannot force replicate the problem. 


    • Edited by commdudeaf Wednesday, August 31, 2016 10:40 AM
    Thursday, April 21, 2016 3:58 PM

Answers

All replies

  • Hi,

    Personally, I have not used the mentioned software, you may get more insights from other community members, and corresponding software vendor support should have more experiences regarding it.

    You may try to disable the software to see whether the issue re-occurs.

    In addition, please also fully patch Windows systems, RDS related updates can be found here:

    Available updates for Remote Desktop Services in Windows Server 2012

    https://support.microsoft.com/en-us/kb/2821526

    Best Regards,

    Amy


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    • Edited by Amy Wang_ Friday, April 22, 2016 5:39 AM
    • Proposed as answer by Amy Wang_ Monday, April 25, 2016 1:36 AM
    • Unproposed as answer by Amy Wang_ Friday, September 23, 2016 3:20 AM
    Friday, April 22, 2016 5:36 AM
  • Hi,

     

    Speak with Webroot, we have just been informed it’s a known issue. They're currently working with Microsoft to try and find a solution to the problem. They will be able to provide you with more information.

     

    Ben

     

    Friday, April 22, 2016 1:45 PM
  • Thanks Ben,

    We are reaching out to Webroot, I will update the post when I have more information.

    Friday, April 22, 2016 2:20 PM
  • We did open a case with Webroot, they have confirmed this is a known issue. I will update the post when I have a fix from Webroot. 
    • Proposed as answer by Amy Wang_ Monday, April 25, 2016 1:36 AM
    • Marked as answer by Amy Wang_ Thursday, May 5, 2016 6:49 AM
    Saturday, April 23, 2016 11:43 AM
  • Hi,

    Thank you very much for the update!

    Best Regards,

    Amy


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, April 25, 2016 1:36 AM
  • any news from webroot? I have the exact same issue on a 2012 r2 TS environment and was pulling my hair out til I saw this post. I will be calling webroot in the AM. thank you for posting.
    Friday, June 3, 2016 6:06 AM
  • Do you have any news from webroot ? We encounter the same issue on 2008 R2 RDS Env.

    Wednesday, June 8, 2016 8:35 AM
  • Hi All, Still no fix from Webroot. 
    Thursday, June 9, 2016 5:02 PM
  • I have these exact same symptoms on 2 RDS 2012 R2 VMs with Webroot. I had been researching all sorts of causes but to no avail. There are really no definitive log entries except the windows logon timout which looks just like a symptom. Processes start to stop responding slowly until a forced reset is needed. I thought about Webroot but had been using it successfully for about a year on both these servers. Maybe some type of interaction with a patch. It has happened 4 times today, I saw this post and immediately uninstalled Webroot, so we will see. Do you have any update from Webroot? I too will call their support. Thank you for this post.
    Wednesday, August 24, 2016 4:41 PM
  • I have these exact same symptoms on 2 RDS 2012 R2 VMs with Webroot. I had been researching all sorts of causes but to no avail. There are really no definitive log entries except the windows logon timout which looks just like a symptom. Processes start to stop responding slowly until a forced reset is needed. I thought about Webroot but had been using it successfully for about a year on both these servers. Maybe some type of interaction with a patch. It has happened 4 times today, I saw this post and immediately uninstalled Webroot, so we will see. Do you have any update from Webroot? I too will call their support. Thank you for this post.

    There is a recent update released by Microsoft that is also believed to cause this exact problem. 

    KB3172614

    We have opened a case with Microsoft for this issue; they said to remove KB3172614. We removed and blacklisted the update across 15 2012 R2 RDS session hosts on Sunday, we have not seen the issue return yet. Also to note; this is separate from the Webroot cause, as these servers no longer have Webroot after determining Webroot caused black screens as well. The recent black screen issue came back around late July. There are many threads regarding this:

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/4052abbc-e98c-4a94-9255-ae92deb686d2/event-4005-winlogin-windows-logon-process-has-unexpectedly-terminated?forum=winserverTS

    https://community.spiceworks.com/topic/1570976-server-2012-rds-winlogon-process-crashing-event-id-4005?page=3&source=navbar-community-notifications#entry-6128940

    • Proposed as answer by Amy Wang_ Thursday, August 25, 2016 2:07 AM
    Wednesday, August 24, 2016 11:25 PM
  • We are having the same issue again too. Removing KB3172614 did not solve the issue. This is being tracked here as well:

    TECHNET_WINLOGONERROR




    • Edited by commdudeaf Tuesday, August 30, 2016 6:45 PM
    Tuesday, August 30, 2016 6:33 PM
  • Remove Update

    KB3172614
    KB3179575

    Thursday, September 22, 2016 7:08 PM
  • Olá, Bom dia!

    Alguém conseguiu resolver o Problema de preta tela não RDS Apos o Evento 4005 de winlogon, removendo Os Dois KB de?

    Estou com o MESMO Problema e Removi o KB hj.

    https://support.microsoft.com/pt-br/kb/3172614

    Obrigado.



    Sidenei Santos

    Tuesday, September 27, 2016 12:08 PM
  • This is a result of updates that were distributed by MICROSOFT in late August 2016. My 2012 Server reacted the same way. Uninstall two updates KB3179574 and KB3172614. Both of these updates even describe the symptoms that we are all experiencing. Why MICROSOFT would knowingly distribute a update that they knew would cause this is the question? My server has been stable for 6 weeks now by dumping these two updates.

    David Holloway www.hsbss.com


    Monday, October 17, 2016 7:57 AM
  • I removed this KB

    KB3179574 today.
    I will wait to see if the problem to happen.

    Thank you.


    Sidenei Santos

    Monday, October 17, 2016 3:20 PM
  • Did you ever get this taken care of?  We are seeing the same thing, also on a terminal server 2012 R2 running Webroot.  
    Thursday, November 3, 2016 12:37 PM
  • Did you ever get this taken care of?  We are seeing the same thing, also on a terminal server 2012 R2 running Webroot.  

    Chris, This is still a global issue that may be affecting any environment running Server 2012 R2 RDS. Microsoft has released publicly they know this is an issue and are actively working on a fix, but still no resolution. We have been using a workaround when black screen occurs that does not require the server to reboot. 

    We have alerts configured to send us notification when the event ID occurs. Many are false positives, but then there are actually black screens as well. When we get the alerts we check for black screen. If it is so we perform the following (we got this from our support case - use at your own risk!):

    1. Message all the existing users who are already logged in to save all the document as they may lose connection however they will get reconnected to the same session again.
    2. Type services.msc in run or in elevated command prompt.
    3. Select the service name "Remote Desktop Services" and select Stop/Restart .
    4. As there is a deadlock in the RDS service , it may not stop or restart. It will go in STOPPING state.
    5. Open command prompt in elevated mode and type "tasklist /svc >process.txt & process.txt" without quote.
    6. Notepad with name process.txt will be open, search for the "TermService" , you will be able to find the process id .
    7. Open task manager and kill the process with the same process id whose name will be SVCHOST .  [Make it sure the process id are same else server may crash.]
    8. Once you have killed the TermService running under SVCHOST container refresh services.msc . You will see  "Remote Desktop Services" not running . Please select the service "Remote Desktop Services" and click on Start .
    9. Disconnected users may get connected back to the old session on the same server.
    10. If the server is in a collection, confirm all servers are set to allow new connections

    Again, this does disconnect all users on the server, but they will be able to reconnect as it does not require a reboot. 

    Still waiting on a fix from Microsoft, we are in communication with them weekly. 

    • Proposed as answer by ECGrid DevOps Wednesday, September 19, 2018 8:11 PM
    Thursday, November 3, 2016 1:00 PM
  • We're having this issue too. All of our environments are using Webroot and Windows Server 2012 R2 on Hyper-V Hosts.
    Sunday, November 6, 2016 5:19 PM
  • Same issue here. We support several RDS servers with WebRoot. Many of them have had the black screen "woes" with Event ID 4005 in the application log.

    Anyone aware of a fix besides removing WebRoot? 

    Are there specific patches that are the catalyst? We could remove / blacklist them from our updates.

    Tuesday, November 8, 2016 3:24 PM
  • Hi all,

    We have same issue with webroot.

    Our solution consist to uninstall webroot and install another AV solution (ESET) :-).

    Since, we don't have problem.

    Best regards,

    Lionel CADET

    Tuesday, November 8, 2016 3:33 PM
  • You can test this solution provide by webroot support

    Turn autoprotect Maximum to minimum for RDS only.

    BR

    Lionel CADET

    • Proposed as answer by Iamsecurity Friday, November 11, 2016 2:39 PM
    Tuesday, November 8, 2016 4:07 PM
  • We also have found a work-around (we use the mywebroot console to manage our AV):

    Use version 9.0.1.35

    - Apply a WebRoot Policy to the server that has auto-update turned off.

    - Uninstall WebRoot - completely. 

    - Remove the wrdata folder from Program Data folder.

    - *Reboot if necessary (schedule accordingly ;)

    - Download and install version 9.0.1.35. *Be sure to associate the proper site ID when running the install command (wsasme.exe /key=xxxx-xxxx-xxxx-xxxx-xxxx /silent /noupd)

    - That should do it until MS and WebRoot come up with a fix to allow the use of the current version.

    Tuesday, November 8, 2016 4:31 PM
  • We have the same issue on Server 2012 R2 but we don't have Webroot. We have Gdata AV installed. Did anyone have the same problems with GData AV?
    Wednesday, November 16, 2016 4:06 PM
  • Webroot may have a problem, but I think AntiVirus is just exacerbating a deeper issue. We have used eSet, webroot, Kaspersky, etc... and still experienced black screens.

    Recently I have noticed that the issue seems to happen when we have unexpected internet/Azure Connection issues. This tends to throw the Terminal Serviecs service into a death spiral. We use Server 2012 R2 on a HyperV machine hosted in Azure. The posts above about force stopping and restarting the TermServ service have worked for us until MS decides the issue is important enough to deal with.

    Wednesday, November 16, 2016 4:20 PM
  • All,

    If you are experiencing similar symptoms (black screen, 4005 event, etc.), but may not be using Webroot, please consider installing the November 2016 Preview of Monthly Quality Rollup for Windows 8.1 and Windows Server 2012 R2 .  It contains a fix for this issue.

    Applicable fix description:

    "Addressed issue where the Remote Desktop Service gets into a deadlock during virtual channel management and can’t accept new connections. This leads to a black screen or brief window before the client disconnects."

    General description of fixes contained in above update:

    https://support.microsoft.com/en-us/help/24717

    You can download details regarding the files included in the update here:

    http://download.microsoft.com/download/6/D/B/6DBDF0E0-FF0D-45A5-9605-ED14D395662D/3197875.csv

    I don't know if the above update will help in cases where Webroot is installed.  Worth a try.

    Thanks.

    -TP

    • Proposed as answer by TP []MVP Wednesday, November 16, 2016 4:27 PM
    • Marked as answer by TP []MVP Wednesday, November 16, 2016 4:27 PM
    Wednesday, November 16, 2016 4:26 PM
  • Overview of known issue:

    Webroot has been actively tracking and monitoring an issue that affects some customers operating Terminal Servers in a virtualized environment. During a fault condition, a Winlogin 4005 error occurs where an RDS user is unable to connect to the RDS server, and the event logs display a message indicating that Winlogin has stopped responding.

    Update: Interim advice issued by Webroot engineering teams recommended setting the WSAB Self-Protection function to ‘Minimum’ on all Server Policies as this significantly reduced the frequency of Winlogin 4005 errors in most cases. Webroot engineering teams have developed a fix which is currently undergoing regression and environment testing. The engineering and QA teams continue to treat this as their highest priority and are predicting this new build will be targeted for release the week of 28th November. Webroot believes this fix will eliminate the errors seen. Following successful roll out of the fix, and a short review period, Webroot will remove the recommendation to operate Self Protection at the minimum setting.

    Next Steps: Webroot will communicate an update to this message on/by Friday 25th November. If you face excessive issues with 4005 errors, please contact Webroot Support for assistance. In specific casesWebroot may be able to provide a beta build of the fix. Note that this beta version will need to be deployed with assistance from the Webroot Support team and involves additional steps not required with the fix release. Webroot apologizes for the disruption and inconvenience caused and for the time taken to manage this complex fault.

    We also thank you for your continued patience and understanding in this matter.

    Kindest regards,

    The Webroot Product Management Team
    Friday, November 18, 2016 6:09 PM
  • THANK YOU! Saved my day.

    BTW, a few notes to others. As we could not log into the server we used the following constructs to kill the process on a remote machine:

    • tasklist /s servername /svc
    • taskkill /s servername /pid ###

    -=tg=-

    Wednesday, September 19, 2018 8:11 PM