Jump to content

Outcast

Members
  • Posts

    48
  • Joined

  • Last visited

Everything posted by Outcast

  1. I'm just putting this here for future reference, so I can reply in 2 or 3 years when it's still an issue. Here is the conclusion of the support case I had open for this issue: That's the advice I get in response: Nothing in any way related to the bug I had reported. No, "Here's how to uninstall and reinstall, because we KNOW the product is 100.00000000% faultless, and therefore YOU are the problem. Now, deal with it and leave us the hell alone!"
  2. Support finally responded to me. Their answer makes no sense, since my phone isn't roaming when this happens.
  3. Thank you. The app should make this clear and in fact should hide or at least make that function unavailable, so users don't go through this aggravation.
  4. I've been trying to get a helpful response from ESET technical support on this since August 30, with no luck. I am a licensed user of ESET Mobile Security and have a Samsung Galaxy S9+ running Android 10 and ESET Mobile Security 6.3.66.0-0. Whenever I turn on the "When SIM card is removed" setting in Anti-Theft and trust the SIM card, my phone immediately gets locked by ESET Mobile Security. I unlock it, get prompted to trust the SIM card again, and a short while later, the phone is locked again by ESET. Each time, I see that a new SIM card has been added to the list of trusted SIM cards, with a new number. There are currently 7 SIM cards "trusted" by ESET Mobile Security, and I've had to disable "When SIM card is removed" to prevent this from happening.
  5. Thanks. As I mentioned above, I was not automatically updated to 14.2.10 until yesterday (June 28), but it came out quite awhile (two weeks?) before that. I do have product update checking enabled in the application, of course.
  6. Understood. My concern was that the two updates I had simultaneously queued might have each have wanted to push their own updates to the same files, and that the older of the two might erroneously "win out". For example maybe 14.2.10 intended to update "importantfile.dll" but so did 14.2.19. I don't blindly trust that the newer 14.2.19 file is what I ended up with. At the end of the day, if the product is so badly architected that a user has to worry about these things, it's not worth using. It's bad enough I was only pushed the 14.2.10 update on the same day the 14.2.19 update was already available. People who think I'm obsessing over nothing have no idea. I've seen coding errors mess up 7- and 8-figure retirement account balances. Was it ever made truly right? No one knows. The same expletives who can't decide if it's safe to turn on red have your life in their hands. Sorry for the mini-rant.
  7. Thanks. So the driver updates must have been associated with the 14.2.10 update. Again, as long as the application is designed to correctly handle stacked updates, everything should be fine. I personally can't imagine designing an application that would allow updates to be stacked the way mine were yesterday, unless it could handle them properly. I also can't imagine designing one that wouldn't routinely perform version and consistency checks. But that's me, and I've been told I'm crazy. Decades of working in IT has made me phenomenally and yet justifiably cynical in these matters.
  8. Don't feel too bad... I've been on that window many times and never noticed the gear icon at all. Even after seeing the above screenshot, I went in there and wondered why I wasn't seeing the same thing. It's not a great UI design element. It should be more obvious.
  9. It shows 14.2.19.0. Hopefully every file that was supposed to be updated for this version was actually updated, rather than being left at the version that was queued for 14.2.10.0.
  10. No, currently two updates are queued. I'm looking at upcu.xml which is the PCU configuration file, and it shows: <PACKAGES> <UPCU ID="1" TYPE="diff" BASE="14.1.20.0" TARGET="14.2.10.0" TIMESTAMP="60D9FE25" RESULT="0" CONTEXT="" /> <UPCU ID="2" TYPE="diff" BASE="14.2.10.0" TARGET="14.2.19.0" TIMESTAMP="60DA1521" RESULT="0" CONTEXT="" /> </PACKAGES> I used a separate utility to determine which files on my PC have changed since this morning. The driver files have changed, but the new version is indeed 14.2.4.0. I just hope the application is designed to correctly handled multiple updates in this manner.
  11. I've never seen a notice that a NOD32 update was successful or otherwise. I was concerned because one update was queued and then another queued on top of it. Decades of working in IT has brought my trust level down to zero. Thanks for the replies.
  12. Now all my ESET driver files (eamonm.sys, edevmon.sys, ehdrv.sys, and epfwwfp.sys) have been updated, but they show version 14.2.4.0 in their file properties. I don't know what's going on here. The support article advises doing an uninstall before updating. If I do that, am I going to lose all my settings? I know I can export/import settings, but I don't trust that facility to capture and correctly restore all settings, any more than I trust the uninstall/reinstall to save them.
  13. Thanks. I just clicked "Check for updates", and now it says that "14.2.19.0 is prepared". I hope that my installation will be correct and consistent, but I'm not going to uninstall and reinstall to ensure that it is.
  14. And this page says that in fact, 14.2.10.0 is indeed the latest version. Typo?
  15. This way of doing things can be problematic. I hope ESET puts control back in users' hands: Microsoft admits to signing rootkit malware
  16. I just got a notification from NOD32 that: "The application update to version 14.2.10.0 is prepared. Restart your device for all changes to take effect." I came here foolishly thinking that maybe I could see what was new in this version, only to find that: "ESET NOD32 Antivirus, ESET Internet Security and ESET Smart Security Premium version 14.2.19 have been released and are available to download." Why am I about to update to 14.2.10 if 14.2.19 is available?
  17. I didn't realize until after posting in this forum (and then running the "Show or hide updates" troubleshooter) that the update in question was actually being detected by Windows at all. It doesn't show in the regular Windows UI. I thought it was NOD32 being screwy. I purchased NOD32 directly, not through a distributor. Would they really accept a ticket I opened with them? I have "Optional updates" selected, because without NOD32 making me aware of some of these updates, I wouldn't see them unless I went out of my way to look for them in the Windows UI.
  18. I hope I've solved the problem. I ran the Microsoft "Show or hide updates" troubleshooter package, and it showed the KB4481252 update. I chose the option to hide it. I haven't yet confirmed that NOD32 will stop seeing and notifying about the update. https://www.tenforums.com/tutorials/8280-hide-show-windows-updates-windows-10-a.html
  19. Also... Pretty sure I don't even have Silverlight installed.
  20. Recently, NOD32 14.2.20.0 began notifying me that an update was available on my Win10 20H2 machine: "Microsoft Silverlight (KB4481252)" The problem is that Windows Updates doesn't actually list KB4481252 as being available for install, even after I hit "Check for updates" and expand "View all optional updates". It's nowhere to be found, which makes sense, since Microsoft released KB4481252 2.5 years ago. I know I can configure NOD32 so that it doesn't display this update (by not displaying optional updates), but I don't want to do that. Is there some other way? This is annoying.
  21. I ran out of time to edit that post. ESET loves its timeouts! Act fast! As far as support for the HIPS feature in general, I imagine that ESET knows most users don't want to continually babysit such a thing. Many years ago I wasted hours and hours of my time configuring HIPS software, and it's a losing battle and IMO largely a waste of time. Thanks again.
  22. I found a way to reproduce the HIPS alert. The alert remains for 60 seconds. I have the aforementioned notification duration for desktop notifications set to 30 seconds. It seems that that setting doesn't directly impact how long the alert remains on screen.
  23. Alerts are not notifications. Alert means "action may be required", and notification means "just letting you know". I have no clue why they would be lumped together. But whatever. The maximum value allowed for the "Duration" of desktop notifications is 30 seconds. That's how much time a user has to review and configure HIPS alerts? Ridiculous.
  24. This wasn't a desktop notification though, so I don't see why those settings would apply.
  25. Under "Advanced setup" > "Log files", my "Minimum verbosity" setting was and is set to "Informative". I had and still have "Close message boxes automatically" disabled. I have no clue how I can review the message that was displayed. My goodness, I was present when the alert appeared, and I simply did not have time to review the alert and formulate a response to it. This is a completely unacceptable design. I am saying this as a person who works with monitoring and alerting for a living. My users would be continually aggravated if I alerted them and then deleted the alerts before they could respond. I understand the need to balance convenience with alerting functionality, but this alert only appeared because I configured the product to alert me. I didn't configure the product to alert me but give me only 60 seconds to evaluate the alert, understand its configuration, and respond to it. Thank you very much for the replies.
×
×
  • Create New...