Eset Updating Hung .............. Again

[itman 1,659]

Win 10 x(64) 21H1, EIS 14.2.19

Same behavior as occurred a couple of weeks ago.

Upon first system startup of the day, Eset Update checking hung at "downloading 1/3." And impact of this was significant on PC performance.

Rather than try to stop updating activity within Eset GUI as done previously resulting in a borked Eset installation with DBI not functioning properly, I performed a system restart as a previous poster noted in another thread. Upon system startup, Eset successfully performed a signature update w/o issue. Two hours later I also received a module update w/o issue.

[Marcos 5,074]

As of v14.2 update is run with the lowest cpu priority possible. In case of performance issues, please provide either a full memory dump from that point or create advanced OS log (adv. setup -> tools -> diagnostics) from update.

[itman 1,659]

3 minutes ago, Marcos said:

As of v14.2 update is run with the lowest cpu priority possible. In case of performance issues,

The performance issue was caused by the hung update. There are no performance issues when Eset updates w/o hanging.

[SlashRose 25]

Can only fully confirm what Itman describes as in the other posting and as I wrote there, it is at irregular intervals, where only a restart remedy!

[NewbyUser 73]

Akamai DNS global outage takes down major websites, online services (bleepingcomputer.com)

 

Could explain issues today.

[NewbyUser 73]

Depending on when your previous issue happened there was also a large outage on June 8th 

 

StackOverflow, Twitch, Reddit, others down in Fastly CDN outage (bleepingcomputer.com)

[itman 1,659]

26 minutes ago, NewbyUser said:

Akamai DNS global outage takes down major websites, online services (bleepingcomputer.com)

Could explain issues today.

If the Eset update hang issue was related to this, it would have not resolved itself after a system reboot as I see it.

Edited July 22, 2021 by itman

[peteyt 393]

7 hours ago, itman said:

Win 10 x(64) 21H1, EIS 14.2.19

Same behavior as occurred a couple of weeks ago.

Upon first system startup of the day, Eset Update checking hung at "downloading 1/3." And impact of this was significant on PC performance.

Rather than try to stop updating activity within Eset GUI as done previously resulting in a borked Eset installation with DBI not functioning properly, I performed a system restart as a previous poster noted in another thread. Upon system startup, Eset successfully performed a signature update w/o issue. Two hours later I also received a module update w/o issue.

Have you confirmed Hips is also working fine?  I remember you had issues with Hips last time this happened although as you stated you tried to stop the update last time

[itman 1,659]

1 hour ago, peteyt said:

Have you confirmed Hips is also working fine?  I remember you had issues with Hips last time this happened although as you stated you tried to stop the update last time

First thing I did.

Easiest way to verify DBI functionality is to open a cmd prompt window. Then open Process Explorer and verify that Eset's DBI .dll is injected into it. However, I now see two instances of the .dll injected which doesn't appear right to me. But two is better than none!

-EDIT- cmd.exe shows the thread for Eset DBI.dll and a weird null stop code. Don't know what that null stop code value is about:

Edited July 22, 2021 by itman

[Marcos 5,074]

Please provide:
1, EsetPerf.etl created after enabling advanced OS logging in the advanced setup -> tools ->diagnostics from an update when it "hangs". Is the system responsive at that point or you can only perform a hard reset?

2, An ekrn dump generated via advanced setup -> tools ->diagnostics -> Create when the update is "hung".

[itman 1,659]

7 hours ago, Marcos said:

Is the system responsive at that point or you can only perform a hard reset?

Obviously the system is responsive or I couldn't perform a system restart from within Win 10.

Also the system is not hung when this Eset updating hanging occurs. The status would be best described as very sluggish.

The simple solution here is for Eset to modify its updating processing to time out and terminate update processing after a reasonable amount of time has elapsed with no download activity occurring.

Edited July 23, 2021 by itman

[itman 1,659]

@Marcos , it happened again this morning; well, sort of.

What I observed was strange behavior from Eset EIS 14.2.19 when I opened the Eset GUI Update section. It appeared that a module update was taking place. Specifically, I saw Eset module files being displayed. This activity stopped and the definition update phase started and stuck at 1/3 downloading. Checking later in C:\Program Files\ESET\ESET Security\Modules, three modules were updated; engine, Pegasus, and Horus database. The Eset Event log however shows no module update occurred; only a definition update.

Later as I was fumbling around in the Eset GUI to find the section to create the logs you requested, the defintion update finally completed. Total elapsed time was 5 - 10 mins. or so.

Also while all the above was going on, my HDD was thrashing away with resultant sluggish system behavior. -EDIT- In this regard note the abnormal ESENT Win Event log entry:

Edited July 29, 2021 by itman

[NewbyUser 73]

For me the last two updates have hung due to a supposed licensing issue that resolves itself almost immediately.

 

[itman 1,659]

@Marcos. I also need to know if Eset is fooling around with Win 10 DCOM.

I recently embarked on fixing DCOM events flooding my Win Event log. The gist of that issue is described here: https://docs.microsoft.com/en-us/answers/questions/281617/the-application-specific-permission-settings-do-no-1.html .

The problem is when I used dcomcnfg to fix this AppID, I couldn't perform the fix due to the inconsistent registry permission setting message appearing. Also, I noticed there was a logon permission associated with this activity which was most disconcerting.  Allowing dcomconfig to resolve the inconsistent registry issue associated with the app also removed the previous logon permission entirely from both available registry permissions and DCOM.

Is any of the above noted logon permission associated with Eset?

Edited July 29, 2021 by itman

[itman 1,659]

I will also add that running an Eset engine update which is over a 100 MB download at system boot time is not desirable activity at system boot time. This may very well be the source of this sporadic Eset update behavior issue. An engine update should be delayed to after Windows has fully initialized itself.

[itman 1,659]

Upon further review, it appears additional Eset module folders were updated although no updates occurred to the .dll contained within. This doesn't look right to me. -EDIT- This was a later update but the creation of a "00" folder doesn't look right to me.

Edited July 29, 2021 by itman

[Marcos 5,074]

Please upgrade to v14.2.23 downloadable from https://forum.eset.com/files/file/30-eset-security-14223 (EAV/EIS x64 only). The new build is going to be released in a few days and addresses several issues from the current version.

Let us know if the problem with update has been resolved.

[Marcos 5,074]

26 minutes ago, itman said:

I will also add that running an Eset engine update which is over a 100 MB download at system boot time is not desirable activity at system boot time.

Module updates are not that big. If ESET is updated regularly and no update is skipped, the current size of the engine update is 18 kB. If more than 20 updates are skipped, the size of the engine update is approximately 1,3 MB.

[itman 1,659]

1 hour ago, Marcos said:

Please upgrade to v14.2.23 downloadable from https://forum.eset.com/files/file/30-eset-security-14223 (EAV/EIS x64 only). The new build is going to be released in a few days and addresses several issues from the current version.

Let us know if the problem with update has been resolved.

I did an install on top of 14.2.19. Will post back in this thread if the prior update issues persist.

What about my DCOM question? Does Eset use it and if so, does it create a logon id permission as I noted previously?

[Marcos 5,074]

Just now, itman said:

What about my DCOM question? Does Eset use it and if so, does it create a logon id permission as I noted previously?

I'm sorry but I can't answer it myself, will have to ask developers.

I assume there's no connection with the update issue discussed in this topic even though you posted it here, isn't it?

[itman 1,659]

27 minutes ago, Marcos said:

I'm sorry but I can't answer it myself, will have to ask developers.

I assume there's no connection with the update issue discussed in this topic even though you posted it here, isn't it?

I am not sure.

I am concerned about that logon permission noted since its not normal. It also would allow someone to logon remotely via DCOM.

[NewbyUser 73]

10 hours ago, itman said:

Upon further review, it appears additional Eset module folders were updated although no updates occurred to the .dll contained within. This doesn't look right to me. -EDIT- This was a later update but the creation of a "00" folder doesn't look right to me.

I don't have a "00" folder in said location.

 

 

[itman 1,659]

11 hours ago, NewbyUser said:

I don't have a "00" folder in said location.

It doesn't exist in that specific module directory after the upgrade to 14.2.23. But it does exist in a couple of other module directories.

[itman 1,659]

@Marcos, are the below .raw files legit in regards to module sub-directory files? There were a number of like entries for modules prior to the 14.2.23 upgrade. After the upgrade, only a few contain this .raw file.

Edited July 30, 2021 by itman

[Marcos 5,074]

Yes, raw files are legit update files. Also the folder 00 is expected in certain cases.