Jump to content

itman

Most Valued Members
  • Content Count

    6,505
  • Joined

  • Last visited

  • Days Won

    174

Everything posted by itman

  1. Run a default scan which uses the Smart scan profile by default. If it isn't obvious that a registry scan is running which should be, scroll to the top of files being scanned window where the scan parameters are shown. You will indeed note that a registry and WMI scan has been selected by default.
  2. Like I posted previously, I have run multiple WMI scans in testing today and WMI never crashed on my device.
  3. Applicable to Dell users is the following from the above linked mydigitallife.net thread: More info on service tag changing here: https://community.spiceworks.com/how_to/1532-how-to-change-dell-service-tag-on-latitude-and-inspirion-laptop and here: https://forums.mydigitallife.net/threads/dell-bios-editing-removing-bios-lock-changing-service-asset-tag-software-here.19369/
  4. This doesn't work! Any profile based scan auto scans registry and WMI. Doesn't bode well for anyone that has set up Eset scheduled scans, Only thing that appears to bypass the registry and WMI scanning is a Custom scan with of course, those options not selected.
  5. Here's an article on WMI issues from Microsoft: https://techcommunity.microsoft.com/t5/ask-the-performance-team/wmi-common-symptoms-and-errors/ba-p/375483 Possible crash reasons: 1. High Memory Usage by WMI Service or Wmiprvse.exe Lower than normal available memory on the system Instance of wmiprvse reaching or exceeding 512 mb on Vista and newer, or 128 mb on XP or Windows 2003: Quota Violation issue Large repository C:WindowsSystem32WbemRepository folder and objects.data file is 1gb or larger 2. High Handle Count on WMI Components Source: Microsoft-Windows-WMI Event 5612 Wmiprvse.exe exceeding handle quota limit Event WMI has stopped WMIPRVSE.EXE because a quota reached a warning value. Quota: %1 Value: %2 Maximum value: %3 WMIPRVSE PID: %4
  6. Doubtful that was the cause. After the latest Eset upgrade, I ran a registry and WMI scan. No WMI crash as a result or for that matter, at any time previously.
  7. Looks like there's an issue with Eset and periodic WMI crashes on Win 10 based on postings in this thread: https://forum.eset.com/topic/23826-wmi-provider-crash/ . At first I thought it might be related to Win 10 2004 and the latest Eset release. However, one poster stated it occurred prior to the latest Eset release. Another poster stated he was not running Win 10 2004 but running the latest Eset release. This also might be happening to others using Eset but do not check Win 10 Reliability events. I personally have never had such a WMI crash and frequently check my Reliability events.
  8. Based on what is shown below and applicable to Dell devices, getting rid of Computrace in the UEFI/BIOS requires "specialized knowledge": https://forums.mydigitallife.net/threads/computrace-causing-problems-need-help-to-remove-from-bios-phoenix-bios-f-2e.16042/page-3#post-1128698 What I have gleaned from the above is Computrace must be set to "Disabled" in the BIOS. Note this can only be done if was never activated. Hence the above "gyration" to get the UEFI/BIOS to the point where it can be set to disabled. Once Computrace is disabled, I believe a UEFI/BIOS version not containing Computrace update via off-line media flashing or in-Windows updating, if available, will succeed. Finally, a UEFI/BIOS version not containing Computrace must be available and provided by the device manufacturer. Also if Computrace is "permanently" disabled in the UEFI/BIOS as noted in the above procedure: I suspect Eset will longer detect its presense. If it does, then its a bug on Eset's part. Once Computrace is permanently disabled, it can never again be re-activated; excluding above hacking method. Also noteworthy is that government grade anti-theft mechanisms can be hacked. 🙄
  9. Based on what Aryeh posted above, Eset will continue to show the detection as long as Computrace still exists in the UEFI/BIOS. Whether its disabled or not appears to be immaterial to the detection.
  10. Here's the problem. The default Eset scan uses the Smart profile. Scans targets are N/A for this scan type. Appears Eset selects them by default and its including the Registry and WMI database scans. My present workaround till this is fixed was to create a new scan profile named; e.g. Smart scan w/o registry and WMI, and set that as the default profile. See below posting.
  11. Also the problem here appears to be not Eset's eamsi.dll, but CSO's new "Trusted mode" feature that is also causing issues with other running software: https://www.pcgamer.com/csgos-trusted-mode-anticheat-system-is-live-but-its-causing-problems/ Believe this is something that needs to be reported to CSO's developers. Security software mechanisms that worked prior to Trusted mode implementation should also be allowed in this new mode. Also of note: https://blog.counter-strike.net/index.php/2020/06/30683/ It also appears that Symantec does offer Authenticode signed certificates: https://urlssl.net/symantec-code-signing-certificate.html . Therefore the issue is not with Symantec certs. per se. -EDIT- Believe this is the issue with CSO. Eset's cert. for eamsi.dll is not an EV cert.. However, Eset also countersigned eamsi.dll with it's Microsoft issued driver cert. which is an EV cert.. This appears to satisfy most apps requirement for an Authenticode signed certificate, but not for CSO it appears. This is also why Code Integrity errors are being thrown by some apps.
  12. Its use from a security viewpoint is critical. It allows AV vendors at a minimum to scan packed. encrypted, and obfuscated scripts after they load into memory and unpack, decrypt, and un-obfuscate; but prior to execution; i.e in memory sandboxing.
  13. I assume the game is flagging eamsi.dll for the same reason the Win 10 OS is: My Win Code Integrity Event log is full of these events. Time Eset finally resolved this issue that has existed for some time. -EDIT- Believe the issue is the .dll is signed with a Symantec code signing cert.. And no one trusts Symantec certs. anymore. It is also signed with a Microsoft code signing cert. but that doesn't appear to be sufficient anymore.
  14. I will also add that in-product updating is always a more secure update method that manual updating; contrary to popular belief. Manual updating opens one up to a phishing attack. A recent example is the WastedLocker ransomware that deployed a fake Google Chrome update request.
  15. What it's showing is one license seat has been activated and one license seat is available. Eset's uses the term "seat" to refer to how many devices Eset can be installed on. In your case, you only have one Eset license issued to you and that license can be installed on up two a maximum of two devices; i.e. seats.
  16. If you're asking if it's safe to whitelist the web site, the answer is no. The site appears to have been compromised with a malicious JavaScript. Just accessing the web site could lead to possible malicious activity against your device.
  17. Open Eset GUI. Then select Network protection -> Troubleshooting wizard. If Recently blocked or applications count shows a non-zero value, do the following.. Open the Troubleshooting wizard and determine if one of the shown block connections relate to this smartPSS software or the cctv camera.
  18. I strongly recommend reading the Kaspersky article referenced in the above: https://securelist.com/absolute-computrace-revisited/58278/ . Note this section: 4. Cases of Unauthorized Activations. If Computrace/Absolute does not have a record of the device in their database, there is nothing they can do about helping you deactivate it. Hopefully, that is not the case here. Finally, the article by Bill Morrow notes this: This is the first I have heard of this and certainly hope it is not true. It might also only apply to Lenovo ThinkPad products.
  19. No, it's not normal. On my Win 10 1909 build, ekrn.exe is currently using 73 MB. What did you use to determine ekrn.exe memory usage? Win Task Manager?
  20. Periodic WMI crashes have occured before: https://support.microsoft.com/en-us/help/959493/the-wmi-provider-host-program-wmiprvse-exe-may-crash-on-a-windows-serv So I suspect an issue exists in Win 10 2004 given all its problems to date. Why this might manifest with Eset installed remains to be determined.
  21. Did you reboot after uninstalling Kaspersky? If not, this plus the subsequent install of Eset might have cause WMI "to flake off." Does the WMI issue persist today assuming you have rebooted since 7/9/2020 6:41 PM?
  22. Unless Computrace has revised their policies, I wish you luck on this one. By design once Computrace is activated, it cannot be deactivated by anyone including Computrace.
×
×
  • Create New...