MikeRigsby
-
Posts
15 -
Joined
-
Last visited
Posts posted by MikeRigsby
-
-
I'm not too worried about this, since I've already figured out the version issue before I even made this post. I mainly just wanted to bring this to ESET's attention and also for anyone else out there who might run into this issue again with this new Windows update.
-
I just installed EES 7.3 from scratch on a brand new PC that has never had ESET on it at all, brand new fresh Windows install, and the version of eamonm.sys is still 10.14.32, and even states that the product version is for 7.3.2026.0.
So if that version is only for 7.2, it seems like something is wrong on ESET's side of things.
-
If we happen to not be updating everything as we should be, I'd definitely like to know.
Why is the most recent version of both the ESET server software and the client EES 7.3 still using eamonm.sys 10.x, or at the very least not replacing it with the newer version of eamonm.sys, if you're telling me that we need version 13.1?
Is there some setting that we're missing that is keeping those files from being replaced during the updates?
-
FWIW, I see forums on Microsoft's Answers site dating clear back to 2016 of people having this exact same issue so this has been a problem for a long time.
-
Ok, I can now verify.
If the system is running ESET 7.3 before the Windows 10 2004 update is installed it seems to work fine. This is only happening on systems running 7.2.
I'm not sure how to to uninstall eamonm.sys 'from scratch' and reinstall it but I did totally uninstall ESET completely and reinstall on the affected PCs as part of my troubleshooting to discover this and the file version of eamonm.sys in EES 7.3 is still 10.14.32.0. So it doesn't seem like the version of the .sys file is what's causing this problem.
-
I understand the need to always ask for memory dump files when issues arise but this is clearly a known issue already and it's the exact same issue as was mentioned in those earlier forum threads. I've attached the dump file for one of the two systems that I've had this issue on so far today.
I am currently in the process of installing the version 2004 update on my own work PC, which is already running EES 7.3, so once it finishes the long install process I'll see if I also have the same eamonm.sys BSOD.
My hope is that it is/was only happening on systems still running 7.2.
-
My specifics here are that these systems having the issue are running ESET Endpoint Security version 7.2.
I'm hoping that pushing out the 7.3 update to the 200 remaining PCs before the users install Windows 10 v2004 that it will keep this from happening.
-
The issue mentioned in these forum discussions listed below is happening again with the most recent Windows Enterprise x64 upgrade to Version 2004. I've already had to fix two systems this morning and likely going to have over a hundred more to deal with.
The "fix" is to boot the system into Safe Mode and use the esetuninstaller tool to remove ESET. You can, apparently since at the moment it seems to work, re-install it once Windows boots.
-
I don't know if this will apply to anyone else, but I re-enabled the Windows Search service on the one system that was throwing this error the most, since in my case it did seem like Indexing was causing this. I then upgraded it from 6.6.2052.0 to 6.6.2064.0 and this error hasn't come back.
Whatever was causing the file conflict may have been resolved in the new update by the looks of it.
-
1 hour ago, Marcos said:
We'll need to get this confirmed by more users since in most Procmon logs we didn't see any SearchProtocolHost records. Moreover, in one ticket the user stated that disabling the Windows Search service didn't make any difference but we could not verify if the user really did what he had claimed.
(Un)fortunately, the issue manifests very rarely and we have only very few reports of it in the last months to definitely confirm that Windows Search is involved.
Makes sense. Unfortunately "Failed to rename file" is probably just a generic error that's caused by pretty much any service or activity on the client PC that causes a file access conflict with the ESET update, at the time it was attempting to automatically update.
In my specific case it appears to be the Windows Search service, but most likely there's plenty of other activities that could cause it.
-
After a few weeks of not getting this error on the two PCs that I had disabled the Windows Search Service on I decided to re-enable the service again to make sure it was related.
Very next morning after turning the Windows Search service back on, I got the error again on those PCs so this issue is most definitely related to a conflict with Windows Indexing.
-
A couple weeks ago I disabled the Windows Search service on two of the PCs that this error was the most frequent on and the error hasn't happened since. I'm assuming that the Windows file Indexing is clashing with the ESET update service.
I don't really consider this a 'fix' because disabling a service that is fairly important to many of my users isn't a solution.
Win10 x64 Version 2004 eamonm.sys BSOD Loop
in ESET Endpoint Products
Posted
Nope, it was definitely 7.2, which was totally the problem. I was confused when you said 'version 13.1' when the version for EES 7.3 is still 10.14.
Just a miscommunication.
I've pushed out the 7.3 update across our entire Enterprise so this shouldn't come up again, hopefully.