itman

Another recent posting on this issue here: https://forum.eset.com/topic/39433-antimalware-scan-interface-amsi-integration-has-failed-endpoint-11020320/?do=findComment&comment=178892

Unless things have changed, MicroCenter offers their PC purchaser's a free one year license for either NOD32 or Eset Internet Security: https://store.eset.com/us/offers/mc/ . If this is still their policy, I would discuss with the store manager why someone sold you a license for Eset.

As far as applying these updates, use the following links; https://www.catalog.update.microsoft.com/Search.aspx?q=kb4474419 https://catalog.update.microsoft.com/search.aspx?q=4490628 Download the KB4490628 update first since it's the service stack update and needs to be installed prior to the KB4474419 update. The main question is if these updates will install w/o issue on the Win 7 Superlight ver.. I assume they will.

Appears the ver. 16.0.28 installer does support this Win 7 non-standard ver.. Ref.: https://www.minitool.com/news/windows-7-lite.html

More info on this ransomware here: https://www.bleepingcomputer.com/forums/t/771041/rcru64-ransomware-idid-random-6-mailemailrandom-4-support-topic/ . If anyone can come up with a decryptor, this would be the place. At present, appears no one has been able to do so.

It depends on if you purposely disabled the Windows firewall on all your network endpoint devices which is doubtful.

Assumed here is your endpoint devices are using the Windows firewall since Eset Endpoint AV does not contain a firewall? Also assumed is WSC most likely is warning that the Windows firewall is not running on your endpoint devices for some reason. This can be verified by opening WSC on one of the endpoint devices and then opening Virus & threat protection. Next, mouse click on "Manage providers" which will show current device firewall status.

Who is the parent process? Ekrn.exe?

It was a typo on my part. I corrected my above posting to show 8883.

It appears Chromium based browsers interface with Google Safe Browsing differently than done in FireFox. In Firefox, Safe Browsing detection causes Firefox to display a full red web page alert with option to Go back or override the warning. Perhaps the override causes another full domain lookup which then allows Eset detection to process correctly.

Well, Chrome is detecting it. Notice the "Dangerous" tag prior to the domain name? Might be an issue with Eset phishing detection "kicking in" on a Chrome connection override situation.

Do you have Sticky Keys option enabled?

Google SafeBrowser detects the domain in Firefox and I assume also in Chrome.

Also, I tried to run the script. As the below screen shot shows, the script has a syntax error and will not run; I have to believe that this PowerShell activity at system startup is being created by something else.

Here's what's weird. Using both Firefox and QUALS SSLab Server test, windows.dns.nextdns.io would not resolve when I originally tested. Now, both have no issues.

It appears the PowerShell command is removing an existing AppxPackage ver. of EsetContextMenu.msix and replacing it with a new ver. of the same. This might have been created to be run as a run once maintenance activity by Eset at system startup time and then be removed. It appears the removal activity got borked in some way and the command is running at each system startup plus not terminating itself. Suspect there is a scheduled task that is performing this activity. Or, a registry run key is the source for the activity.

This is not a valid domain name. It won't resolve in Firefox or any of the SSL server validation web sites I tried.

Appears you purchased a boxed version of Eset. Standard retail practice with boxed software is once the box seal is broken, the software is not returnable for a refund. However, the assumption here is that the software is usable in that it can be activated and the license has not expired. Eset can't help you in this matter since you did not directly purchased the software from them. Your only recourse here is to escalate the issue to the retail store management. If they still refuse the refund and you purchased with a major credit card, you can dispute the purchase with the credit card issurer.

Let's refer back to this posting. I also had Eset firewall issues when upgrading to ver. 17. They didn't cause this black screen issue; but other problems. All my issues were resolved by resetting Eset firewall rules back to default settings which of course, wiped out all my custom firewall rules. Now as far as I am concerned, the issue isn't directly related to the ver. 17 upgrade; rather the ver. 16.2 upgrade with the problems surfacing in the ver. 17 upgrade. After the ver. 16.2 upgrade, I observed that the Eset default rule ordering had changed. Most notably, the first 6 rules or so. Since these are default rules, there was no way to revert to the normal default rule ordering other that a full firewall rule reset to default which I did not do since I didn't want to lose my custom rules. Also, export and import of rules did not fix the issue. All this was very odd to me, but I did not report the issue in the forum.

I'm not having or ever had any issues in this regard. I just posted one way to try to diagnose the issue. Additional refs. on the subject here: https://www.techtarget.com/searchenterprisedesktop/tip/Steps-to-fix-a-black-screen-in-Windows-11 https://www.windowscentral.com/how-fix-black-screen-problems-windows-10 Neither article mentions AV software as a possible sourec.

The long black screen at Win startup time is obviously a Win startup issue. When this occurs and after the Win desktop is displayed, open Win Task Manager. Then open the Startup tab. Displayed are tasks that ran at system startup time and their impact on startup time. The only Eset task shown here is "Eset Command line Interface"; i.e. ecmds.exe, and on my Win 10 22H2 build, its impact is shown as low. What you need to look for are tasks shown as high impact.

Correct. However as far as I can tell it is the only AMD utility that uses the AMDRyzenMasterDriver.sys driver as noted below; If your system is not experiencing any issues, I would just leave the driver file in Eset Quarantine.

Based on this detection, Eset is detecting the driver used by the AMD Ryzen Master utility program. You can download the latest version for it here: https://www.amd.com/en/technologies/ryzen-master . Also and important is Eset PUA detection is triggered on MalwareBytes AntiMalware MBAMService.exe execution of the AMD driver. If you are running MBAM in real-time mode concurrent with Eset, problems can occur with conflicts between two AV solutions running in real-time mode. You need to either uninstall MBAM or disable its real-time scanning feature.

The Eset firewall configured at default settings and rules only monitors inbound Internet traffic. All outbound Internet is allowed.