Jump to content

Outcast

Members
  • Posts

    48
  • Joined

  • Last visited

About Outcast

  • Rank
    Newbie
    Newbie

Profile Information

  • Location
    USA

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  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
×
×
  • Create New...