itman

Going through the multiple Wi-Fi connection problems in the forum, the only solution to the issue posted was; https://forum.eset.com/topic/32033-wifi-problems-with-eset-smart-security-premium/?do=findComment&comment=152765

I ran tracert edf.eset.com and the final connection was to 52.160.70.199. Next, I ran DNSChecker for edf.eset.com and all DNS resolutions world-wide were to IP address 52.160.70.199; As such, whatever DNS resolution issues you are having are on your end and nothing to do with Eset.

Refer to this article: https://support.eset.com/en/kb7554-unprotected-wifi-notification

Per Robtex, edf.eset.com resolves to the following IP addresses;

FYI: https://github.com/MicrosoftDocs/windows-driver-docs/blob/staging/windows-driver-docs-pr/debugger/bug-check-0xd1--driver-irql-not-less-or-equal.md As the article states, Driver Verifier utility analyzing epfw.sys might be able to shed additional info on what is going on here. In this article: https://answers.microsoft.com/en-us/windows/forum/all/bsod-kernel-mode-driver-attempted-to-access/dc240524-45d9-4219-bd03-184b2725953c , an update of PC manufacturer motherboard chipset drivers fixed the problem.

Some further info on why encrypted VHD recovery might be "an effort in futility." From a May, 2023 Secure Data forum posting; https://forum.eset.com/topic/36474-eset-encrypted-drive-error-authenticating-or-mounting-encrypted-virtual-drive-error-code-0xc00f000c/?do=findComment&comment=167214 I checked for this same folder on my device and it does exist. So it appears it is also created when a VHD drive is created. Since the OP installed a new boot SSD and reinstalled Windows, this original Secure Data keystore folder no longer exists. Therefore even if it was somehow possible to associated the old VHD .eed file with the current Eset Secure Data installation, it would be impossible to decrypt those files. If there was a full backup of the old boot SSD taken prior to drive failure, it might be possible to restore the keystore folder from that. Finally, Deslock+ documentation clearly states the this "keystore" folder needs to be backup to external media for just this event occurance; something Eset documentation is silent on.

Your hosts file is fine. At this point, I have no clue what G-Data was detecting on the VT scan. Your TCPView screenshot shows a number of processes using 127.0.0.1 among them are Discord and Teamview. Both are known to contain vulnerabilities in other than most current versions. You could start by verifying latest versions are installed.

Not so according to Eset publication;

Have no clue what you are referring to. Post a screen shot of what is shown in your Win10/11 hosts file.

To get to the bottom of this, here's what I did pain in the butt it is. I activated Secure Data and created a virtual encrypted drive on a non-boot HDD I have installed. Verified I could access it via password and that the drive loaded into Win Explorer. I then exported my existing Eset settings. I then uninstalled ESSP. While the uninstaller was running, I saw Secure Data roll by. Oh-oh. Sure enough, when ESSP was uninstalled, all traces of the previously created VHD were wiped from the HDD it was previously installed on. I will continue, but this in itself is enough to state that any VHD created by Secure Data option is 100% dependent upon the current Eset installation. I then reinstalled ESSP and imported my previously exported settings. Secure Data was still showing as never setup after settings import completed. "I again say to thee", yes the OP new system shows that an existing old installation VHD exists on his non-boot SDD. But as far as his current ESSP installation on the new system is concerned, this VHD doesn't exist. It is in effect an "orphaned" VHD. Unless Eset developers can come up with a way to associated this old VHD with the current ESSP installation, it will remain inaccessible.

You're talking "apples vs. oranges" here. SSL/TLS protocol Application scan rules relate to Eset Web Access protection and have nothing to do with the Eset firewall which is related to Eset Network protection. Eset has posted previously in the forum that users are not to modify SSL/TLS protocol Application scan rules. These are maintained internally by Eset.

Based on your TCPView screen shot, you are using both Outlook and Thunderbird e-mail clients. Eset e-mail anti-spam processing only works with Outlook; not with Thunderbird. As far as the VT detection, it's for localhost port 8080. Eset default firewall rules allow all traffic within computer; i.e. 127.x.x.x.. Check your Windows hosts file to see if has been modified.

Appears OP is referring to the currently active NOD32 license. Multiple past forum postings all refer to license purchases in U.S. dollars are forwarded to Eset N.A. for payment processing. As such, issues with the purchases must be resolved by Eset N.A..

Are you an Eset partner; i.e. value added retailer (VAR), associated with Eset Croatia LLC? If so, it appears they are terminating their business relationship with you.

Eset North America handles all Eset license purchases made using U.S. dollars. You can contact them here: https://www.eset.com/us/about/contact/ about this matter.

I believe you are referring to this registry key, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. Malware will store there malware payload in this key for persistence purposes ensuring the malware always runs at system startup time. The point to note is the malware still exists on your system regardless if present in this registry key.

Pondering more, there is another possibility here and your not going to like it. First, a clarification of what the .eed file is. It appears to be the Secure Data executable file. The file is used to access Eset encrypted data on a created VHD or removable drive. When your old device crashed, so did the VHD and any data on it. Unless you backed up that data to external media prior to the crash, I am afraid it is lost. Or if your very lucky, the data still physically exist on the SDD. But I see nothing in the Eset Secure Data documentation this is the case. Also if the Eset encrypted files from the old system still exist on the SDD, there is no documented procedure on how to link those files to the new Eset VHD created on the new system. Now if you instead had created Secure Data removable media drive, Eset would have created the data on that drive permanently. This is why it can be accessed again when Eset is reinstalled either on the existing device or a new device.

Let's "take it from the top" again starting with the very first statement in Eset Secure Data FAQ; https://support.eset.com/en/kb6266-eset-secure-data-faq#deleteVD Next is when reviewing Eset product on-line help in regards to Secure Data processing are the repeated references to removable drives, My take here is Eset never fully designed Secure Data to be deployed on internal HDDs. It does so by creation of a virtual hard drive. My assumption is VHD's are directly linked to the device OS where created. Installing the SSD on a new device/OS no longer has an Eset VHD relationship. Did you create a new Secure Data VHD on the new device specifying this SSD as the source? Also, this might not work in that all that is created is a new empty .eed encrypted folder for the new VHD on the new device I assume. Also if you exported Eset settings prior to the old system crash that contained Secure Data settings and imported those settings after ESSP installation on the new system, the VHD might have been auto created w/o issue. But again, I am not sure this would have worked. In any case, I believe you need to create a support request for this one. -EDIT- Pondering a bit more. The problem here is a way to replace the newly created empty .eed folder associated with the new Secure Data VHD on the new device with the old existing .eed folder created on your old device. This I have no clue on how to do or even if this is possible.

ESSP Secure Data option is not a full encryption solution as exists in Eset commercial products. It is set up primarily to encrypt removable drives. My guess here is Eset stores the decryption password somewhere on the removable drive. "My gut is telling me" Eset never anticipated your scenario; using an Eset encrypted non-boot internal HDD in another Windows system. Another possibility here is the SSD is either damaged or malfunctioning in some way. Did you run chkdsk on that drive? Better yet, the drive manufacturer test tool? You mentioned a catastrophic hardware failure with your old computer. It is within the realm of possibilities that could have impacted this SDD.

My take on this is if Eset can recognize the encrypted drive per below; https://help.eset.com/essp/16.1/en-US/enc_intro.html?enc_encrypted_virtual_drive.html you're "good to go." Recognition would be if Eset prompts for the password. The "gotcha" is since the password was created on another device, will Eset recognize this password on the new device?

Looks like this KB needs to be updated to reflect ver. 16 changes. Refer to the below screen shot. Enter Firewalla Gold gateway local subnet IP address as the remote IP address and that should work;

You have multiple JavaScript malware on this web site per Sucuri analysis: https://sitecheck.sucuri.net/results/https/www.pigier-issec-toulouse.fr/* . If you can't eliminate the malware, a web malware cleaning entity such as Sucuri will clean the malware for a fee.

Contact Imunify since they are supposed to be protecting your web server.

First, try to access the network share on the device with Eset installed. Next, open the Eset GUI on that device and access Network Protection section. Now refer to the below screen shot; The Recently blocked apps or devices count should be a non-zero count. Mouse click on Resolve blocked communication. Select "Unblock" on all inbound port 445 blocked traffic displayed. Prior to doing this, verify the remote IP addresses shown are associated with your local network subnet. Eset will create a permissive firewall rule/s to allow this inbound port 445 network traffic. Once it has been established inbound port 445 network traffic is no longer blocked, you can modify the Eset generated firewall rule specifying your local subnet IP address range in the firewall rule remote address field if it does not previously exist there. Finally if Eset is also installed on the device you are try to access this network share from, you will probably have to perform the same above procedure on that device. A simpler solution is to change your Eset established Network connection profile to "Private" on all devices with Eset installed. This will allow file and printer sharing by default for the local subnet on all those devices. Of note is this will also allow other network traffic between those devices such as uPnP, etc.

There are many web site scanners available. Most are not free.