Jump to content

Definition Update Issue with Version 9.0.386


Recommended Posts

I upgraded two computers this morning from version 9.0.381.0 to 9.0.386.0.

 

After updating, the following behavior is occurring on both systems (Win7 x64 Ultimate, fully patched):

 

1) ESET is updating the virus definitions.

2) The last updated flag is not being updated.

     a) On the update tab, the current definition number is indicated, but the "Last successful update" status is "update has not been run yet." 

     b) On the home screen, the update status is also "update has not been run yet"

3) In the event log, it is clear that updates have been run, and run successfully.

 

Please advise. Thank you.

 

EDIT: I just noticed that definition 13829 was released. So, before the auto update kicked in, I manually updated on both machines. Both updates were applied successfully. However, the status on both machines is still "update has not been run yet," even though the log shows a successful update, and the virus signature database is correct in "help/about."

 

This was not an issue in 9.0.381 or earlier versions.

 

EDIT/UPDATE 2: I just updated from build 381 to 386 on a new Dell Win10-Pro x64 machine (where I just installed ESET for the first time yesterday). Same behavior.

Edited by howardagoldberg
Link to comment
Share on other sites

  • Administrators

This was an issue in previous v9 versions but it should be fixed in 9.0.386. I was unable to reproduce it with the latest version (clean install, not upgraded).

Link to comment
Share on other sites

All I can report is that -- this was never an issue for me in previous versions (I have been using ESET since version 5, or earlier), and presented on multiple systems when updating from V9 build 381 to 386.

 

That being said, this morning the issue seems to have magically resolved itself :-).

 

Will let you know if the glitch occurs again.

 

Thank you.

Link to comment
Share on other sites

I can confirm the issue.

 

Yesterday I upgraded from version 9.0.381.0 to 9.0.386.0  (Win7HP64SP1)

Last successful update (Update) is shown as 2016-07-19 20:32:41  (my time)

However that is for database version 13828.

 

After that there were updates for database version 13830,13831 and 13832.

(as I could see in Log files / Events with different date/time stamp)

But the date/time stamp of the last successful update has not changed anymore.

 

Also in Tools / Scheduler I can see that updates were done at a later date/time.

(latest regular automatic update 2016-07-20  14:46:27 (my time) )

This is a little bit confusing.

Link to comment
Share on other sites

Last night, after posting my initial report ... I did actually turn off the computers in question. This morning, upon rebooting everything ... the issue seems to have resolved. It is strange, since I did reboot each system after the update from 381 to 386, but perhaps something was just wonky enough that a second reboot was required?

 

If those of you who have also reported this issue have not rebooted a second time since updating to 386, give it a try and let us know what happens!

Link to comment
Share on other sites

This morning Last Successful update shows 2016-07-20  21:46:44.

That is for database version 13834, so the time was updated yesterday.

 

However Virus signature database version shows 13837 (20160721)

And Log files / Events shows latest update (13837) was 2016-07-21  11:51:28

(all dates/times are my time)

 

So I still have a problem, only occasionally (?) update of the Last successful update?

 

 

 

Hello Siljaline, yes we meet regularly in a newsgroup.

Latest version announced by Eset in this forum is 375,

I discovered the release of 381 and 386 via other channels.

One may wonder why Eset does not say so?

Link to comment
Share on other sites

An update ...

 

The problem definitely still exists, but with the following addendum:

 

1) If you completely shut down your computer, and then

2) Reboot your computer from a cold state, and if

3) Before logging on, ESET runs a background update, then

4) the "update was last run" information on the home tab and update tab do show correct information.

 

However, if you are logged on to Windows and a background update runs or the user initiates a manual update, the "update was last run" information on the home tab and update tabs are NOT updated.

 

So, for me, since I do turn off my systems overnight -- at first use in the morning, the update information looks as it should as ESET runs an update after the computer have been off for 5-8 hours. But as the day goes on, even with background updates running as expected (and the occasional OCD manual user update when I notice a new definition has been released), the "update last run" data is stuck at the "boot up" update data.

 

Most certainly an ESET bug. Hopefully one that does not compromise the safety of our systems (I suspect not, but would like to see this acknowledged and addressed ASAP).

 

Again, I can reproduce this on 2 Win7 Ultimate x64 systems and 1 Win10 x64 Pro system.

Link to comment
Share on other sites

An update ...

 

The problem definitely still exists, but with the following addendum:

 

1) If you completely shut down your computer, and then

2) Reboot your computer from a cold state, and if

3) Before logging on, ESET runs a background update, then

4) the "update was last run" information on the home tab and update tab do show correct information.

 

However, if you are logged on to Windows and a background update runs or the user initiates a manual update, the "update was last run" information on the home tab and update tabs are NOT updated.

 

So, for me, since I do turn off my systems overnight -- at first use in the morning, the update information looks as it should as ESET runs an update after the computer have been off for 5-8 hours. But as the day goes on, even with background updates running as expected (and the occasional OCD manual user update when I notice a new definition has been released), the "update last run" data is stuck at the "boot up" update data.

 

Most certainly an ESET bug. Hopefully one that does not compromise the safety of our systems (I suspect not, but would like to see this acknowledged and addressed ASAP).

 

Again, I can reproduce this on 2 Win7 Ultimate x64 systems and 1 Win10 x64 Pro system.

 

I shut down my computers every night.

 

Problem still exists.

Doesn't hurt anything but still should be fixed.

Link to comment
Share on other sites

  • Administrators

Didn't notice this issue with v10. Since most likely there won't be any further version 9, let's wait for v10 which shouldn't take long to go final.

Link to comment
Share on other sites

Release V10 then as this build seems to be causing too many headaches.  Last time I looked ESET AV was set-and-forget.        

 

Didn't notice this issue with v10. Since most likely there won't be any further version 9, let's wait for v10 which shouldn't take long to go final.

Link to comment
Share on other sites

An update ...

 

The problem definitely still exists, but with the following addendum:

 

1) If you completely shut down your computer, and then

2) Reboot your computer from a cold state, and if

3) Before logging on, ESET runs a background update, then

4) the "update was last run" information on the home tab and update tab do show correct information.

 

I can confirm this.

I switch off my computer every night and switch on every morning.

 

Yesterday Last successful update did nor change.

Today the first update after switching on was recorded.

Last successful update 2016-07-22  8:46:26 (version 13842)

 

 

Later in the morning I switched off and in the afternoon I switched on.

No updates were recorded anymore since first start this morning.

Updates 13843, 13844, 13845 and 13846 passed without changes

to Last Successful update.

(all dates/times my time.)

 

I will ignore Last Successful update (I can also look in Log files / Events).

I will wait (have to wait) for version 10.

Link to comment
Share on other sites

Unless, version 10 is coming out next week ... I think this should be a (relatively) simple bug to squash? I understand this is probably cosmetic, but still think it needs to be addressed (or at least acknowledged with a confirmation that there is no security risk involved).

 

The statement "This was an issue in previous v9 versions but it should be fixed in 9.0.386 ..." is clearly in error given the number of confirmations of the issue.

Link to comment
Share on other sites

Unless, version 10 is coming out next week ... I think this should be a (relatively) simple bug to squash? I understand this is probably cosmetic, but still think it needs to be addressed (or at least acknowledged with a confirmation that there is no security risk involved).

 

The statement "This was an issue in previous v9 versions but it should be fixed in 9.0.386 ..." is clearly in error given the number of confirmations of the issue.

It's nice to be ignored, isn't it? :(

Link to comment
Share on other sites

  • Administrators

V9.0.381 had a different issue with last update notifications and the problem in 9.0.386 is a consequence of fixing the bug from 9.0.381. We'll see what can be done about it but fixing both issues together will not be an easy task and it's likely that only v10 will have them fixed both.

Link to comment
Share on other sites

Today all day Last successful update showed 2016-07-22  20:36:26, date/time from late yesterday.

This is odd because I did not switch of my computer before this date/time, so it was not updated after a cold start.

 

Today version updates 13848, 13849, 13850 without changes to Last successful update.

 

 

V9.0.381 had a different issue with last update notifications and the problem in 9.0.386 is a consequence of fixing the bug from 9.0.381. We'll see what can be done about it but fixing both issues together will not be an easy task and it's likely that only v10 will have them fixed both.

 

 

Imo these are statements made by marketing not by technicians!

 

Long time ago I was a (Cobol) programmer and a good one.

Fixing a bug is *never* an excuse for a new bug, proper testing should have prevented this!

And please do not say that fixing two (2) bugs is not an easy task, that looks so silly.

 

If fixing some (minor) bugs is a problem, then what is the quality of the programmers at Eset???

(hire some autistic nerds, they are very good in solving problems.)

If Eset does not want to spend efforts in correcting these bugs in version 9 than do say so.

 

This is my last message in this thread.

If marketing gives (lame) answers on behalf of programming I am done.

It only makes me wonder how I can look at the quality of the products of Eset.

Edited by FredW
Link to comment
Share on other sites

Since I noticed no issues with build 9.0.381 ... and have noticed issues in 9.0.386, is this a case of the cure being worse than the disease?

 

At any rate, can you please advise (confirm) that there is no actual impact on the security being provided by the product, and what the timeline is for  fix and/or the release of V10?

 

Thank you.

Link to comment
Share on other sites

I just want to know if I should make a post in eset smart security or will this be fix in version 10 for eset smart security

It wouldn't hurt to put it there.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...