Crashes with version 4.2.67.10

If possible, disable the startup scan tasks in Scheduler temporarily to see if the crashes cease occurring. Real-time protection will scan files that are accessed/created anyways.

 

Uh, HMM. I take it back. Startup scanning is disabled on my machine. Last run 11/17/10. Probably disabled it when I was having problems last time and forgot to turn it back on. So, I'm getting the issue when HTTP scanning is on and start scanning is NOT enabled. UGH>

 

I had "startup scan" disabled since yesterday but a crash occurred today.

I still have enabled "scan after update", but the crash occurred much later than update 5757 was made.

Good night

 

The problem has manifested itself on my other two 2003 R2 Terminal Servers. Headed to the data center (again) to take a look. I believe people were logged in at the time and the session stopped responding. Earlier today the console itself stopped responding on other TS machines and I hard to hard boot, then completely uninstall ESET to get them to behave...

 

Put in a ticket with ESET support and just got a response where they had me install a ESET Update Fix. Anyone else get this and install it yet?

 

Where did they have you go? I'm willing to be lab rat and try it.

 

http://download.eset.com/special/eset_update_fix.exe

 

Ok..going to the sandbox to give it a shot

 

Thanks for testing it out. Unfortunately I'm working in a non-profit and the only server we have is our live terminal server which everyone uses and this whole thing has been a huge headache.

 

The above mentioned tool simply restarts ekrn no matter what state it's in. It can be used as an immediate fix to make ekrn functioning if it doesn't restart automatically for whatever reason.
I've prepared a bunch of dumps for the developers so I expect a fix to be ready soon. We'll keep you posted on the progress.

 

From what I understand the tool posted further up the thread reboots ekrn.exe in services ? Mine is currently in a stable state, awaiting further instructions.

 

This is server #5 today...

Wow, interesting...

So I just had a client call mentioning issues with their exchange server, timing out opening outlook and so on.


Logged into the server and it did let me on, but was bugging out and locking up.

Was able to CTRL ALT END (Ctrl alt Del over terminal services) and open task manager.

Found ekrn.exe eating about 25% cpu consistently (on a single core, HT box)

could not open the eset console, IE wouldn't open, just hung opening a blank page, could not kill ekrn it because of antistealth etc, but I was able to open a command prompt and open this update fix file from another machine i downloaded it to.

as soon as it ran, everything came back to life and ekrn.exe was killed.

This was on an older build of Eset Mail Security, the Version 4.2.10016.0

I'm going to update this client to the beta 4.3 latest build and uncheck all the antistealth things and reboot their server and see if it happens again.

Whatever ekrn is doing seems to snowball the system after some time, I think i just got in before it completely hung up to where you couldn't even RDP like the other servers, then you can't access files over network and so on.

 

Hi!

One of our customers is having the same problem.

They reported CPU consumption of 50% (ekrn.exe), they don't able to navigate in the internet and they don't able to receive e-mail.

I'm concerned about these events. Something similar happened in September.

 

I've had to remove NOD32 from all our servers again. It was causing repeating hard lockups (IIS, RDP all dead) on all our high utilisation servers (Windows 2003 and Windows 2008 R2).

 

Just happened on Server #6, running 4.2.40...

Guess I have to stay up all night tonight to babysit...

 

Killing the ekrn process is the only thing that helps indeed.. Also update 5757 does not help and one of my other servers just went back to 5754 for no apparent reason..

Hope you guys fix this soon.. rlly..

 

For people with crashes and wanting to wait, here is a temp fix i've verified to work for some large clients: http://kb.eset.com/esetkb/index?page=content&id=SOLN2567

For people wanting to generate logs to help, send me a PM.

 

Nice workaround, but not workable for ppl with terminalservers and loads of active sessions on there during workhours.

ESET needs to push a new update which resolves this without the need for a reboot!

 

We are experiencing the same problems! We have terminal servers which are unresponsive (deadlock), faults in ekrn.exe, RPC calls which are failing... this is all since the 30 december 2010 and update 5747. Restarting servers is the only solution.

When does ESET Nod32 Europe starts communicating confirming this issue!?

We are running EAV Nod32 4.0 update 5757 at Windows Server 2003 32 bit. We have no drive C:\ at our terminal servers...

Technical question: what is included within the patern files besides the anti-virus definition? Is there some flexibele executable code within the updates which allows Nod32 to be more flexible? What is the root cause problem why ESET can't find or locate the issue...

 

We are still looking hard for anyone willing to coöperate to create the needed logs. It would require rebooting about two times and into safe mode, and sending dumps of the crashes. Please contact me if you want to help.

 

I'm going to have to remove ESET from the remainder of my servers (something that has a more appealing ring to it the longer this problem goes unresolved).

Can't spend another day with angry coworkers, sorry.

 

The time between failures are random and we can't predict when it happens. We have allready applied the fix and waiting... for the next crash.

Please start sharing information, i've posted some questions but they were not answered.

 

An update with a fix in the code added to the engine on Dec 16th is being being prepared right now and will be released soon. We assume this should fix all issues related to ekrn that have recently been reported.

We highly appreciate your assistance and thank you all who have contributed in pinpointing the cause. We will keep you posted on this matter.

 

If I had any info I would share it, but I'm as much in the dark as you are. I have a dump from a customer i've uploaded, and that is being analysed as we speak. I can also tell you that the next update 5759 could possibly fix this, but this is up to you guys to test.

edit: damn, marcos beat me to it

 

As I mention in another thread (https://www.wilderssecurity.com/showthread.php?t=290185) we have been able to stabilize our terminal servers by disabling email client protection.

I have setup one of our three terminal servers to capture procdump information, but ekrn.exe has not crashed since then.

I'm glad it's not crashing, but obviously can't provide the dump to ESET unless it does.