ottchris

The options could have been more wisely worded. If its only purpose is increasing awareness, that should have been made more clear. "Stay Protected" implies something more significant than just more information will occur should you select it. I assume "Postpone" means the pop-up will reappear at some point?

Ghostery is apparently "working on it". Contacted them via Twitter.

I have already just this minute done a check using https://www.digicert.com/help/ and it also states the certificate in question is invalid. While site admins certainly would be advised not to go the wire with certificate renewal I can understand why anyone might think that a certificate whose validity period (valid from date to date) and has a to date of 30th November is still valid. The wording is ambiguous. UPDATE. OK, didn't notice the time stamp! :-( It would be preferable if the timestamp was included with the date in the certificate display 'valid from/to" field.

I have always assumed the validity period on SSL certificates (valid from date x to date y) is inclusive. It seems the logical interpretation of from/to. Today, ESET is telling me that a certificate with a 'to date' of 30/11/2017 has expired and is invalid. I'm making an assumption that the 'invalid text' in the certificate as displayed by ESET is the result of an ESET test of the dates. A brief Google search has failed to produce a definitive answer. Anyone care to enlighten me?

As far as I'm aware this issue began within the last month or so. The broadband connection drops out for circa 2 minutes in the early hours of the morning. At first I assumed it was a reconfiguration event at the exchange. When it became apparent that this event was occurring every day at around the same time, during one of the outages I ran a ping test to one of my sites from a smartphone connected to the same broadband router; all pings were successful so no circuit down as far as the router was concerned. While looking around for potential 'culprits' I noticed that the ESET Smart Security Scheduler had Log maintenance set to run daily at 00:10. I disabled that and after that the issue was resolved. I have just run a confirmation test and re-enabled log maintenance and rescheduled it run in 5 minutes. About 1 minute after the log maintenance was scheduled to start, the broadband connection dropped, at least as perceived from the 'ESET machine, and came back up after about 2 minutes. During this 2 minute period I noted intensive disk access, presumably log maintenance activity. I would have expected ESET to temporarily cache new log entries while it was running log maintenance. I'm not sure whether it is intentionally blocking all activity during log maintenance or whether it is an indication that it cannot cope with running normal security functions concurrent with log maintenance. Running ESET Product version: 10.0.390.0

I wouldn't dispute that *your* 5 PCs no longer exhibit the problem. I'm happy to be corrected but I don't believe we know the root cause, i.e. the process which leads to the three network protection modules starting up non-functional and until we do it can't be said the problem has been fixed. That was the point I was making in my reply. Over the last month or so I have made significant reductions in the number of applications and any associated services that start up automatically so I'm almost at a 'skeleton startup' configuration. In my case, the current situation is an aggravation but it is liveable with. The investigation is ongoing.

Not here it hasn't. I have not contributed to this thread for a while because I have been trying to zero in on the cause while still trying to do normal work. This morning all was fine after the first windows boot. Yesterday, it took 2 additional windows restarts after the first boot for ESET to start with all Network protection modules fully functional. On 8th May just one windows restart was needed. On 7th May 2 restarts plus another 3 restarts with the workaround (the 3 modules modules disabled prior to windows restart and then re-enabled post restart) before I was able to get the 3 modules functional. I have run ESET log collector (1 days worth) on most days. The evidence so far is that it seems to depend on resource availability and perhaps sequence of events during start up which can differ from one restart to the next, and maybe even hardware configuration (4+ year old laptop but with an SSD hard drive and core i5 processor).

This is an ongoing experiment which may or may not produce a revelation tomorrow. A week or so ago, I did remove all 'custom' rules (excluding predefined rules and bar two manual rules related to a specific exploit) and for a day all seemed well. Then the issue reoccurred and given that I run ESET in interactive mode I assumed a 'rogue' rule had been recreated. My previously reported workaround worked this time but expecting the issue to reoccur again I turned on firewall advanced logging (FAL) prior to powering down for the night. Next morning no issue! So I turned off FAL and turned it on again just before powering down. Next morning no issue again. This cycle has repeated now for 5 days. So tonight I will not turn on FAL and see what happens tomorrow. Of course it's possible that the issue may not be limited to having just one cause (i.e. one or more rogue or corrupted rules) so one users solution may not resolve the issue for another user. I have wondered from the beginning whether in my case system loading at startup played a part and that initially fitted in with clearing down the rules solution. However, without knowing the nuts and bolts of FAL I can conceive that it could have an impact on the issue by slowing down the startup process in a controlled fashion and thereby allowing the firewall and the other internet protection components to start up normally. We will have to wait until tomorrow to see if there is any further mileage to be made in investigating that area further.

As you might expect :-( my workaround which apart from the odd occasion consistently worked, refused to work this morning despite half a dozen reboots. Every time I tried to enable the three network protection components they came up non-functional. So I followed Mahoneko's solution and deleted all 338 firewall rules bar 2 (which were to block a specific exploit). Having done that I was able to enable the three network protection components without difficulty. The only difference to Mahoneko's solution is that I kept clear of learning mode, i.e. remained in interactive mode. If a particular rule *is* the culprit it's of course possible that it may be recreated at some point and the problem start again. If that happens I will do as Marcos has just requested.

That's interesting. Had tried toggling disable/enable before unsuccessfully but without closing the GUI in between. Will try that next time as obviously preferable to my workaround of restarting windows. An additional observation. Just checked windows event logs and the non-functional status appears to correlate with this: This application took longer than usual to start up, resulting in a performance degradation in the system startup process: File Name : ekrn.exe Friendly Name : ESET Service Version : 10.0.386.0 Total Time : 871ms Degradation Time : 538ms Incident Time (UTC) : 08/04/2017 14:21:09 When I implement my workaround no such message is logged during the post-disable (Firewall, IDS, Botnet) windows boot.

I repeat a workaround which I already posted yesterday but so far no one appears to have commented on: Begin Quote. Open up ESET Smart Security 10 as soon as possible after Windows Startup. If the ominous red 3 flag is showing against Setup (this appears to occur often but not every time), open up Internet protection and permanently disable (only option unfortunately) Personal firewall, Network attack protection and Botnet protection. Restart windows. Wait a minute or so and Re-enable the aforementioned 3 functions. Apart from one occasion [Now two] where I think I did not wait long enough (i.e. processor activity hadn't quite dropped to the typical idle 5 to 7 % in my case) they always come back up fully functional. Obviously this workaround is less than satisfactory and not a long-term solution but it does provide some breathing space. End Quote I should add that I am assuming until I get time to test it that the Internet Protection section is in fact telling the truth when it indicates the statuses as functional or non-functional.

This is just a temporary workaround that works for me (Windows 7) and suggests the problem is some form of conflict during windows startup. It's also worth mentioning that I have for some time run a staggered windows startup in so for as reducing to the minimum the number of applications that start up automatically yet I still experience this issue which suggests it is not a resource issue. Open up ESET Smart Security 10 as soon as possible after Windows Startup. If the ominous red 3 flag is showing against Setup (this appears to occur often but not every time), open up Internet protection and permanently disable (only option unfortunately) Personal firewall, Network attack protection and Botnet protection. Restart windows. Wait a minute or so and Re-enable the aforementioned 3 functions. Apart from one occasion where I think I did not wait long enough (i.e. processor activity hadn't quite dropped to the typical idle 5 to 7 % in my case) they always come back up fully functional. Obviously this workaround is less than satisfactory and not a long-term solution but it does provide some breathing space. I would add that unless you are watching events during start-up there is otherwise no indication of a problem. The red warning against the system tray icon disappears after a few seconds even though the network protection component is reporting itself non-functional. Only by opening ESET Smart Security does it become apparent that there is a major issue.