Marcos

It was not in the registry at all.

With HIPS disabled, malware can easily turn off your antivirus protection. Use it in default automatic mode which provides protection of crucial system and antivirus processes.

Please export an on-demand scanner log with all scanned files logged to a text file and post it here or attach it to a personal message for me.

The error message in question usually occurs if permissions to ESET's data files were modified. Perhaps we could arrange a remote session and fix it quickly.

I assume it's because Windows XP didn't support lightweight drivers yet. Jumbo frames are supported in the ESET lightweight filter as of v6.

Assuming the application is detected as a potentially unwanted application which is a fully optional detection and not a false positive, you can report it to ESET as per the instructions here. Having said that, we'll draw this topic to a close.

The bug is actually in the program itself and there's no chance to make a brand new beta version and test it thoroughly within 2 days. However, a hotfix (workaround) will be distributed to v7 users by means of a module update soon.

What about changing the firewall integration to "Only scan application protocols" or "Personal firewall is completely disabled" in the advanced setup?

The update issue is discussed here and we assume it will be solved shortly by temporarily disabling notifications about newer versions. The issue doesn't affect updating as is more of a visual glitch than a serious issue.

There's another forum dedicated to v7 beta and an ongoing dicussion about this issue. Having said that, we'll draw this topic to a close.

The aforementioned message appears if update files are modified by a proxy server. I'd suggest that you capture the network communication using Wireshark during an update (http should suffice), upload it to a safe location and send me the download link via pm.

Whenever you experience issues with BSOD, please provide the memory dump created during the crash and compressed in an archive to ESET for analysis. Feel free to drop me a personal message with a download link to speed up the analysis.

We've fixed it during a remote session. There was a shortcut in the startup folder attempting to load a non-existing dll.

Unfortunately, this is not possible. Creating general rules for files just by name while ignoring the path would be dangerous as the rules would be easily applied for malware, too, if the same file name was used by malware.

I reckon Leadbolt is detected as a potentially unwanted application (PUA) which is a fully optional detection.

Just to inform other users, the issue was confirmed to be caused by a bug in Windows Filtering Platform and other vendors have reported it to Microsoft as well.

Yeah, sorry, it's was early morning and I misread the post

It seems to be a weird tactics to make own software totally undocumented for 3rd party vendors and then offer own solutions. Note that ESET scans email for malware regardless of the email client use provided that it's received via POP3(S)/IMAP(S) protocols. The only module that won't work without a dedicated email client plug-in is antispam.

I'd suggest enabling logging of all files so that you can see what's actually being scanned.

If you have the full version of Malwarebytes installed, you should disable its real-time protection (especially if you have Windows XP).

Please supply the memory dump created during BSOD to ESET for analysis. It doesn't necessarily mean that ESET is the culprit; the BSOD could be caused by a bug in Windows Filtering Platform and not having the appropriate hotfixes installed. The memory dump should definitely shed more light.

Please confirm or deny my assumption that automatic updates are downloaded fine as long as an automatic update task is scheduled and the only issue is that Application update gets stuck.

The issue is being investigated. I was able to update v7 without an issue on Windows XP so far.

I've tried to reproduce the issue on Windows XP to no avail. After installation and a computer restart, the system started alright. If you can reproduce the issue with black screen, does it go away after renaming C:\Windows\System32\drivers\ehdrv.sys driver in safe mode?

We'd need to get a SysInspector log as well as a boot log created using Process Monitor for analysis. Maybe the fastest way to tackle this issue would be by contacting your local Customer care who would assist you with the issue.