erothenberg

Marcos, Thanks for the response. While reinstalling the epfwlwf driver did fix the issue - at least for the time being, it is not really a solution - more so, it's a temporary workaround. This does not solve the underlying cause of why the issue is happening. I would love to be able to take a healthy machine and reproduce this issue on the spot, but as I mentioned earlier, there is no rhyme or reason to triggering this issue. It happens randomly.

Please see attached pictures for answers to your 2 questions: Note: ESET Personal Firewall is no longer even listed

That method does not work. That has been tried several times in the past.

Problem machines for the most part are Windows 10. I believe it did happen once on a Surface Pro 3 running Windows 8.1. The user has since upgraded to Windows 10 and has continually had this issue reoccur. If this is an issue with ESET running on Windows 10, which has been out for 7+ months, one would think it should have been addressed by now? Attached are the output logs you have requested. ESET_FW_OUTPUT.TXT LOAD_ORDER_OUTPUT.TXT

We have been experiencing a growing number of "Non-Functional" Personal Firewall, Network attack protection (IDS), Botnet protection (see attached picture) issues with our Security Endpoint clients. This first presented itself with Security Endpoint 6.1 and it is still happening as of 6.3. We have seen this happen most commonly with our Microsoft Surface Pro 3 machines, however it has also occurred with Lenovo Thinkpads as well. If this happened once to a user, it could be chalked up to an anomaly, but for some users it has happened upwards of 5 times. There also seems to be no rhyme or reason to it as well. A user could go weeks or even months before they turn on their computer one day and their ESET Network services are suddenly non-functional. ESET's response to this is to uninstall and reinstall the product. A repair will simply not work. We have opened up tickets in the past and have provided ESET developers with extensive log files but they had not provided any other solution. I am curious as to what others who have dealt with this issue have done.

GNP67 - thanks. After adding the "Threading = 0" to the odbcinst.inf file in conjunction with the "innodb_lock_wait_timeout=600" and a restart of the server, it is now updating the "Last Connected" column as it should.

Restarting the server is only a temporary workaround. From my understanding the MySQL service at midnight is supposed to clean the cache on the ERA server and thus update the client last connected list. It appears this is not happening. We are running the ERA Virtual Appliance and in another thread it was suggested to "add innodb_lock_wait_timeout=600 to your MySQL configuration (/etc/my.cnf) into [mysqld] section and restart database server". We performed these steps but it has not had any effect, we are still experiencing this problem. Is there an update regarding this ESET?

Even after ripping out 6.2 Era Agent from all endpoints, 4-5 boxes are still freezing up randomly and we are STILL experiencing the issue even though 6.1.144 has been reinstalled. We applied the MS Hotfix to a Windows 2008 R2 box and a Windows 7 Pro x64 and have not seen an issue reoccur. However, we have a number of Windows 2008 Server SP2 boxes, some of which experienced freezing/high CPU utilization, which aren't even running 6.2 anymore, they are running 6.1 and will still lock up randomly. And NONE of these boxes had any sort of issues until 6.2 was installed. Although, the hotfix mentions Windows 2008 Server, when running the hotfix it says "Not applicable to this Operating System". The poster above me mentioned disabling HIPS helped. Was this applicable to File Security or just Security Endpoint? Anybody else still experiencing issues even after ripping 6.2 out? For those running on Windows 2008 Server SP2, what did you do?

Resolved: I was able to grab the Linux tar file I had previously generated from Live Installers and install it on the box. This put 6.1 back on an then I ran the components upgrade task to bring it to 6.2 I am good again.

There only seems to be a Server folder within /var/log/eset/RemoteAdministrator/. I don't see an Agent folder. Is it possible when i removed all the 6.2 agents from all endpoints it deleted the folder on the ERA VA? If so, how do I go about reinstalling the agent on this VA?

We are running Version 6.2 of the ERA Remote Administration Server Virtual Appliance. We had pushed out 6.2 to all endpoint agents, however, some of them experienced high CPU utilzation/locking up and crashing so we have backed down to 6.1 on everything except the ERA Server VA itself. There is a Microsoft patch that supposedly addresses this issue but we have not run tests on it yet. Anyway, the one agent that is 6.2 is the ERA Server itself. This issue seemed to start after we upgraded the ERA server from 6.1 to 6.2. The computer object shows up under the the Linux Computers group as it's a VA running Cent OS. However, it has not "checked in" since September 14th. When I open details of the object i see the following are installed on it: ESET Remote Administrator Agent 6.2.200.0 ESET Remote Administrator Server 6.2.200.0 ESET Rogue Detection Sensor 1.0.728.0 (I know this is not the latest and greatest, but we have purposely disabled this service because we don't want it running port scans on our network) Although this is running the ERA server component as well, I'm not sure why the Agent is not checking in. I've performed an "Update components" task on it as well as initiating several wake up calls. There is an "Uninstall" button when I show the list of installed items that I have not attempted to run it on the Agent. Any ideas?

We seem to be experiencing the same issue. On Friday, we upgraded our ERA Virtual Appliance from 6.1.222 to 6.2. I then deployed the agent through "ERA Components Upgrade" task and pushed it out to several endpoints. While we have not had any reported freezes on endpoints running Windows 7/8/10, we have had at least 3-4 server VMS running Server 2008 R2 that have experienced high enough CPU spikes to freeze up the box causing a reboot. When i rebooted the boxes and took a look at all the processes ERAAgent was at 0% - hardly a blip - however, the commonality between all the servers crashing is that it all began after the upgrade from 6.1 to 6.2. Also, we have NOT upgraded the File Security Agent on any of these boxes. Like the OP, I have gone ahead and uninstalled just the ERA 6.2 agent from these boxes and so far the incident has not repeated. I will continue to monitor the situation. Does anybody know if the MS patch above fixed their issue?