howardagoldberg

I just upgraded my Pixel 3 (Verizon Wireless) from Android 9 to Android 10 on my secured home network. Interesting issue encountered: After the update, ESET Mobile Security flagged my home network as an 'insecure public WiFi hotspot,' and recommended that I disconnect! Reason? ESET had not been given location permissions and therefore could not resolve the SSID of the network (even though I was connected to the WiFi). Giving ESET location permissions resolved the issue, no muss - no fuss. So, just as a heads up: If network aware apps aren't working correctly (security apps, WiFi/Network scanning apps, apps that sync over WiFi such as DejaOffice) after updating to Android 10, make sure you give those apps location permissions. As an aside, hopefully ESET folks will test this themselves, and roll out an update to account for this change in Android 10 so less savvy users do not become concerned that they are suddenly connecting to a non-secure public network from their home! 😉 @Marcos

How does that compare to AVAST's method?

I came across this article today via "Ask Woody" ... https://textslashplain.com/2019/08/11/spying-on-https/ The article specifically calls out AVAST, and I have not seen this warning in Chrome or other browsers (on the stable/release channel) using ESET. Can any of ESET's staff can comment on how ESET monitors HTTPS traffic, and if the 'issue' with AVAST is something ESET users need to be aware of vis-a-vis browser warnings/compatibility? Again, I've encountered no issues on this front ... I am simply curious! 🙂

My cleaner module version is also 1195 dated 6/10. I don't use Sandboxie and no issues to report - just confirming that this module has not been updated on my systems (one Win10, one Win7). But based on @Marcos comment, this seems to be intentional.

This module is still not listed on the Windows 7 system. Is this expected behavior (12.1.34.0)?

@Marcos Thank you for the clarification, very much appreciated.

@Marcos ... As stated in my original post, I am not on pre-release updates on any of my systems. The modules on my Windows 10 system were pushed with my update settings on their default channel (regular release). The release may be staged, which is a reasonable explanation - but the modules are being pushed out for users on the regular release channel, unless I am a unique exception.

I have ESET AV 12.1.31.0 running on a Windows 10 (1809) system and a Windows 7 SP1 system ... both systems are 64-bit and fully patched/up-to-date. This morning upon booting up both systems, I noticed the following: On the Windows 10 system I noticed that a new module is now listed: 'Deep Behavioral Inspection Support Module' (version 1068.1 / dated 03/21/2019). This module is not listed on the Windows 7 system. On the Windows 10 system, the Anti-Stealth Support Module had been updated to version 1150 (dated 02/25/19). On the Windows 7 system this module is at version 1148 (dated 02/11/19). On both systems, ESET appears to be updating itself normally (both have detection engine 19121, Antivirus/Antispyware Scanner module 1550.1, etc. as of the time of this posting - 06:30 Eastern/US - in fact all modules 'match' across systems expect for the two listed above). Any guidance/thoughts? Thank you for any insights that can be provided! Note: Neither system is receiving 'pre-release' updates, both systems are on the 'regular' update channel.

I completely understand the frustration you may be feeling, and that it looks like ESET could be the culprit. But, if rebooting resolved the issue - assuming ESET was still installed and you did not make any changes to ESET's settings, then it does not sound like it is an ESET issue to me. There have been issues with network cards on Win7 after certain Windows Updates. Depending on how up to date you are on patches, that could also be causing an issue. https://support.microsoft.com/en-us/help/4009469. I believe they are resolved now, but if you delay updates, etc., that could be in the mix.

On Win7, with 12.1.31.0 ... My network info and LAN status look exactly as they should. So, your screenshots above may not be related to ESET.

This morning, my ESET Mobile Security, running on a Samsung Galaxy S7 (Verizon), was updated to version 5.0.25.0-0 via the Google Play store. Yesterday, while I do not recall the version number - in the 'about' section - the app indicated it was a 64-bit app: "ESET Mobile Security (64 bit). After the update, in the about section, it now reads "ESET Mobile Security (32 bit). Why would the update change the 'bitness' of the app? Should I uninstall and reinstall? This is very odd behavior!

Marcos, I know that "security center" has been around since XP ... but the way it is implemented in W10 is very different from earlier iterations. I will ignore for now, but think it may be something ESET wants to look into. Thank you.

I would not have even noticed an issue, however ... this morning I was checking the log files in the event viewer after booting my computer and noticed the following: At 11:26:37 PM last evening (US/Canada Eastern), the following error was logged: ESET Kernel | Registration to Windows Security Center was not successful (USER: SYSTEM) This error must have been logged at or near the time I shut down the computer last night (not put the system to sleep, but actually powered down). This is a Windows 7 x64 system - fully patched and up to date. ESET AV version 11.2.49.0. Going to the Windows 7 "Action Center," ESET is properly identified as the AV installed, and is reporting that it is on and up to date. ESET itself is reporting "green" (You are protected). Had I not, by chance, been looking at the log files, nothing would have presented as being amiss. This error has never been logged before on this system. Two thoughts/observations: 1) I was not aware that there is a "security center" on Windows 7 that ESET needs to "register" with as there is on Windows 10 2) The Antivirus and Antispyware module was updated to 1541.1 at some point between last evening and this morning Could the new module - perhaps pushed out late last evening - have been attempting to register with the Win10 security system, but failed, because this is a Win7 system? I know that Win7 checks to see what AV is being used, but it is not the same background process that is used in Win10. There was no similar error message logged on my Win10 system, which makes me believe I may be on the right track here. Thoughts?

And just as I posted the above ... manually checking (again) on two systems pulled a 804kb update which brought me to the current detection engine. However that download of less than 1MB took about 90 seconds. Not a long time, per se ... but on a 100Mbps link, very slow. I am thinking there are server issues at your end? Please advise.

Running ESET AV 11.1.54.0 on a number of x64 systems (Win10 1709, Win10 1803, Win7, Win 8.1). ESET is reporting all is normal, and the last successful check for updates was at 6:23 a.m. EASTERN (U.S.). However, the last successful update was at around 6:45 p.m. EASTERN last night - nearly 12 hours ago. All internet connectivity is normal (obviously, since I can post this). Have no updates been pushed over the last 12 hours? Current detection engine on all my systems is 17499. Last engine shown at hxxp://www.virusradar.com/en/update/info/ is 17501. Is there any issue with the update servers pushing updates. Manually checking also results in no errors, but also no updates.

If we have 11.1.42.1 installed, will this new version update automatically on top of the current version to work correctly, or will we have to uninstall and install "fresh?" as was necessary for many users last time?

@Peter Randziak, thank you for this explanation and for making clear that the reason for pulling 11.1.x.x was not due to security concerns/functionality bugs. It would be very helpful, in my opinion, that when such actions are taken, that reasons be offered pro-actively vs. letting users wonder what is going on. I appreciated your responsiveness!

@Marcos @Peter Randziak ... can we please have some answers as to 1) Why 11.1.x.x was pulled, and 2) For those of us who have 11.1.42.x installed, what concerns should we have? Looking at the EIS forum, the thread on uninstalling 11.1.42.x leading to a non-bootable machine is highly concerning, as is the total lack of documentation as to why a major revision was pulled, and users were not notified.

@Marcos I was actually just about to post about this. I had turned on a computer not used frequently to run updates, and noticed that ESET did not update to 11.1.42.1 AND that 11.0.159 is what is offered on the downloads page. The fact that 11.1.42.1 was PULLED is demanding of a public explanation. After all the issues that have been reported regarding QA testing, does this mean that those of us on 11.1.42.x are running buggy security software? Should we "downgrade" all of our systems back to 11.0.159? The lack of transparency and communication on what is clearly a critical issue is concerning, and almost intolerable. Please @Marcos, explain to us why 11.1 has been pulled and what are the risks for those of us that were already upgraded? Thank you.

@anton83 Do you work for ESET? How do you know? I think this question needs to be answered by @Marcos or @Peter Randziak. I am not worried, I want to know whether to block the update for the time being or not.

Is 11.1.42.1 fully compatible with the forthcoming Windows 10 Spring Creators update which begins release tomorrow? Are there any issues/caveats users should be aware of? Thank you!

@Marcos I understand the need for some percentage of users to serve as beta-testers/pre-release update testers. However, I have a home office with only a handful of systems, none of them non-critical. In other words, when a machine has an issue, I pivot from doing my job to working as my own IT department. While I have those skills, it is not my primary function. On the other hand, if ESET were to offer incentives for people both using and providing feedback for pre-release updates, that would be another thing to consider all together, as I am always looking for cost savings. There have been a number of QA issues over the past month. They have been detailed in these forums, by me and others. Yes, this one is completely cosmetic, and I do understand that. When there were installation issues from 11.0 to 11.1, I switched to pre-release to get the correct configuration module, then switched back to "regular." At that point, almost all the protection modules failed (big red warnings!), and I uninstalled and reinstalled "fresh." That whole process took several hours. I am not going to potentially spend hours over a splash screen issue. It just needs to be fixed via the next regular update.

@Marcos Thank you for the prompt response. I am not switching to pre-release. The last time I switched to pre-release and then back to regular release completed corrupted my installation; and since the issue is not critical, but cosmetic, I have no desire/time to play beta tester in this instance. I was able to also test on a Win10 machine without a SSD drive, and the issue is reproducible so it is not Win7 specific. I am pleased that the issue is being acknowledged, but still leaves me with the concerns that: 1) If this setting is not working properly, what other custom setting are not working properly? And, 2) There are general QA issues which need to be addressed. I will wait for the regular release of the module, and report back to you.

It is set to 0. Again, in the settings, it is set to "off." This is resulting from a "clean" install of 11.1.42.x

@Marcos @Peter Randziak While this has been addressed in other topic threads, no one from ESET has thus far responded. Since updating to 11.1.42.0/1 (via a fresh install, as the update process was originally problematic), the splash screen is shown during boot up on Win7 x64. The setting for the splash screen is set to "off." Please advise. Thank you.