Jump to content

winram

Members
  • Posts

    15
  • Joined

  • Last visited

About winram

  • Rank
    Newbie
    Newbie

Profile Information

  • Location
    USA
  1. How will we know when a future version contains a possible fix?
  2. Date and time are accurate, disabled and re-enabled SSL, restarted computer. I have this same issue. I figured it was related to this article, but can't confirm. hxxp://searchsecurity.techtarget.com/news/252436120/23000-Symantec-certificates-revoked-following-leak-of-private-keys Get it a lot just visiting CNN and watching news videos from there. And yes, happened a lot in the the last week.
  3. I am on the pre-release version of ESET Internet Security now and just got the error again, not running ProcMon at this point though. FYI.
  4. I'm confused then about who really owns this issue. Is this an ESET problem or not? If Carbonite (or SearchProtocolHost from other threads related to "Failed to rename file") are colliding with files in this folder, why does ESET recommend to turn off the 3rd party service on the Modules folder, then when I chase that point, say that it's an ESET problem? The ESET case I opened responded and recommended I go to pre-release version of ESET. I've done this. I have no way to verify except to wait. This bugs me. I just want to know how I can productively help bring this to a verified close.
  5. Case 02316458 opened with Carbonite, referenced them back to this thread.
  6. 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
  7. 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...
  8. 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.
  9. 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?
  10. 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.
  11. 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).
  12. I see no option for "Launch protected under HIPS" Can you be more specific please? EDIT: NM Marcos had the detail.
  13. 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?
  14. 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.
  15. 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.
×
×
  • Create New...