Marcos

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.

If disabling firewall makes a difference, enable logging of blocked communications in the IDS setup, reproduce the issue and post the recent firewall log records here.

Do you mean that egui.exe is not among running processes in the Task manager after the system starts?

Do you use default antispam settings? Does disabling either "Add text to email subject" or "Move messages to spam folder" make a difference?

When reporting an issue to ESET, an ESET SysInspector log is the most essential thing to get for analysis along with the information which of the protection modules needs to be disabled in order for the issue to stop manifesting. Feel free to send me the log attached to a personal message.

Apparently the file has been detected since update 8624. Almost none of the big AV vendors detect it to date.

It's not wise to restore malware just in order to get rid of this message. Please create a SysInspector log and send it to me attached to a personal message.

Detection was actually added in update 6862 on Feb 2, 2012 and it's been detected since then: c:\test\9c0b098ca31c83cd2baa703ea657ac9a8c852cb8.htm - JS/Kryptik.HK trojan

Document protection is disabled by default because registering it in the system (Windows registry) may have adverse impact on system performance due to a bug in Microsoft Office. I'll try to find out and let you know which registry value needs to be changed in safe mode to disable integration.

It's probably a legit action of the operating system, however, to date we have not heard of any issues caused by the block.

Without knowing details about the block it's impossible to tell if it was malicious or legit operations that were blocked. Posting a couple of records from the HIPS log might shed more light. Also note that logging of blocked operations should only be enabled for the time of debugging certain issue, otherwise the HIPS log may continue to grow up quickly until the disk space is exhausted.

I've tested submissions via the program's gui and it worked like a charm. Try restarting your computer. At any rate, the preferred way of submitting actually suspicious or infected files is by email due to a huge number of irrelevant stuff that people submit via the built-in form.

Please generate install logs as per the instructions here. When done, drop me a personal message with the logs attached for analysis.

Please continue as follows: - open the task manager and make sure no browser or email client process is running. - disable SSL scanning - click OK - enable SSL scanning - click OK Should you get an error, copy the information about installed modules from the about and paste it here. If you have the most current modules installed, we'll need a Process Monitor log from the point of enabling SSL scanning for analysis.

Currently scanning of https traffic tunneled via an http proxy server is not supported.

With firewall integration completely disabled and Epfw lightweight filter disabled, there's no change ESS could affect network communication in any way.

Maybe the file is too large to submit. I'd recommend following the instructions in this KB article for submitting files for analysis.

It's not clear what connection you meant between enabling SSL scanning and disabling real-time protection which are two completely different and independent things.

The issue should only occur on systems with old processors not supporting SSE2. It was fixed yesterday in Internet protection module 1076 for v5 and v6 users. V7 users will receive an updated module 1078B soon.

A dump should have been created when BSOD occurred. Check if the file c:\windows\memory.dmp exists and look at the date and time of creation to make sure it's from the last crash. If the file doesn't exist, look for minidumps in C:\Windows\Minidump. Compress the dump(s), upload them to a safe location and pm me the download link.

Please create an application dump of ekrn.exe by right-clicking it among running processes in the Task manager and selecting Create dump file. Then compress the dump, upload it to a safe location and PM me the download link. I'll pass it to the engineers for further analysis.

If you're able to reproduce the freeze, please configure Windows to generate complete memory dumps as per the instructions here and when a freeze occurs, use the appropriate key combination to create a memory dump. Of course, disabling startup scan tasks is not recommended as they serve as another protection layer and can detect potential new born malware in memory.