itman

Someone else might be able to help you with the learning mode as it's not something I currently use, but your Son might be fine with just Automatic, which is the recommended setting for general users/non technical users.

It would be beneficial that Eset published a change log when modules are updated. If for no other reason than incorrect information is not conveyed in the forum ...............

It appears you have Dr. Web installed as your AV solution. Note that Dr. Web is a Russian based product and in fact is the only AV approved by the FSB for use in Russia. Read into this what you will. If I was in Ukraine, I certainly would not be using the product given the current situation there.
Unless you have an Eset product installed, this forum can't be of assistance since the moderators here need Eset logs in able to access the current situation on your PC. I advise you seek help in the various malware assistance forums. Below are two links to a few:
https://malwaretips.com/forums/windows-malware-removal-help-support.10/
https://www.bleepingcomputer.com/forums/f/22/virus-trojan-spyware-and-malware-removal-help/
I wish you the best over there. 

You are still missing what the issue is here.
Eset SSL/TLS protocol scanning initiated exploit processing for a vulnerability that never existed in Firefox. Again, Eset SSL/TLS scanning stays disabled on any browser that I use.

My last test in regards to the CVE-2020-0601 vulnerability is something I have not so far disclosed. That is Firefox was never affected by this vulnerability as highlighted in the below screen shot:
With Eset SSL/TLS protocol scanning disabled, this was verified per below screen shot:

So there you have it. A POC showing that Eset SSL/TLS protocol scanning actually makes you vulnerable to browser exploits!

I performed the same above CVE-2020-0601 test using Eset's Banking & Payment Protection mode. Again, note that this vulnerability will allow an attacker to perform browser network traffic man-in-the-middle interception activities.
Unfortunately, the result was the same:

@MMx , you previously posted that the main reason for Eset SSL/TLS protocol scanning was to detect browser exploits. Appears there is an issue in that regard.
First, note I am using the latest ver. of Firefox running on Win 10 21H2. Eset SSL/TLS protocol scanning for Firefox is enabled. I have also deployed your recommended reg. patch although I don't believe it's related to this issue.
For verification of Eset's ability to detect browser exploits, I used CVE-2020-0601; the infamous "Curveball" ECC certificate issue noted here: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2020-0601 .
It so happens there is a test web site that will deploy this exploit: https://www.ssllabs.com:10446/ which I used for testing. Upon attempted access to this web site, Firefox blocked the access noting there was a certificate issue. If I overrode that warning, the web site displayed a page noting I had been exploited. Further confirmation is shown via Win Audit-CVE log entry:

Not a beep from Eset exploit protection in any form.

Hum ........ I thought by now based on my recent comments, the issue with your problematic drive is not a "bug" in Eset.

At this point, it has been confirmed the issue it related to a specific drive.
If a full format of the drive doesn't resolve the Eset scan issue, below are your options:
1. Search for disk utility that performs multiple "wipe" passes against all sectors on the drive. 
Note that a Win full format only performs one pass against the drive writing binary zeros to all sectors. There have been persistent past malware that have been able to evade a single pass disk wipe.
A multiple pass wipe on a large drive can take days to complete.
2. Don't use the drive and destroy it - Recommended.
3. "Live with" the Eset scan issue.
 

Hum ........ I thought by now based on my recent comments, the issue with your problematic drive is not a "bug" in Eset.

At this point, it has been confirmed the issue it related to a specific drive.
If a full format of the drive doesn't resolve the Eset scan issue, below are your options:
1. Search for disk utility that performs multiple "wipe" passes against all sectors on the drive. 
Note that a Win full format only performs one pass against the drive writing binary zeros to all sectors. There have been persistent past malware that have been able to evade a single pass disk wipe.
A multiple pass wipe on a large drive can take days to complete.
2. Don't use the drive and destroy it - Recommended.
3. "Live with" the Eset scan issue.
 

One more additional comment here.
Try another USB thumb drive. If that drive can be scanned from the Eset removable media  popup scan option, this will confirm that the problem is with the original USB thumb drive.

My best guess at this point is the USB drive contains malware or crap-ware on it. When Eset encounters it, the software reacts by attempting to block the source thereby freezing the Eset GUI in the process.
You stated the drive is new. That really doesn't matter since USB drives can have malware or crap-ware inserted at the manufacturing source. The worst type is firmware based such as this recent example: https://www.zdnet.com/article/fbi-cybercriminals-are-mailing-out-usb-drives-that-will-install-ransomware/ .
I as a rule always reformat new USB thumb drives to NTFS format prior to using the drive. However, this won't help if the drive's firmware has been compromised.
Bottom line here is unless the drive was acquired from a known vetted trusted source, I would pitch the drive. And again, there have been past instances of drive tampering occurring at the manufacturing source.

https://answerstoall.com/language/why-is-an-ntfs-partition-more-secure-than-fat32/

When Eset detects malware, it will more associated files to its Quarantine area and delete the source files. In certain situations, it will just delete the source file.
Open Eset Quarantine via the GUI's Tools section and you should see entries for deleted malware from the flash drive.
Note: you should always closely exam the Eset scan log to ensure all detected malware has been removed.

I just scanned one of my USB thumb drives this way and had no issue with the Eset scan. As such, the issue isn't directly Eset related.
Open a command prompt windows. Type in:
chkdsk X:
where X = drive letter Win has assigned to your thumb drive.
This might take a while depending on the size of the drive. When chkdsk completes, it will notify you if any errors were encountered. If chkdsk finds errors, run it again as:
chkdsk X: /f
where X = drive letter Win has assigned to your thumb drive.
to correct any errors found.
Also if you did a quick drive reformat to NTFS:
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/format
no bad drive disk sector bypass activity will be performed. You have to perform a full drive reformat to NTFS.
There is a strong suspicion that there is a bad sector on that drive. When the Eset scan hits that sector is when it goes bonkers.

The Eset "right mouse button" option is a context scan. It is primarily designed to scan individual files. As such, no boot sector scanning is being performed.
Since it appears the Eset scan immediately hangs when a "scan" is selected from the Eset popup menu, this would be indicative of a boot sector issue; one possibility is malware; i.e. bootkit.. If this persists after a "full" reformat to NTFS is performed. I would pitch the drive.

When Eset detects malware, it will more associated files to its Quarantine area and delete the source files. In certain situations, it will just delete the source file.
Open Eset Quarantine via the GUI's Tools section and you should see entries for deleted malware from the flash drive.
Note: you should always closely exam the Eset scan log to ensure all detected malware has been removed.

My best guess at this point is the USB drive contains malware or crap-ware on it. When Eset encounters it, the software reacts by attempting to block the source thereby freezing the Eset GUI in the process.
You stated the drive is new. That really doesn't matter since USB drives can have malware or crap-ware inserted at the manufacturing source. The worst type is firmware based such as this recent example: https://www.zdnet.com/article/fbi-cybercriminals-are-mailing-out-usb-drives-that-will-install-ransomware/ .
I as a rule always reformat new USB thumb drives to NTFS format prior to using the drive. However, this won't help if the drive's firmware has been compromised.
Bottom line here is unless the drive was acquired from a known vetted trusted source, I would pitch the drive. And again, there have been past instances of drive tampering occurring at the manufacturing source.

I have verified that the above works for any problematic link posted in this thread; no more ekrn.exe memory spiking. At least as far as Firefox goes.  In regards to Win 10 21H2, I had to add the ChainEngine key under HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\ and the Config key under HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\ChainEngine\ key.
I have also for the time being re-enabled SSL/TLS protocol scanning for Firefox. Why? Mozilla just pushed ver. 97.0.2 to patch two vulnerabilities that were being exploited. The problem is it appears they busted part of Google Safe Browsing protection. It is no longer detecting on any tests from https://www.wicar.org/test-malware.html .

i will note that the Win firewall also doesn't support wildcard in its rules;
https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-firewall/best-practices-configuring
Like the Win firewall, the Eset firewall is a basic feature but effective firewall.
On the other hand. McAfee's firewall; at least for the endpoint versions, does allow wildcards: https://docs.mcafee.com/bundle/endpoint-security-10.6.0-firewall-product-guide-windows/page/GUID-6BBA2444-6126-49CD-A866-93CDC0CF7A66.html . BTW - McAfee won A-V Comparatives product of the year award: https://www.av-comparatives.org/tests/summary-report-2021/ .

"Don't hold your breath" on Eset supporting global wildcard capability. I have been waiting 7 years for it.🥺

That makes sense since the current version is 1437.

I believe this is the Cryptographic protocol support module or a component within that module.

OK. This means the issue will remain; at least for a while.
As far as I am concerned, it's N/A since I have disabled SSL/TLS protocol scanning for Firefox, the browser I use, and it will remain so. I will also note that since doing this, the large CRL download via Win crypto service no longer occurs at system startup time. Appears that Eset was triggering this if the CRL was previously used and it was refreshing the existing list.