ekrn locks computer (100% cpu) on flash uninstaller - workaround available

A fixed update won't help most of us that have hundreds of clients that aren't able to boot up far enough to update or change any settings before ekrn locks up the PC. I have some really angry clients that have already lost over a day's work.

 

Re: ekrn locks computer (100% cpu) on flash uninstaller

I had to look that one up:

Nullsoft Scriptable Install System
http://en.wikipedia.org/wiki/Nullsoft_Scriptable_Install_System

So I take it Adobe Flash uses NSIS?

 

That's weird. The issue would occur if an NSIS installer was run on system startup and all these users changed default settings for real-time protection which seems to me unlikely. If they are unable to boot up, have them uninstall EAV/ESS in safe mode and install it in normal mode from scratch. With default settings, there should be no problems with the arch. module. A fix is already being distributed via automatic update. Should there be a problem with uninstallation in safe mode, refer to this article

 

Re: ekrn locks computer (100% cpu) on flash uninstaller

Right.

 

In my test the high CPU didn't start until I logged on to the machine. (I used Sysinternals pslist to check the CPU from another machine before logging on to the test machine.) I believe that ESET updates will load without a person being logged on. Also if you're using ESET Remote Administrator, you can push the Scan all files setting to the machines, and it will be applied even before logon.

Unfortunately the settings in the ESET Configuration Editor bear little resemblance to the user interface. Of the many places to set extensions, I finally figured out that the one to change for version 3.0:

ESET Smart Security, ESET NOD32 Antivirus > File-system filter > Scanner (file-system filter) > Extensions > Extensions setup.

Mark

 

Mark, can you confirm or deny that these computers had real-time protection set to scan files with default extensions instead of scanning all files as set by default?

 

Confirmed, though I vaguely remember deleting one or two of the default extensions. Here are notes on my performance testing last year and why I globally UNcheck Scan All Files using ERA:

http://blogs.mcbsys.com/mark/post/Comparing-NOD32-Version-27-to-Version-30.aspx

Another reason to not scan all files is that I use file-based databases. So with Scan all files checked, I have to exclude DBF, DBT, MDX, ADI, ADM, ADT...hope I'm not forgetting any.

BTW of the two machines I use daily, only the XP machine had the issue; the Vista machine did not. I logged on to a couple XP machines at a client site and did not see the issue.

 

Forgot to mention that after checking "Scan all files" and logging in again, I got the following popup which I have never seen before:



That's one of the many drivers for my HP OfficeJet G85xi.

 

I pushed out these installs with the scan all files un-checked per eset support. I'll have to call each user to talk them through it and give them the admin password to uninstall. That will mean they will all have the local admin passwords and none of them will report or update from our servers anymore unless I run them through that setup also. I guess I can create a custom installer and try to figure out how to get it to them. I really don't want users to have the company's eset user name and pw either. These installs are on a lot of small companies. The largest is around 80 clients.

 

I'll try pushing the config out before the user logs in to see if that works. Thanks, Joel

 

I tested pushing out the new config and it says it's finished under the task tab but it didn't change anything.

 

It looks like there is a bug where the configuration only pushes changes that are different from the defaults. If I look at the configuration that was pushed out nothing is listed that was default, only non-default settings are shown.

 

Just received archive module 1100 via the updater - looks like the problem is solved now. Thanks Marcos and ESET for fixing it during the weekend!

Marcos, will ESET take any measures to ensure that problems like these won't occur anymore? Don't get me wrong, I like the product and know that problems can't always be ruled out, but perhaps this bug could have been caught with improved QA procedures.

 

In the ESET Configuration Editor, I think you can click on the Mark button to force it to push out a setting even if it is the default. You should see the little square as solid blue.

 

Confirmed for 3.0 and XP SP3. Virus sig 4297 includes Archive module 1100. Even with Scan all files UNchecked, CPU does not go up.

I have been through a similar issue with another AV vendor a couple months back. They pushed a release that brought most systems to their knees. My request to them and now to ESET: as soon as you become aware of a serious issue, create a status or blog page on your web site with a prominent link from the home and/or support pages. Keep that page updated with the current status: problem description, workarounds, fix ETA, requests for dumps, whatever. It seemed yesterday that even the U.S.-based support staff did not have access to this information. A forum like this is helpful but too obscure for most users to find. Even when users do find the forum, it helps to have a specific support page with official answers to distinguish them from users' forum postings (and support can link to the status page from the forum).

This bug had limited impact because it didn't affect users with the default configuration. Imagine the next time when everyone is knocked out. Make a disaster plan NOW--set up your web pages and links, make sure your site can scale to handle the traffic, write down who will do what and how to reach them, define who has authority to declare the emergency, etc. There will be no time for any of that when a real firestorm hits!

My two cents,

Mark

 

I totally agree with Mark. The problem first appeared for me on Thursday and Friday morning Eset support was still telling me there wasn't a problem as far as they knew. The biggest problem was that even after they knew there was a problem they kept pushing out the bad update. Why not revert back to one that works? Did they want to make sure people who didn't get the update right away had plenty of time to get the bad update? It hit all my several hundred users (minus a few that weren't set that way for some reason) because Eset support told me to change the setting to not scan all files.

 

Not sure why I've always unchecked this but all our computers are configured this way. It's saved us from a few issues in the past like the log file lockup a while back. We've also never run into any problems with it unchecked.

I didn't realise "msi" and "msp" files weren't in the list. I was under the impression the list could be altered by ESET to include new threats.

I love the reaction time of ESET to new threats. Like I said, Friday afternoon for us it was a newly discovered issue. I figured it was someone else's problem, left for the weekend and sure enough, come Monday morning, problem resolved.

Thanks ESET.