100

wlm.exe wlmail.exe

Hm, thanks for the quick reply. It's strange that I've only had the problem since the on-demand scan.

Hello, I have had v14.2.10 for months/weeks, then .19, .23 and now .24 and no problems with Windows Live Mail on Windows 7 x64. Only since today it occurs after a system reboot. Previously I had done an on-demand scan ("scan only, no action"). Selected were only the drive for backup files (not c:\), memory, boot sectors, WMI database and registry. Then did DBI not work at all before because of inplace updates and was only enabled by the on-demand scan? The exception of wlm.exe in HIPS DBI works as a workaround, but a fix would of course be better. Can we still hope for it, Marcos? That would be really nice!

Suggestion for the Eset anti-spam filter: Mark mails as spam, based on own rules for individual X headers. Reason: My e-mail provider has decided no longer to add a note to the subject of e-mails classified as spam or to change the subject in any other way. Instead, spam mails are moved to a folder on the server that cannot be retrieved via POP3 (IMAP is not an alternative). However, I have created a rule on the server that moves all mails to the inbox that are not sorted out by other filters. Rules for X headers are not possible. Now, of course, I get the spam mails in my inbox, which are now only marked as spam in the mail header via "X-Spam-Flag: YES" and are not recognized as spam by Eset even with the extended antispam database.

The cleaner version is now 1200 with the regular updates.

Eset has now informed me that version 12.2.29 is ready to install. The folder C:\Program Files\ESET\ESET Security\Updates now contains both upgrade files (118 upcu files for the 12.2.28 and 118 upcu files for the 12.2.29 and the xml file). However, the xml file only refers to the new upcu files for the 12.2.29. The others will probably simply be deleted during the installation. :-)

Thank yo very much, Marcos. This is the behavior of the program I expected before.

The calculations are expected to run for at least 6 weeks. Hopefully this will go well. 😟 In the future I will deactivate program updates before. Edit: What will happen if I deactivate the program updates now and then switch back to the regular update channel?

So a reboot in a few weeks will definitely first install the 12.2.28.0 which is waiting for a reboot?

Yes, I can't restart for a few weeks but Eset can still be used during this time and won't restart the computer by itself. It's just a general question if Eset revokes an upgrade due to problems and releases a new upgrade. I saw a message from you in the forum before, that 12.2.28 has been released. But since someone reported problems with 12.2.28, your post has disappeared.

Because of this: I'm on the test update channel. The upgrade files are in this folder: C:\Program Files\ESET\ESET Security\Updates For versions higher than 12.2.28, the upgrade mechanism could simply replace these files as long as no reboot to install 12.2.28 has been done. Would it not be possible to boot into Windows SafeMode and delete the folder "Update" to prevent the upgrade?

I didn't click anything. The upgrade was downloaded in the background. But it certainly doesn't make any difference. If there was a newer version before the reboot (e.g. 12.2.30), would the upgrade files be replaced from 12.2.28 to 12.2.30 before the reboot so that 12.2.28 would be skipped?

Eset reports that it needs a system restart for the update to 12.2.28. Is it possible to cancel the upgrade? I can't restart the system for the next weeks anyway and maybe there will be a corrected version.

Tested today: Regular updates are still at 1195. Does anyone with regular updates have a version above 1195? Edit (09/21/2019): The cleaner version is officially still 1195 with the regular updates.

Yes: https://help.eset.com/eis/12/en-US/idh_page_scheduler.html https://help.eset.com/eav/12/en-US/idh_page_scheduler.html

Eset scans the start files after every successful update.

See this posting from me: I didn't have any problems with 1199. The problem occurred with switching back to 1195 and unfortunately remains now after I am back to 1199 (without restarting the operating system). 1199 only protects against new locks but doesn't unlock existing ones.

I know, and after a few minutes I had changed back to the test updates with cleaner module 1199, but the registry keys still remain locked.

I thought that now with the regular updates at least the cleaner module 1197 would be available and so I changed back to it. But it's still on 1195! Now I unfortunately have 3 applications with the locked registry keys and I probably can't restart the system for the next 2 month because big calculations are running which will probably take so long. :-| Edit: I have created a batch file that should delete all folders and their files (except the RegHive files) of these sandboxes with a double click. @echo off FOR /D /R "C:\Sandbox\username\sandboxname1" %%x IN (*) DO rd "%%x" /s /q FOR /D /R "C:\Sandbox\username\sandboxname2" %%x IN (*) DO rd "%%x" /s /q FOR /D /R "C:\Sandbox\username\sandboxname3" %%x IN (*) DO rd "%%x" /s /q

Hm, I cannot confirm this under Windows 7 (x64) and EIS 12.2.23 with the cleaner module 1199.

Cleaner module 1199 now. :-)

Are the test updates still on wave 3? I have now also switched to the test updates.

Thank you very much, Marcos.

The same here. There's another cosmetic problem. The "Advanced Machine Learning Module" is not displayed under Modules. Only after switching to beta updates is it displayed. After that it will also be displayed if you have changed back to normal updates. The same after a second unintallation, reinstallation and several restarts.

Eset has by far the best support of all antivirus software vendors. They are the only ones who take their customers seriously and listen to them!