Samoréen

Peter, As I already explained multiple times, the problem appears randomly so I'm unable to anticipate. I cannot reproduce at will. Thus, providing consistent logs along with a Process Monitor log as you requested in your message from June 12 is a problem. The problem didn't re-appear since about 8 days. It may re-appear at any time without any warning. I will be notified of the error by the ESET UI after a failed attempt. So any log collecting procedure implying a before/after backup is a no go. Otherwise, I can provide any file you want.

Latest news : - Clearing the Update Cache didn't help. - MalwareBytes is not the culprit.

Yes. This error occurred only once until now.

Hi, I recently got this notification after (or during) an update. No other error was reported. Is it possible to get this kind of message after the Update Cache has been cleared ? Thanks.

Thanks for your time, itman. I'll continue feeding this thread with the information I'll be able to collect.

My intent was to protect these ports via the Windows Firewall instead of letting the ISP's router doing something that is not documented. If these ports are not used when ESET updates itself (I had a doubt because of the ERA), there's no reason to leave them without any monitoring.

I just discovered that my ISP box was by default "protecting" ports 135, 137, 138, 139 and 445 (I don't know exactly what it does, there's no documentation about this). Most of these ports are used by the ESET Remote Administrator. I don't know whether ERA is used for the pico updates... I have disabled this "protection".

Hi itman, Back to the above... So, this means that even if the update file is not corrupted (tampered with), the update will fail anyway with the same error message if something prevents the update compiler from communicating with the ESET server during the update process when trying to check the hash code ? That "something" could be a setting (a filter) enabled in the firewall (I'm not using the Windows firewall but the one embedded in my ISP's modem) ? Do you know which ports are involved in this process ?

Yes, I did. I'm currently trying again.

Anyway, thanks for your help. I might be the only one with this issue but I rather believe that many people just don't care or even look at the event log. They click on the Check for updates button until everything is OK. My system has nothing fancy. It's not a development system and I only have image processing, office applications and various utilities. There are only 2 programs that could interfere : MalwareBytes Premium (with real-time Protection enabled - I use it as a complement to ESET) and Acronis True Image Home which now has an Active Protection feature against ransomware (which I turned off). I think I have already asked about possible incompatibilities and I'm not aware of any.

Hi, This morning ESET displayed a strange empty message. A corresponding entry was added to the event log :

The Clear Update Cache option is OK this morning. The proxy mode was already set to "Do not use proxy server".

I'm aware of this. I'm a former developer/system engineer and I coded such things in the past. I can admit file corruption during transfer from the ESET servers to my system but corruption affecting only ESET files (and apparently only pico updates) is very unlikely. I don't have any problem with other updates and downloads and many of them are sensitive to file corruption. For example, I'm using a lot of Microsoft .Net applications and all units are checked again corruption before being installed/updated. Never had a single problem. All my disks have been checked multiple times and no problem has been reported. I also run memory tests : no problem reported either. Maybe my system configuration has something that ESET NOD32 doesn't like but I think it's now useless to consider any system failure on my side.

I finally could upgrade to version 11.2.49.0.

The Clear Update Cache option is grayed out. New bunch of failures tonight...

Itman, are you telling me that not all updates are "pico" updates ? This could explain why not all updates fail. I'll see if I can find some document listing the required certificates for Eset Nod32.

By the way, ESET NOD32 still didn't auto-update to version 11.2.49.0 (I'm in France) ? Any possible relationship ?

Hi Itman, No proxy used in this system, no suspect activity to ro from 127.0.0.x. I used various tools in order to detect transparent proxies : no proxy detected. So, a malware undetected by ESET NOD32 and that would only affect ESET updates from time to time and not any other network activity for any other software ? IPV6 is enabled on my system. Could this be a problem ?

Hi, After moving the TEMP folders and the Windows pagination file back to C : and after a quiet period (away from my desk for a while), the problem re-appeared today. After the update failure, a first attempt to update manually also failed, as usual. And as usual again, the second manual attempt succeeded. Nothing changed. the pagination file after So it's neither a hardware problem with the SSD where my temporary files were previously stored (this disk is no longer involved in the update process) nor a problem with the location of the TEMP folders. Back to start...

My TEMP/TMP environment variables now point to C: . Let's see if this changes anything...

OK. This SSD is an OCZ one, so I downloaded the corresponding utility which reports that everything is OK. No block removed, spare blocks still at 100% available, health is at 100%, temperature is low, etc. After a full scan, HD Tune has the same opinion about this disk. No error reported, scan window green from first to last block.

Yes. But the problem can disappear during 2 or 3 days (or more) and then show up again.

No. I have one application where this path is hard-coded and that re-creates it when it is deleted.

Hi, No. I have 2 SSDs. C: is a SSD with a single partition. D: is a HDD and E: is an older SSD dedicated to temporary folders and files and to scratch files for my photo applications. It haf only one partition but it has 3 partitions : one for the pagination file, one for the temporary files and folders and one for the scratch files. I made this to make sure that the temporary files and the pagination file were moved to another physical location. I'll try to add a small pagination file to C: but moving the temporary files and folders back to C: is a problem because the disk will not be big enough, I'm afraid. I'll try.

The archive file is now ready for download.