itman

Running these four commands from elevated command prompt window did the trick for me:
cd c:\windows\system32 lodctr /R cd c:\windows\sysWOW64 lodctr /R

Good find!

Good find!

Well I was curious I went to update the eset when the modules were just installed look what happened to my GPU all disappeared.

I found that it was because of the update of the eset modules.

The Smart Optimization option exists whether ThreatSense settings do; Real-time protection, Malware scans, Web Access Protection, etc.. I really can't see how this setting is related to your WMI problems.

The Smart Optimization option exists whether ThreatSense settings do; Real-time protection, Malware scans, Web Access Protection, etc.. I really can't see how this setting is related to your WMI problems.

Rebuild the performance counters: 
https://docs.microsoft.com/en-us/troubleshoot/windows-server/performance/manually-rebuild-performance-counters
Create a new data collector set by running performance monitor. The process is similar to the following guide, just select all the GPU related performance counters.
https://help.tableau.com/current/server/en-us/perf_collect_perfmon.htm
I don't believe this problem has anything to do with ESET, as the problem is affecting a far wider audience. Doing the above procedure worked for me.

Reviewing my Eset Event log, the answer to why you did not receive a LiveGuard safe verdict is as follows.
It appears Eset designed LiveGuard processing to run silently in the background. That is when a file is submitted to LiveGuard and the file is not determined to be malicious, you will receive no verdict Event log entry. The only time you will receive a LiveGuard safe verdict Event log entry is when you try to access a currently locked file prior to LiveGuard completing its cloud processing.

Reviewing my Eset Event log, the answer to why you did not receive a LiveGuard safe verdict is as follows.
It appears Eset designed LiveGuard processing to run silently in the background. That is when a file is submitted to LiveGuard and the file is not determined to be malicious, you will receive no verdict Event log entry. The only time you will receive a LiveGuard safe verdict Event log entry is when you try to access a currently locked file prior to LiveGuard completing its cloud processing.

Reproduction is "highly doubtful." As I posted when I retested, the submission to LiveGuard was immediately after malware detection.
This instance shows behavior akin being stuck in the LiveGrid submission queue. Then later, Eset recognized an unsent submission was pending and then sent it.

I had one that took 35 mins. .................

I had one that took 35 mins. .................

Eset will unblock a file after the "Maximum wait time for analysis result expires." The default value is 5 mins..
As far as if there is a risk associated with this, theoretically the answer is yes. To exploit this however would require an attacker to perform system modifications prior to the executable/script being dropped. One example would be creating a scheduled task to run every 6 mins. or so that in turn, runs the executable/script.

Err .......... yes, I know that.
The issue is why it took 4 hours to do so. I have never seen this behavior previously from Eset.
BTW - I just repeated the test and the download was immediately sent to LiveGrid after detection.

I am running Win 10 Pro x(64) 21H2 and FireFox 99.0.1 and having no issues with Eset B&PP. I also applied latest Win preview updates yesterday. Also my ESSP ver. is 15.1.12
This issue might be related to Firefox ESR.

I am running Win 10 Pro x(64) 21H2 and FireFox 99.0.1 and having no issues with Eset B&PP. I also applied latest Win preview updates yesterday. Also my ESSP ver. is 15.1.12
This issue might be related to Firefox ESR.

Notice the remote IPv6 address is the same as previously posted that was detected performing coinmining activity.
Also, it is not normal Win system behavior to see PowerShell running as a stand-alone task for an extended period of time.

In regard to the prior PowerShell code posted:

Attacker dropped the coinminer code file previously in highlighted Windows log file directory. Attacker is creating App_V process remotely using Sync-AppPublishingServer.

I am running Win 10 Pro x(64) 21H2 and FireFox 99.0.1 and having no issues with Eset B&PP. I also applied latest Win preview updates yesterday. Also my ESSP ver. is 15.1.12
This issue might be related to Firefox ESR.

It is also noteworthy to review how ESSP performed in AVLab's recent Banking and Payment Protection test: https://avlab.pl/en/overview-of-techniques-and-attacks-in-windows-11/ .  Some work needed by Eset in this area.

Glad to see that Eset has joined AVLab test series. Since they are not an AMTSO member, they are not constrained by its testing methodology. As such, they can be more "creative" in testing of malware.
There does appear to be some confusion as to what the various test levels; L1 - L3 mean. So let's review those:
https://avlab.pl/en/modern-protection-without-signatures-comparison-test-on-real-threats/
To sum up the above, Level 3 ranking means malware detection based on behavior methods only. Also, behavior based detection implies that some system modification activities may have occurred prior to detection. Level 1 detection obviously offers the most system protection. However, almost all in the security industry will state that given the current and evolving state of malware development, it is an unrealistic malware detection standard. Rather, Level 3 malware behavior detection today is mandatory in conjunction with Level 1 and 2 methods.
As far as LiveGuard being a contributing factor to ESSP 100% Level 1 scoring, I see no evidence of this in the current test published details. One of many ways to determine LiveGuard effectiveness would be to have AVLab perform a controlled test of both EIS and ESSP. The test malware samples would include a large number of "true" 0-day samples. That is malware in-the-wild not currently being detected by any AV solution; not 0-day malware seen in the last 30 days. This test would also establish Eset's effectiveness using L3 behavior methods.

It is also noteworthy to review how ESSP performed in AVLab's recent Banking and Payment Protection test: https://avlab.pl/en/overview-of-techniques-and-attacks-in-windows-11/ .  Some work needed by Eset in this area.

Glad to see that Eset has joined AVLab test series. Since they are not an AMTSO member, they are not constrained by its testing methodology. As such, they can be more "creative" in testing of malware.
There does appear to be some confusion as to what the various test levels; L1 - L3 mean. So let's review those:
https://avlab.pl/en/modern-protection-without-signatures-comparison-test-on-real-threats/
To sum up the above, Level 3 ranking means malware detection based on behavior methods only. Also, behavior based detection implies that some system modification activities may have occurred prior to detection. Level 1 detection obviously offers the most system protection. However, almost all in the security industry will state that given the current and evolving state of malware development, it is an unrealistic malware detection standard. Rather, Level 3 malware behavior detection today is mandatory in conjunction with Level 1 and 2 methods.
As far as LiveGuard being a contributing factor to ESSP 100% Level 1 scoring, I see no evidence of this in the current test published details. One of many ways to determine LiveGuard effectiveness would be to have AVLab perform a controlled test of both EIS and ESSP. The test malware samples would include a large number of "true" 0-day samples. That is malware in-the-wild not currently being detected by any AV solution; not 0-day malware seen in the last 30 days. This test would also establish Eset's effectiveness using L3 behavior methods.

More likely something from one of the numerous JavaScript's running there. Quttera downloaded approx. 80 - 90 files that it analyzed.

I am now 100% convinced that LiveGuard processing of suspicious unknown scripts is non-existent.
This morning I found a web site that was showing code examples for two .vbs scripts that could be used maliciously. Note that the code was shown in clear text and therefore couldn't be directly executed from web site access. LiveGuard upload was triggered by the code in one of the scripts:
Time;Hash;File;Size;Category;Reason;Sent to;User
4/11/2022 9:16:36 AM;2AC6C154FA1000AE10D85D4892B79D13763DAB8A;https://gist.github.com/Alekseyyy/6e3569c5b3dfa5eeee60f9f48af58579.js?file=medium.2021.infosecw.vbscript_fun.reboot.vbs;30092;Script;Automatic;ESET LiveGuard;xxxxxxx
Time;Component;Event;User
4/11/2022 9:16:36 AM;ESET Kernel;File '6e3569c5b3dfa5eeee60f9f48af58579.js?file=medium.2021.infosecw.vbscript_fun.reboot.vbs' was sent to ESET Virus Lab for analysis.;SYSTEM
This is "classic" LiveGrid processing behavior I have seen many times in the past.
First, Eset detection is not "smart" enough to realize that the web page code was shown in clear text and can't be directly executed. Next, Eset's detection of this script code was by signature which I will get to later. The upload to the Eset clould was for notification that a web site was found with malicious code.
Why do I know that this code was detected by signature? I copied the code and pasted it in Notepad. When I tried to save  the code as a .vbs file:
Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
4/11/2022 9:23:26 AM;Real-time file system protection;file;C:\Users\xxxxxx\Downloads\edtdtestfile\Test.vbs;VBS/Agent.DN trojan;cleaned by deleting;xxxxx;Event occurred on a new file created by the application: C:\Windows\System32\notepad.exe (5B80BBB07B1A84384E61FB3F9366CAD97904EBEA).;2482C486EB9F55C9DD98FEFD55B200B169A75DAA; 4/11/2022 9:23:23 AM
As far as I am concerned, LiveGuard, as currently designed, will only protect you from unknown, to Eset, suspicious binaries. That is stand-alone .exe's and the like or, the same embedded in another file that can be identified by Eset as such. Note that the procedure Eset recommends for testing LiveGuard functionality is create an e-mail and attach the created test .exe to it. This is as bogus a test that I have seen in a while. Note that most if not all third party e-mail providers will immediately delete any .exe attachments upon receipt of the e-mail by the provider.