AV Definition update caused error

I used to receive emails daily from Symantec with news on updates and such. Does ESET offer such a service? If ESET doesn't have anything, is there a listserv for NOD32 out there?

 

Hi Guys,

We have updated all of our servers which are running 2003 and 2008 R2 and we are still getting the freezing and servers hanging so this has obviously not resolved the issue.

Please can you update ASAP

Thanks

 

I've got the same server versions and had to reboot them several times, on some occasions by just powering off the server - ESET wouldn't allow me to shut them down safely.

 

Can I chime in?

Not trying to rub it in, but we got lucky here. Out of the 87 workstations we have on our RAS, only 5 of them got impacted by the update, though the others were all updates to 5418 and did not suffer any problems (not sure why, actually). Plus, only our Terminal server got hit.

But I can't understand how proper QC could've help, here. The bug was in 5417, but was only triggered when applying 5418. How do you test for that? Is there a way for ESET to test that the next update they push won't make it crash? I don't think it's very feasible.

It's very unfortunate, what happened! But I have to say I've been working with NOD32 here for 2 years, on a RAS for 1.5years, and the last year on v4, and it's the first time I encounter any of those problems whatsoever.

But yeah! It's sucks!

 

Pretty obvious that we need the ability to stop the ekrn service on servers without rebooting them. Even when I uncheck "enable self defense" and reboot, I still can't kill ekrn. v4.2.64.12

 

Completely agree. There needs to be a method for this, the amount of downtime to customers we could of avoided...

 

Our servers broke when v5417 was installed. They couldn't update to v5418 because when I tried to open ESET, the window was blank. After a few seconds ESET said "Cannot communicate with kernel".

Had any kind of QA/QC been done, these issues would have been picked up.

 

Did you also restart the servers after update to 4519? With self-defense disabled a computer restart is not necessary, simply kill ekrn.exe and it will restart automatically. We're trying to find a way how to accomplish that with SD enabled without restarting the computer.

 

Our servers aren't freezing, but our TS displays a Winlogon.exe crash at logon, for all users. It was fine prior to today, and we've rebooted and updated to 5419.


Jim

 

The symptoms we had were: no web browser (or remote access, as we use LogMeIn, which operates using HTTPS), stop error messages, and complete lock ups. Thankfully I was able to see which machines have which updates via the ERA. The ones that had 5417 and 5418 had to be rebooted, install 5419, then rebooted. Some machines received 5419 without issue. I had everyone reboot their workstations once 5419 was deployed, just in case.

 

Hi There,

We have updated to 5419 and given them a reboot, well getting on for multiple reboots now as the keep freezing and locking up.

We have 5 sites gloablly affected with this now so to say im unhappy is an understatement.

Just to be clear the main issue is with servers not the workstations.

 

I've been reading on/off all morning but just now posting.

We have 130 servers and over 3000 clients that are affected or potentially affected. It looks like we will be here throughout the night...

I had a question for anyone who has experienced this but if you have a client that is below 5417 and you update to 5419 will the ekrn still crash....

 

For anyone still having an issue after updating to 5419, I'd highly recommend contacting ESET directly through customer support at this point, as per the official post by Rmuffler above.

There is a chance that this thread may not get official attention now that the fix and knowledgebase article have been published.

 

Doubt it, but I have clients like this too and would like to know the answer too please.

 

I'd actually like to see an option for 'Delayed updates', where the ERA will automatically wait for X Hours/Days from when an update becoems available until it is applied.

I'd happily trade being slightly behind on updates to having something like this happen again.

Although, in all fairness, I only seem to recall one time in the last 8 years we've been using NOD32 that something like this happened.

 

This is probably just going to put the last nail in the coffin......

 

Actually, these problems happen very infrequently. NOD32 happens to be one of the most stable programs I use.

 

This is out of control!!!!!!! and I pushed for months to have Eset installed in our company well over 1000 machines and several locations. You say a reboot works well that is all and fine but what about Servers in production? This is costing and has probably cost my company well over a couple thousand already. I will be getting some kind of payback for this ?? I hope I still have a job to come to in the morning.

 

If you have v3 or have Self-defense disabled, it's enough to kill ekrn and it will restart automatically. For those with v4 and SD enabled, we're preparing a tool that will accomplish this if you had the problematic update 5417 installed.

 

Still no excuse, especially when you're faced with lots of time wasted and profit lost when your infrastructure dies and you have to reboot everything several times to fix a problem that could have been avoid through proper testing on ESET's side.

In my opinion, ESET will never learn. Look at their new releases... They're always full of bugs, despite being put through "beta" testing (though I don't believe enough testing is done in the first place). ERA 4.0.122 is a great example.

 

Marcos - I'm currently holding my site clients at 5418. My question is whether or not a possible 5420 update will allow me to start updating again without exhibiting the issues that have been reported here today. I've had (so far) only 4 users out of my own 340+ that have had freezes, and I'd like to keep it that way...

I'd like to avoid the whole "Reboot all of your clients, maybe twice" thing if I can. Our servers were not impacted at all, but we just run 2.7 on them.

 

Were the Windows 2000 Server issues mentioned earlier successfully resolved with a reboot?

I have only been able to reboot one of our older W2K Servers, the least important one if bombed on the reboot, but it seems to have come back up fine.

Still waiting for the end of the day to start on the mess with the rest of the servers. Client workstations seem to be fine now after multiple reboots, but still blocking definition updates just in case.

 

Well...here we are...a happy techy department at 8.10pm....gonna be here until we reckon around midnight or so.....thanks guys.....think you have it hard? Imagine being a major reseller into large clients and Schools and colleges.......

My biggest client now has close to 2000 users unable to work on over 700 base units.....you can bet he's a happy bunny with me.....

TEST YA F****** UPDATES BEFORE YOU RELEASE THEM. THIS IS THE SECOND TIME I HAVE HAD TO PULL AN ALL NIGHTER BECUASE OF YOUR INCOMPETENCE.

REBOOT YOUR SERVER? YOU ANY IDEA WHAT THAT ISSUE CAN CAUSE? 700+ SERVERS.....WE ARE A PREDICTING A 10% FAILURE ON REBOOT FOR VARIOUS REASONS......AND SCHOOL STARTS BACK IN 3 DAYS....THANKS THANKS THANKS...

and yes...I know I had caps on

 

For those complaining about updates not being tested before they are released, I'd like to emphasize that updates are indeed tested thoroughly first. Of course it's impossible to test a signature update for a couple of days as they need to be released several times a day in order to cope with new born malware. In this particular case the problem wasn't in the update after which the problem started exhibiting so reverting to the previous version wouldn't help either. Testing the two last updates individually didn't reveal any problems either. It was a combination of several factors that led to the issues.
I can assure you that the necessary measures will be taken to minimize the possibility of severe issues occurring after automatic updates.
Our developers are working on a tool for those who cannot afford restarting servers and will stay in the office until the tool is ready for use.

 

Your testing procedure isn't very useful if it doesn't test how the definitions would load in an *actual* environment. I hope you can at least see THAT...