Samoréen

Peter, Despite the massive reorganization and re-partitioning of my E: disk, the problem occurred again this afternoon. This time, I could collect all the necessary information. Here is how I proceeded... These updates always fail the same way : 1. I'm notified of the error. 2. The first manual update attempt always fails. 3. The second manual update attempt always succeeds. So I collected the requested files before the first attempt, ran it while Process Monitor was running, and then collected again the requested folders and logs after that first manual attempt failed. Then I ran the manual update again (which, as expected, succeeded) and collected again everything. The result is an enormous ZIP file (1,2 GB) that is currently uploading to Dropbox : https://www.dropbox.com/s/q7813a2jh0q5uj3/EAVLogs.zip?dl=0 The file shouldn't be ready for download before this night (19:30-20:30 french time). I'll notify you if it is uploaded faster than expected. Now a remark : if the problem is actually due to a random failure of my E: disk, I can't understand why it always occurs the same way, as described above. This is too repetitive to be random. From the beginning, the first manual attempt always failed and the second one always succeeded (at least they were reported as such). As you can see from the attached screen capture, the Advanced logging switch generated additional messages. It seems that after the second manual attempt (which I considered as successful) nothing was actually installed : retval = 00005007 [NOT NEED] . Not needed ? So why try to update ? Or was the apparently failed first update attempt actually successful ? I think that there is more about this issue than a mere disk failure (which may actually exist, of course).

Hi itman, You're correct about the permission settings. But if a user is able to manage the location of the TEMP folder, he should also be able to manage the access permissions accordingly. I know that some applications, instead of using the Windows API in order to retrieve this kind of information, are using hard-coded strings. It's just nonsense . Such applications are written by incompetent developers and should not be used because if these programmers are able to do that, they are likely to make similar mistakes in other programming areas. As for the OS, I'm not aware of any problem with TEMP folders redirection. I'm doing this since years and never noticed any issue. Trying to move the Users\xxxxxx folders to a non-system partition is another problem, though, and I agree that this should be avoided.

OK. I have checked the disk and no problem was reported. I have reorganized this SSD so that the whole TEMP folder was moved to another location (partition). That partition is now dedicated to the TEMP folder. Other folders have been left in the E: disk and the pagination file (which was in the same partition as the TEMP folder) also has now its own partition. We'll see if this changes something. I'll keep you informed.

Thanks Peter, Strange. I'll check again this disk and try to relocate the TEMP/TMP folder. It's a NTFS formatted SSD which doesn't have exFAT, though. I'll let you know if I detect some problem. Thanks again.

Thanks Phil, I'm feeling less alone. I had the problem again today and as usual, the update succeeded after the second manual attempt. Unfortunately, I was just back to my office and Process monitor was not active.

No new error since 06-09-2018 18:24. I'll be on the road for a while. I guess I'll get a lot of updates when I'm back.

New Detection Engine update at 18:50. No error.

I checked all my disks more deeply and they are all healthy, especially my system disk (C: - SSD) and E: (disk where all temp and scratch files are stored - also a [recycled] SSD). Also, it's hard to believe that a hardware or network failure would only affect ESET files. Never had problems when downloading Windows updates (which are also signed), software updates from Adobe and other software vendors which are signed as well and lots of big image files which are not signed but where any corruption either in the header or in the image part can be immediately spotted. Not talking about other updates like those of Malwarebytes and the regular checking made by my backup software (Acronis). When I say signed, I mean either actually signed or submitted to a CRC check or similar. Also, I'm running a lot a Microsoft .Net software using signed units that are regularly updated. Also, I had a look at the statistics of my ISP's router and the error ratio is extremely low and when errors occur, they are of the auto-corrected kind. They are fixed before my PC sees them. OK. Still waiting for the next update. The last one was at 14:34 and it didn't fail.

Peter, I cannot reproduce at will since this problem randomly occurs when the Detection Engine is updated. How could I know when these updates occur and which one will fail ? This means that I should leave Advanced logging enabled all the time. OK but as I already mentioned in one of my messages in answer to the same recommendation made by Marcos, Please note that Advanced logging disabled itself multiple times after I enabled it. It also disabled itself just after the last module update. Which process ? Should I capture all events for all processes ? For the reasons explained above, this will generate a huge log until the problem occurs again.

Everything OK.

Interesting comments. So I should now be looking for intermittent and undetected problems on the network OR on my system disk (I just checked it, no apparent problem). After all, if your assumptions are correct, this could also be a file corruption occurring when the source files are written, not necessarily during the download. I guess that these assembly source files are not maintained on my system ? Otherwise I could read them and at least be able to determine if they are actually corrupted. Re : module updates The Event log reads as follows : update module - Compiler error... Actually, if I understand well, we are not talking about "updating modules" but about the "module that is in charge of running updates". It's always that particular code that fails. The updated module appears to be the "Detection Engine" module. If I look at the component list, I can see that module updates are not that frequent. The "Rapid Response" module was updated today, the "Network Protection" module was updated on 06-08-2018 and other modules were updated in May. Otherwise, the updates occurring almost daily are the Detection Engine updates. When I re-launch a failed update manually, it's always a Detection Engine update that is installed and listed in the Event log. So only that module would be corrupted ? By the way, this problem is not related to 11.1.54. I just discovered that it also occurred with 11.1.42 and 11.0.159.9, although not that frequently.

OK, thanks. But this assumes that I'm able to anticipate when an update will take place. Otherwise, I'll have to keep Whireshark active all the time. This will generate huge logs, I guess.

Correct. I forgot these. Not an option. My system contains sensitive data. However, I'm a former software/system engineer, so I can certainly understand directions from Eset in order to detect any anomaly. Just waiting for them. As mentioned above, I provided all the requested information one month ago. I certainly value your comments but : 1. I'm able to monitor what's happening on my network and I couldn't find anything unusual or suspect. 2. My router has been fully reinitialized recently. I checked the settings. Nothing wrong. There's something I can check, though. I have the possibility to bypass my ISP's router and be connected to Internet via a 4G device. I can live with such a connection one or two days. Let's see if that changes anything... 3. If some malware is at work somewhere on my system, why should it target only ESET Nod32 ? No other problem during the past month. 4. Why does the update always eventually succeed when I use the Check for updates button ? If the updated modules are tampered with only from time to time and are always eventually installed, what's the actual purpose of this malware ? Too lazy to be effective . 5. Why did this problem only appear just after version 11.1.54 was installed ? 6 Why do I get compiler errors anyway even if there's no digital signature problem ?

If this really happened, then both ESET Nod32 and Malwarebytes missed it. So should I drop these products and look for something more effective ? Moreover, the invalid certificate warning occurred only once (could be a mere transmission error). All other update failures since the problem appeared were compiler errors.

Thanks. My router is specific to my ISP. It doesn't belong to the affected routers.

I can't remember how many times I have uninstalled and re-installed ESET Nod32 when having problems because this is what I had been told to do. This never helped. Now, if a product has a repeating bug, I prefer that the bug be fixed instead of masking it by restarting from scratch. I have sent all the requested logs and information one month ago. Waiting for the feedback...

I flushed the DNS cache and just a few minute ago a new update took place. Same error again. I clicked on "Check for updates...", same error. I clicked again, update succedeed.

And, as a reminder, I never had such problems before version 11.1.54 was installed.

I can test this but again, this would not explain what's happening with the "Check for updates..." button. When an update failure occurs, if I click once on this button, the update fails again. If I click a second time or a third time, the update succeeds. I don't see how the DNS Server could intervene in this process. The DNS Server is just here to translate a domain name into an IP address. Unless I have missed something, the DNS Server doesn't determine the route. Maybe I should update my knowledge about TCP/IP.

Hi itman, I'm using the firewall of my DSL modem. If this is the cause of the problem, updates should fail all the time. Which is not the case.

Hi, Strange. I have no other corruption problem when downloading files from other sources. And I'm daily downloading a lot of files that are potentially sensitive to corruption. Why should especially the Eset files be corrupted on their way to my PC ?

Problem going on...

The problem occurred again today. I clicked on Check for updates, and the update failed again. I clicked a second time on Check for updates and the update succeeded. Immediately after that, the event log reported a successful Detection Engine update. So, I guess that these module updates are actually Detection Engine updates. If I'm correct, this means that if I do not update manually, my system is not protected against the latest threats normally detected by the Detection Engine. Time to do something...

At least, there's one thing I'd like to know : when these errors occur, clicking on "Check for updates" re-launches the update process. In that case, no error message is displayed and the Event log doesn't show any additional error. But it doesn't acknowledge a successful installation either. So finally, are these modules actually updated ? Is there any way to check this ? If there is only one thing I'd like to be sure for an antivirus software, it is that it's correctly updated. Below, my list of components...