sreece 1 Posted September 9, 2019 Share Posted September 9, 2019 Hello, I am running ESET File Security 7.1.12006.0 on a Server 2008 R2 VM. Several times now, I've been unable to log in via RDP or console, getting just a black screen and hourglass mouse. Even after attempting to kill the open sessions, my user still has one open process that can't be killed remotely or locally: eGUIProxy.exe. When I try to kill it locally, I get a message that access is denied. The only fix I've been able to find is to reboot the server, which is not an ideal situation. Has anyone else run into this? Any ideas on how to fix it? Thanks! Link to comment Share on other sites More sharing options...
Administrators Marcos 5,259 Posted September 9, 2019 Administrators Share Posted September 9, 2019 EFSW doesn't contain a firewall, hence it can't block RDP communication. Do you have KB2664888 installed? https://support.microsoft.com/cs-cz/help/2664888/computer-stops-responding-when-you-run-an-application-that-uses-the-wi Does temporarily disabling protocol filtering make a difference? Link to comment Share on other sites More sharing options...
sreece 1 Posted September 9, 2019 Author Share Posted September 9, 2019 (edited) It's not blocking the connection. I get to the login and can login fine, but I get a black screen after the password and Duo prompt are handled. The only process running under that user is the eGUIPpoxy.exe, and trying to reset or logoff the disconnected session using Remote Desktop Manager fails. Other users are able to log in fine, it's just that the user with the hung exe is not able to log back into the disconnected session (which also can't be killed because no users have access necessary to kill it). I do not have that hotfix installed, but we aren't facing an issue where the computer stops responding. The server is still up and functioning as a file server and other domain admins can log in; it's just that my session can't be reset so I can log into the server again. Based on this (https://help.eset.com/efsw/7.1/en-US/idh_config_epfw_scan_main_page.html), we do not have Protocol Filtering enabled since those features are not shown in the GUI. Edited September 9, 2019 by sreece Link to comment Share on other sites More sharing options...
Administrators Marcos 5,259 Posted September 9, 2019 Administrators Share Posted September 9, 2019 That's weird because egui_proxy is just a simple gui for basic interactions and operations accessible from the tray icon menu. For other operations it launches the main egui.exe. The only process that can affect other programs is ekrn.exe. It's possible that a complete memory dump from a manual crash when the issue occurs will be needed for analysis. Please raise a support ticket with your local customer care. As for protocol filtering, you can find the setting here: Link to comment Share on other sites More sharing options...
veehexx 1 Posted September 18, 2019 Share Posted September 18, 2019 us too! Just had this on our new server2019 RDS farm, running eset file security 7.1.12006.0. so far it's an isolated occurrence. One of our IT staff had a disconnected session from last night. When he reconnected this morning he was stuck at something along the lines of 'waiting for configuration profile' as the profile loads up. I forced a logoff of the session which mostly worked, but a single process remained; ' eGUIProxy.exe'. the process eventually ended but not sure what timeout this has. The time between him attempting to connect, me forced logging off that session and attempting to kill eguiproxy.exe with access denied, and the the process ending of it's own accord was around 5 minutes. Link to comment Share on other sites More sharing options...
veehexx 1 Posted September 19, 2019 Share Posted September 19, 2019 had the issue again just now for another user, so it seems not isolated. will raise with support. Link to comment Share on other sites More sharing options...
Administrators Marcos 5,259 Posted September 19, 2019 Administrators Share Posted September 19, 2019 If it's easy to reproduce, the best would be to get a complete memory dump from unresponsive state. For instructions how to configure Windows to generate complete memory dumps and how to manually trigger a crash to generate one, please refer to https://support.eset.com/kb380/. Link to comment Share on other sites More sharing options...
veehexx 1 Posted September 19, 2019 Share Posted September 19, 2019 Quote Currently, the server is set to full GUI mode, we strongly recommend setting the servers in RDS systems to be set to terminal mode. This can be done by policy or on a local machine (setup > advanced setup) User Interface >> User Interface Elements > Start Mode [Terminal] This will ensure that it doesn't start GUI sessions for users unless they start it manually. above is from support. changed from full to terminal and a test user doesn't have eguiproxy.exe running so seems good. guess we'll see for end users ever the next few days... Link to comment Share on other sites More sharing options...
Recommended Posts