SlashRose

I hate when things are changed for the sake of change. I like that ESET maintains the same interface throughout multiple versions and yearly updates. Antivirus isn't like an ide that you maybe staring at for a while. It should sit in the background and rarely be interacted with. Last thing anyone should want to do is waste 10 minutes looking for a setting because the interface has been updated.

Yeah I think if there was more communication it would stop people posting on here. For example a lot of people post their own sites on here after emailing them and having no answer. Often there is malware but if Eset replied it would prevent then having to come here and break forum rules.
I know this may be easier said than done as they probably receive a lot of emails 

Description : Multi-threading/core for on-demand scans.
Detail: ESET only uses a single CPU thread/core for on-demand scans, not utilizing my M.2 SSD even close to the limit. As a consequence on-demand scans take a *lot* longer than competing products that make use of multi-threading (up to 24 logical cores on my system).

I understand the spinning platter situation, but modern systems don't use HDDs for system drives anymore. And even then, scanning network shares on my HDD based NAS is faster when done by multi-threaded AV products.
All of my own and my customers' computers use SSDs for years already. Defender peaks at over 2500 mb/s during on-demand scans running 24 threads/files in parallel, meanwhile ESET is chugging along one file at a time. This should be brought up to more modern standards rather sooner than later.
Furthermore large compressed archive files should be handled by multiple threads, too, especially for the uncompression part of the operation.

What is meant by "whitelisted" files in this context? I noticed that out of the 456 .exe files contained in the WSSC GUI (Nirsoft, Sysinternals) only those 5 are re-read after reboot that qualify as "potentially unsafe applications" (regardless of the respective settings and exceptions). All none exe files on my system seem to be re-read by ESET after each reboot, regardless of module updates.
This includes all TTF (font) files, but also things like loading thousands of Lua addons files, hundreds of Toc files, dozends og TGA and font files when World of Warcraft is started for the first time after a reboot, plus NVidia and Battle.net client cache files.
I assume that most of these files are only re-hashed instead of rescanned (analyzed)? But it's still re-reading of files that were already scanned when the PC was last turned on (or just before reboot a few minutes ago).

Description : Improve ESET update server capacities.
Detail: Last week some connections to (some?) ESET update servers were abysmally slow, as in downloading at 0.01-0.1 mb/s while my internet line offers close to 13 mb/s. As a consequence download single update files took a *very* long time.
According to e-mail support some major ESET module update caused high spikes, so the server/connectivity infrastructure should be improved to handle these spikes much better.

I had to perform some additional system and Eset Networking modifications and now Eset Networking/firewall is "peacefully co-existing" with my device/router. If after reading this, you get a migraine headache. Take two large migraine relief tablets and go to bed.
I forgot to replace Eset firewall default DHCPv6 rule which doesn't work with my router with the Win 10 firewall DHCPv6 rules that do work.
Next, I noticed that Eset Network Identification active connection processing appeared borked. Decided it was time for a full Win 10 network reset. Upon system restart from this, I noticed that my IPv6 DNS servers were fully initialized in both Win 10 and Eset. That is external AT&T IPv6 DHCP/DNS server showed as primary IPv6 DNS server in Win 10 and local subnet IPv6 DNS server as secondary IPv6 DNS server in Win 10. Additionally,  both IPv6 server IP addresses showed in Eset DNS server Zone. This result is critical for Network Inspector correct DNS server determination which I will get into next.
This morning upon first Win 10 fast startup of the day, I observed something never seen in Eset use to date. Both IPv6 server IP addresses showed in Eset DNS server Zone. However, at that time only the external AT&T IPv6 DHCP/DNS server showed as primary IPv6 DNS server in Win 10. Within a couple of minutes, the handshaking processing completed and the local subnet IPv6 DNS server was assigned as secondary IPv6 DNS server in Win 10.
If the above processing holds true from now on for all future system restart modes, it confirms prior statements made by Eset that Network Inspector is determining and saving network settings at either Eset installation an/or when the Windows network is completely rebuilt from scratch as is done via Win 10 network reset option. In my case, this is critical for Eset not misinterpreting the various IPv6 DNS setting combination settings done by my router as rogue DNS server setting modification to my router.
The last remaining piece of this Eset Networking inspection puzzle mess was the misinterpreted outbound network traffic from my device as inbound traffic upon resume from system initiated sleep mode with no prior system sign off.  This had settled down to only DNS and mDNS; i.e. port 5353 traffic as show below:
Time;Event;Action;Source;Target;Protocol;Rule/worm name;Application;Hash;User
10/3/2021 10:38:32 AM;Communication allowed by rule;Allowed;192.168.1.xxx:5353;224.0.0.251:5353;UDP;Rule created by wizard for: svchost.exe;C:\Windows\System32\svchost.exe;010DB07461E45B41C886192DF6FD425BA8D42D82;NT AUTHORITY\NETWORK SERVICE
Time;Event;Action;Source;Target;Protocol;Rule/worm name;Application;Hash;User
10/3/2021 10:38:33 AM;Communication allowed by rule;Allowed;192.168.1.xxx:57839;192.168.1.25x:53;UDP;Rule created by wizard for: svchost.exe;C:\Windows\System32\svchost.exe;010DB07461E45B41C886192DF6FD425BA8D42D82;NT AUTHORITY\LOCAL SERVICE
Turns out the above is being generated as a result of NetBios and mDNS connectivity handshaking processing from the Ethernet PowerLink adapter my PC is connected to. Eset networking is totally clueless on how to handle this network traffic. So I created specific Eset firewall rules to handle the above.
Bottom line- Eset has really created a network mess with current Network Inspector processing for select customized routers. God help you if you happen to fall into this category.

Now how do we consumers report problems that happen to our products?
Because I'm always seeing problems and never a solution. and a lot of delay to solve, whenever what I hear is on V15 it will be corrected.

And that's exactly our problem here Marcos, you never see reported problems, no matter how much you show them to them and that's why they are not useful here, as I already wrote to their superiors!

Good advice. I am tired of wasting my time in this forum reporting Eset problems that ultimately get dismissed.

itman can't explain that to him, he's always right, he's not true, but he believes it, so let's let him believe in it. 

I will again reiterate what happens on my EIS installation when Network Inspector is enabled.
At system restart time, a half dozen ekrn.exe UDP and UPDv6 are established along with an ekrn.exe port 138 connection. These remain for a couple of mins. and are then dropped. In the past, one ekrn.exe UDP and UDPv6 remained. On ver. 17, the UDPv6 connection is usually permanent dropped and not later reestablished.
Upon resume from Win 10 sleep mode, a dozen ekrn.exe UDP and UPDv6 are established along with an ekrn.exe port 138 connection. These remain for a a couple of mins. are then dropped. In almost every instance on ver. 17, the UDPv6 connection is usually permanent dropped and not later reestablished.
In regards to the ekrn.exe UDPv6 connection when dropped. If I perform anything related to current network status such as ipconfig /all or view network settings in Win 10, the ekrn.exe UDPv6 connection is reestablished and remains in effect until system shutdown/sleep mode.
With Network Inspector disabled, I have no borked Eset firewall activity where my normal outbound network traffic is being interpreted as inbound traffic and being blocked upon resume from sleep mode. Although there have been two incidents where this occurred for a couple of port 53 DNS connections.
Now really, is this passive behavior?
Network Inspector stays permanently disabled on my device.
-EDIT- BTW the same above behavior occurs the minute the Network Wizard is opened with the result being the ekrn.exe UDPv6 connection being permanently dropped.

Err, what? I posted previously that it resolved all my IPv6 connectivity issues and Eset recognizing that an IPv6 exists via establishment of an ekrn.exe connection monitoring UDPv6.
All of them. There never has been an issue with the Win 10 firewall properly recognizing my IPv6 connection or interfering with any aspect of it connectivity processing.
I have previously posted Eset needs to provide an option to only use its firewall for outbound network traffic of user custom rules. All other network traffic would be handled by the Win firewall.
This, I 100% disagree with. If everything I have posted in this thread hasn't  effectively communicated there is an issue with Network Inspector, nothing I posted further would do so and would be a waste of my time.

I need to correct my prior postings in regards to Eset Network Inspector and network inspection processing.
Eset's network inspection processing is a critical security mechanism used to inspect IPv4 and IPv6 network traffic via proxy mechanism. It is "baked" into Eset and there is no way to disable it. Nor should you ever want to do so. Its malfunction in regards to monitoring of IPv6 network traffic in ver. 14 is the primary reason I embarked on this long resolution quest.
Eset Network Inspector is the newer feature Eset introduced to monitor router tampering activities. It however does deploy Eset network inspection processing to do so. Besides Network Inspector borking my router's IPv6 configuration activities at system startup time, it was also failing to initialize the network inspection IPv6 network connection.
BTW - disabling Network Inspector doesn't appear to fully disable its processing. Another Eset feature that uses it is the Network Wizard. The difference being when the Wizard is deployed is after system startup time. Since my router would be fully initialized at this time, it causes no adverse activities to occur against it.

Interesting.
My ISP router has an excellent stateful firewall plus IDS protection. Hence, external network attacks like these are dropped on the WAN side of the router. Also, more reason to disable Eset Network Inspector if there are suspicions it might be tampering with any internal router mechanisms.

It sort of says it "helps" with identifying open ports and vulnerabilities, but doesn't seem to indicate it has any protective role. So how is it a critical security mechanism?  And on a side note, now I have to/should post about updates hanging again, this product is a mess. 
 

Correct.
It also resolved a more serious issue that manifested on ver. 17. Upon resume from sleep mode, it appears the Eset firewall wasn't initializing itself properly; or not fast enough. Note this didn't happen upon every system startup from sleep mode, but it happened enough to be disconcerting.
Network Wizard showed blocked svchost.exe inbound traffic to ports 53, 137, 1900, 3702, 5353, and 5355. The "rub" is the remote IPv4 address shown was my device assigned IPv4 address. In other words, Eset firewall; or more likely Network Inspector, wasn't initializing properly and was interpreting legit outbound traffic from my device as inbound traffic and blocking it!

I, like you itman and others, no longer see Eset as trustworthy and where since Corona the attacks have increased a few times. This is not a fine kind of Eset.

Well, it didn't take AT&T long to detect my Cloudflare IPv6 DNS server usage and start interfering with that. So I am now back to using their auto assigned DNS servers and Eset's networking resultant borking of those connections.
But I have finally confirmed the Eset culprit. It is the Network Inspection feature. Disabling that not only solved the auto IPv6 configuration by my router problems but most importantly, the totally spastic Eset firewall behavior upon resume from sleep mode.
I also question the use of Network Inspection processing when the Public profile is deployed. Its applicable Eset firewall rules only allow Trusted network device communication. When using the Public profile, no local network devices are trusted.

But in the case of updating the end user is only half the equation. The company should be logging updates as well and trying to find a solution. Turning users into trouble shooters is not the answer. All this constant drone to submit logs is driving users away. 

Kind of ridiculous putting all the work on the end user. 

What are you talking about I totally agree, you are correct in your opinion this away from the users.
I am finding that ANTIVIRUS ESET does not have TELEMETRY to identify all these problems.
The worst thing is that the updates of the product problem fixes take a long time to get out to the END user, that's because we pay dearly for the product, so much so that competitors like KASPERSKY products are very cheap and have several promotions and even more has FREE antivirus.
I am finding that ESET is unable to work faster.

By default, Eset network Profile selection is "use Windows settings." As I previously posted, Win 10 firewall default network Profile setting is Public. Therefore if using default settings on both, Eset's Network profile would always be set to Public.
-EDIT- Some additional detail here.
Win 10 firewall defaults to the Public profile for a reason. It auto disables Network Discovery. The way you're supposed to securely do file sharing on a Win 10 device is to right mouse click on the file to be shared on the network and select the "Give Access" option.
This also brings up why Eset has the "Home or Office networking" profile option in the first place since it in effect, overrides Win 10 built-in network security. The most damning aspect of the Home or Office networking Eset profile is it enables NetBIOS access by default.

This error has been around for quite a while, namely since the Windows 10 May Update.  
I find it really, very strange that the Eset developers/coders do not notice this and this error is taken over by Eset from build to build, as well as other bugs and all this moved me to stop constantly sending logs etc. and not to engage me so much anymore, 

What I am observing is there is a bigger issue. Appears Eset is not properly initializing coming out of Win 10 fast startup mode. I am having issues with Eset Network Protection; namely Network Inspection not working properly.