itman

Suspect this is caused by Eset's Banking & Payment Protection. It in essence opens a hardened browser session under ekrn.exe protection. Did such activity occur around the time the Windows Event Log entry was created? However, this only occurs if FireFox was already opened. If B&PP is selected via desktop icon, it will open the Win default specified browser.

Don't you have direct contact info to Eset headquarters tech support in Slovakia?

What I will note is that it is virtually impossible via web search to find an authorized Eset reseller. A search for U.S sellers will point you to Eset U.S. web site in San Diego, CA. I have always made it a point to purchase sealed box versions of whatever Eset product I was purchasing from whatever source in the U.S., and never had a licensing issue.

Purchase a new license from the Eset web site or an authorized Eset retailer. Places like Amazon, eBay, etc.. are not authorized Eset retailers. If you have made customized changes within the Eset GUI, export those. Uninstall your existing Eset version. Reboot if not specifically requested to do so after uninstall. Install the Eset version you just purchased and activate it with the provided license key. If Eset previous settings were exported, import those into the newly installed Eset verion. Neither MBAM or SuperAntiSpyware are needed. If MBAM is installed, its real-time protection should be disabled since it can conflict with Eset's like real-time protection.

There is no "free" Eset product to start with. There are Eset products named NOD32 and Eset Cyber Security - for Mac's only. There is no Eset product name NOD32 Anti-Virus & Cyber Security.

Personally, I think the feature is a bit "spastic" to me. I had the same behavior occur in select earlier Eset versions. The latest versions so far have displayed the splash screen in a consistent manner; as least so far ......... knock on wood.

This reference: https://help.eset.com/eea/7/en-US/installation_command_line.html is for Eset Endpoint Antivirus ver. 7. Note however that the installer is named ees_nt64_enu.msi; not eea_nt64_enu.msi. The format for command-line installation is: msiexec /qn /i ees_nt64_enu.msi ACTIVATION_DATA=key:AAAA-BBBB-CCCC-DDDD-EEEE I checked your Eset download link and it is indeed eea_nt64_enu.msi, so I am a bit confused. Substitute eea_nt64_enu.msi in the above command as see if that will work. -EDIT- Here's a link to the French version: https://help.eset.com/eea/7/fr-FR/?installation_command_line.html . In the on-line help, the installer is repeatedly referenced as eea_nt64_enu.msi except in the command-line installation section. Looks like a documentation screw up by Eset to me.

I believe the problem here is your a using NOD32, a consumer product, versus Eset Endpoint, a commercial solution. Whereas Eset Endpoint might support license key entry versus command line option, I don't believe NOD32 has such capability. -EDIT- Are you referring to NOD32 AV for Business Linux Desktop version? If so, you posted in the wrong forum section.

I would say "hell would freeze over" first before Eset ever adds full wildcard support to either the firewall or HIPS. It has been a feature requested for years by multiple Eset users and "panned" by Eset with statements like "it will most likely be added in an upcoming future release," etc..

For some odd and unknown reason, the Eset firewall will often throw an alert about an insecure firewall rule in reference to the built-in equi rule. It usually occurs after an in-place Eset upgrade to a new version. You possibly answered one of those alerts as a block action which resulted in the rule being disabled. What appears to be triggering this activity is Eset's Application Modification detection which is only applicable if the firewall is set to Interactive mode. Bottom line - this activity appears to be a long running bug in Eset firewall processing.

Forget the DNS suffix bit. From what I see in this posting: https://www.reddit.com/r/Windscribe/comments/9o0bx6/windscribe_tries_to_route_rfc1918_lan_traffic_to/ based on the ipconfig /all display, no DNS suffix exists for the VPN connection. Using ipconfig each time you switch WindScribe off/on, check the shown IPv4 address for the WindScribe VPN connection. If it remains the same, add that IP address to Eset's VPN network connection for WindScribe local IP address field and see if that makes a difference.

To begin with, files the begin with "\\?\ are not virtual files. This is how Windows reference files locate in the C:\Windows\WinSxS directory. You can try specifying that path but it will still be an effort in futility since the file names for Win Store apps and the like are constantly changing. And its not just Win Store apps that have constantly changing names. Win system apps including Windows Defender do likewise. One reason Eset included the specification in Network Protection to allow Win firewall inbound apps was to accommodate this activity. And many of the above apps do auto updating of the Win firewall to accommodate this. I have previously mentioned about Eset also using the Win firewall outbound rules likewise to accommodate this activity. It appears that this is something that the Eset firewall in its present Interactive mode isn't capable of handling.

This subject has come up many times in the past. The Eset firewall doesn't support wildcard notation for executables. If one insists on using Interactive mode, one will be getting an alert whenever the app .exe changes path name; real or virtual.

My ISP is AT&T. The below TCPView local address screenshot shows "attlocal.net" appended to my assigned internal PC name. Eset's Network Protection primary ID method for my Ethernet adapter is the same DNS suffix: What my PC name.attlocal.net in TCPView converts to is the local IP address assigned by the router via DHCP for my PC; e.g. 192.168.1.xxx.

Eset's network connection detection is very much conditioned upon IP address connection. Like I posted previously, see if there is a DNS suffix that the Windscribe VPN uses. An IP connection monitor like SysInternals TCPView: https://docs.microsoft.com/en-us/sysinternals/downloads/tcpview should show that suffix when the VPN connection is active. Most likely the connection established for the WindScribe .exe. Then assign that suffix to the Eset VPN connection and see if that helps.

I strongly suspect this is the source of Eset ekrn.exe excessive activity you are observing. As @peteyt posted, his Eset VPN connection is not be deleted and recreated each time the VPN is stopped and started, As you posted previously if the network adapter connection VPN mini-port filter is likewise being deleted and added at each VPN stop/start event, this most certainly would be the cause. Perhaps the Wi-Fi Internet main network connection is the source of the VPN adapter connection being deleted from Eset? @peteyt is your main Internet connection Ethernet or Wi-Fi?

The only other thing I can think of is your VPN adapter connection is not properly set up in Eset firewall Known networks section. There should be two network connections shown there; one for your non-VPN adapter connection and one for the VPN connection, The VPN connection Network Identification data should show a network adapter type of "Virtual adapter (VPN, tunnel, ...)". Also there probably needs to be other identifying info specific which can only be DNS suffix as I see it. If the VPN network connection doesn't exist, you will need to set up one manually.

Also if you presently don't have a firewall rule to allow all inbound and outbound traffic, all protocols, all ports for the VPN executable, I would create one and move to the top of the existing firewall rule set. This in theory at least should allow all VPN traffic regards of IP address changes or the like.

Save yourself some time and stop looking. There is no option in the Eset GUI for 12.2.30 in regards to enabling AML. That won't exist until ver. 13. The scenario here is the same prior to when advanced behavior blocking was implemented. That is the feature in the form of the module being present is fully functional as far as I am aware of.

Does the behavior you're complaining about occur if the firewall is set to default Automatic mode?

It's there on my pre-released EIS ver. 12.2.30 installation: Detection Engine: 20128P (20191004) Rapid Response module: 15010P (20191004) Update module: 1018.1 (20190709) Antivirus and antispyware scanner module: 1555 (20190911) Advanced heuristics module: 1194 (20190918) Archive support module: 1292 (20190911) Cleaner module: 1200 (20190916) Anti-Stealth support module: 1155 (20190918) Firewall module: 1391.1 (20190912) ESET SysInspector module: 1275 (20181220) Translation support module: 1763 (20190916) HIPS support module: 1373 (20190916) Internet protection module: 1380 (20190920) Web content filter module: 1071 (20190605) Advanced antispam module: 7827 (20191002) Database module: 1110 (20190827) Configuration module (33): 1788 (20190719) LiveGrid communication module: 1054 (20190724) Specialized cleaner module: 1013 (20190627) Banking & payment protection module: 1160 (20190918) Rootkit detection and cleaning module: 1019 (20170825) Network protection module: 1682P (20190801) Router vulnerability scanner module: 1063 (20190724) Script scanner module: 1055 (20190924) Connected Home Network module: 1031.1 (20190621) Cryptographic protocol support module: 1040 (20190913) Databases for advanced antispam module: 3582P (20191004) Deep behavioral inspection support module: 1082 (20190716) Advanced Machine Learning module: 1034 (20190919)

https://forum.eset.com/topic/19083-eset-firewall-bug/

The "big enhancement" in ver. 13 is advanced machine learning. Just enable Eset pre-release updating in your current Eset ver. and you will receive the AML module.

OP is now "ranting" about Eset lack of VPN support in another thread. As @Marcos stated in that thread, Eset doesn't guarantee VPN compatibility. My take is Eset and assumed other AV vendors make reasonable "accommodations" in their software for VPN use. This would include the assumption VPN use is the norm; starts at boot time and disables at system shutdown time. Repeatedly turning VPN off/on during system up time would be one event I suspect AV's across the board might not anticipate and would respond to accordingly.

Post a screen shot of the Eset Detection log file or post individually event entries showing what malware Eset has detected. Eset can't clean a file containing malware if its an OS system or like critical file since it could bork your PC operation.