Failed to rename file

[winram 0]

Windows 10 version 1709 build 16299.248
ESET Internet Security 11.0.159.9

I am getting occasional "Failed to rename file" when the product auto-updates.  

I've opened a case with ESET on this and have gone through the steps to uninstall/reinstall already as well as flush the cache.  This hasn't resolved the issue.

I'm reluctant to call in as my last case note instructed me to do, as this problem immediately resolves itself by manually running the update, and the issue usually happens every few days.  I am happy to provide information but since it is not immediately reproducible I feel that either there is a quick answer or a process I can run through, which shouldn't require me waiting for support..  Hopefully one that does not involve insane complex logging that also can impact the system.

From the google searches on this issue there is no clear cut answer that I've seen.

Any advice?  I'm just tired of seeing the red alerts when there isn't really a problem, this seems like a silly issue to have persisted.

[Marcos 5,074]

It could be that the ESET install folder is not excluded from indexing by Windows Search which locks an update file at the moment we attempt to rename it during update.

[COStark26 10]

3 hours ago, Marcos said:

It could be that the ESET install folder is not excluded from indexing by Windows Search which locks an update file at the moment we attempt to rename it during update.

Hi, Marcos. I get this too But every X Weeks vs Days. Manual Virus Update always works but it would be nice to eliminate the Update failures.

I found Indexing Options in Win 7 Control Panel.: Indexing Options/ Modify / Users/  Program Files/ ESET/ ESET Security ..... then Do what?

Edited February 19, 2018 by COStark26

[Marcos 5,074]

Here you can find step-by-step instructions how to open indexing options: https://helpdeskgeek.com/windows-7/windows-7-file-search-indexing-options/.

[COStark26 10]

22 hours ago, Marcos said:

Here you can find step-by-step instructions how to open indexing options: https://helpdeskgeek.com/windows-7/windows-7-file-search-indexing-options/.

Thanks for the Link but based on your Reply I presumed we need to learn How to EXCLUDE the ESET Install Folder from Indexing. The Link is more about Adding or Moving items. If you Clk Modify and Browse via "users" to all of the C: Gateway Folders, Program Files isn't even Checked, and I presume it must be checked to be Indexed.

I'll just manually update Virus Sigs when the popup occurs.

[winram 0]

On 2/19/2018 at 12:38 AM, Marcos said:

It could be that the ESET install folder is not excluded from indexing by Windows Search which locks an update file at the moment we attempt to rename it during update.

In reading the attached link and looking at my indexing options, it appears the ESET install folder is already excluded. (see attached)

So I'm confused how this could even potentially be an impact, or if this is the next diagnostic step, it appears to be irrelevant.  

Note that this is the default Windows 10 indexing option, I've not altered this in any way.

[Marcos 5,074]

Ok, so we could rule out Windows Search. How often are you getting the error? Would it be possible to start logging with Procmon, reproduce the error, save the log and provide it to me for analysis?

[winram 0]

2 minutes ago, Marcos said:

Ok, so we could rule out Windows Search. How often are you getting the error? Would it be possible to start logging with Procmon, reproduce the error, save the log and provide it to me for analysis?

See, this is where we'll have issue. 

ProcMon is a great tool, but it's finding a needle in a haystack.  I and others (as evidenced by this thread already) get this error once every few days.  I would NEVER want to keep procmon running for days on a production machine to hopefully capture an event that I cannot immediately reproduce.  PML data goes up to 1GB in minutes - you want me to run this for days??

Additionally, since an update only occurs a few times per day (DAT updates) this isn't immediately reproducible either, I would have to wait for an actual update of some kind.

I would very much like to know if there is actual logging of the update beyond the simple one-line in the log: "Failed to rename file".  That would also greatly help in the diagnosis.  What I have issue here is there is virtually no data for even intelligent people to work with on figuring this out.  The point that this thread and others have gone to indexing being a culprit is a bit strange since clearly default indexing doesn't impact this, unless of course it's renaming a file within the indexing scope.  I'd love to know WHAT FILE is the problem and specifically where it is located - and I shouldn't need procmon to have to figure that out either, don't you think?

 

[Peter Randziak 1,130]

Hello @winram

you can filter only events with path containing "ESET Security" also use the Drop filtered events option to reduce the log size than you should be able to use it for days if you have enough RAM on the system.

Also please before the logging start disable Launch protected under HIPS (requires system reboot) so Procmon can log all events.

Regards, P.R.

[Marcos 5,074]

Before you start logging:
1, If it's Windows 8.1 or newer, disable Protected service in the HIPS setup and reboot the computer.
2, After launching Procmon, set a "contains" filter for the path "C:\Program Files\ESET\ESET Security\Modules"
3, Enable advanced output in the Filter menu.
4, Enable Drop filtered events in the Filter menu.

Start logging with Procmon and wait until the error occurs. This way the log should be reasonably small and yet capture events on the folder where the issue occurs.

[winram 0]

10 hours ago, Peter Randziak said:

Also please before the logging start disable Launch protected under HIPS (requires system reboot) so Procmon can log all events.

I see no option for "Launch protected under HIPS"  Can you be more specific please?

EDIT:  NM Marcos had the detail. 

Edited February 21, 2018 by winram

[orfan40 0]

I too started getting this popup. I have Windows 10 version 10.0.1 build 16299. It started about two weeks ago. I ignored it for awhile but got tired of it popping up so I did the update. It went find and the popup went away but started up again. I don't want to go through the Procmon tool but would like it to get fixed. I'm relatively techno but not enough to run the tool, sorry.

[winram 0]

Please leave this thread alive -- I had some issue with the capture process that caused problem, but so far I've kept ProcMon running for a few days and looking forward to seeing what it reveals when it eventually catches it.  (Like I said earlier it takes sometimes few days -- hopefully I'll have some kind of event over the weekend).

[Marcos 5,074]

Do you mean that the issue hasn't occurred with procmon logging?

We've got a Procmon log in the meantime where SearchProtocol.exe was holding an update file which prevented ekrn from renaming the folder.

[winram 0]

It hasn't yet, no.   It's an average of every 3 days or so, sometimes more sometimes less.  And also only when a DAT actually gets updated ... no effect on no changes, so how often do the DATs get updated?  So I have about 3-4 shots a day or so at this error happening, by my estimation.

If I could guarantee a DAT refresh, I could perhaps force this, but until then, I have to wait til whatever happens, happens.

I'm extremely curious why SearchProtocol would impact this, seeing as the configurations as detailed earlier in this thread seem to indicate that this folder is already excluded from the search parameters -- or at least not specifically included.  I wouldn't want to turn off a Windows service to fix this.

[winram 0]

I had another issue, but the ProcMon.exe failed to log anything special whatsoever beyond what it does normally in every update cycle -- all "SUCCESS" and "NO MORE FILES"

I'm re-validating my logging and resetting to see if it can again be reproduced and will update again.

What exactly do you need when this event occurs?  What am I looking for?  If you're looking for a failure, nothing is failing in this procmon list.  While this is not the error window in question (this is just how it looks when updating), this is all that I'm getting during an update.

I will totally admit I got frustrated, annoyed, and closed the program and threw my hands in the air when this logged nothing at all different. 

I'm asking this on the assumption that when I see this error again in a few days that, once again, there will be nothing special discovered here that will lead to a resolution, or that potentially again I must force detail out of ESET that might spare me more days of analysis.  Can we possibly be a bit more proactive here?  Am I capturing the right level of detail?  The filter only has one line in it -- the folder in question.  Is that all?  Should there be more?  This goes back to the question I had before -- what exactly is going on during the update process?  

Why does this feel like pulling teeth? 

[itman 1,659]

Are you running any third party disk management software such as a disk defragmenter?

[winram 0]

I am not.

I am wondering why this is all the data we ever get on the issue from the ESET side of things.  I'm doing an awful lot of diagnostic for something where I can't even see detail as to what is going on.

Edited February 25, 2018 by winram

[Marcos 5,074]

I think you have an incorrect filter set. Instead of the condition "is" you should use "contains".

[winram 0]

I finally got a captured event, but it took several days since my last reboot and the log file is 18mb and unable to upload here.  I have created a case #122337 with details as below:

An automated update occurred on 3/6/2018 at 8:58:46pm : "Failed to update file"
I forced a manual update immediately after (3/6/2018 at 8:59:31pm): "Failed to update file"
I forced another manual update immediately after, with no error.

I have a PML of 18mb zipped which has the capture.  Hope someone can help...

[Marcos 5,074]

Please upload the log to a safe location (e.g. Dropbox, OneDrive, etc.) and drop me a message with a download link.

[Marcos 5,074]

1 hour ago, winram said:

I finally got a captured event, but it took several days since my last reboot and the log file is 18mb and unable to upload here.

In your case it's a backup-related process CarboniteService.exe which is having a handle for an update file open at the time we attempt to rename the appropriate folder. Is it possible to configure the backup sw to exclude the Modules folder at least?

[winram 0]

I have the vanilla Carbonite settings, which excludes "\Program Files" content.  I verified my Carbonite backups do not include anything from any ESET folders in there (full disclosure - I have nothing outside of \users\ backed up - completely vanilla Carbonite configuration).

I find it highly interesting that there are several AV vendors listed as hard exclusions.  Is there a specific collision in question here that can be called out that you found?  See the below link for "Files Excluded From Backup".  I'm happy to initiate a support case with Carbonite provided you can give me some hard data to work with here and reference this thread.  It seems that they only block one file for one variant of ESET product.

https://support.carbonite.com/articles/Personal-Windows-File-Types-Carbonite-Backs-Up

[winram 0]

Case 02316458 opened with Carbonite, referenced them back to this thread.

[Marcos 5,074]

Actually there's no issue with the Carbonite sw, it merely acts as a catalyst. We are working on a fix on our part.