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

[Brummelchen]

uninstaller (cleaner) standalone
http://fpdownload.macromedia.com/get/flashplayer/current/uninstall_flash_player.exe

uninstaller in active-x setup
http://fpdownload.macromedia.com/get/flashplayer/current/licensing/win/install_flash_player_10_active_x.exe

anything is ok except i start copying that file (uninstall_activex.exe)
ekrn.exe uses 100% cpu and wont go down again - ffs - i had to restart many times till now.

URL contain actual FP 10.0.32.18 - but it happens on the previous build too now.

[mickhardy]

No problem downloading or running either file with ESS 4.0.437 installed on Win7 Build 7100.

[mickhardy]

Spoke too soon. Experienced the same issue you describe. Still investigating.

Edit: Add an image.

210889

Edit: Reboot hasn't resolved the issue. Nor has removing Flash and reinstalling via the Adobe site.

[Marcos]

No problems here scanning the two files either. What version are you using? (paste here the info about installed modules from Help-> About) Does the same happen when you scan the files with the on-demand scanner or it's just the web scanner that causes this problem?

[mickhardy]

Browsing any Flash enabled web page with web access protection and advanced heuristics enabled along with Flash 10.0.32.18 caused a sustained 50% CPU spike, presumably one core at 100%.

210890

Uninstalling the Flash Player from the normal Control Panel Add/Remove would cause a near 100% sustained CPU spike.

210891

Rebooted, reinstalled Flash Player, rebooted again. Browsed a Flash enabled site and same issue 50% CPU.

Disabled web access protection and killed ekrn.exe. Problem solved. Disabled Advanced Heuristics but enabled web access protection and problem remained resolved.

Now I have both web access protection and advanced heuristics enabled and can't reproduce the problem. It must be something to do with having AH enabled during the installation.

Edit: Added version as per request
210892
Virus signature database: 4292 (20090730)
Update module: 1028 (20090302)
Antivirus and antispyware scanner module: 1229 (20090724)
Advanced heuristics module: 1095 (20090727)
Archive support module: 1099 (20090730)
Cleaner module: 1043 (20090728)
Anti-Stealth support module: 1012 (20090526)
Personal firewall module: 1050 (20090625)
Antispam module: 1011 (20090114)
SysInspector module: 1213 (20090507)
Self-defense support module : 1005 (20081105)

[mickhardy]

This is 100% reproducible on a different box with XP SP3 EAV 4.0.424. Just installed the latest Flash Player from the Adobe site using the standard web update and the CPU spiked at 100% and stayed there.

I'm guessing this is not good and ESET or Adobe have some work to do.

Beer o'clock for me. This is an SEP for sure.:)

[Marcos]

No problems here with Flash enabled websites nor the Flash uninstaller. The best would be if you could create a dump from ekrn (Self-defense must be disabled) and convey it to ESET. Vista allows generation of process dumps from withing the task manager.

[Hydro]

Similar problem here: while downloading the new Flash Player setup ( v10.0.32.18 ) for Opera from http://get.adobe.com/flashplayer/ my ekrn.exe CPU-load jumped to 50% and stayed there. Next I downloaded the Flash Player setup for Internet Explorer and the CPU-load jumped from 50 to 100%. Had to reboot to cure it, but the problem reappeared as soon as I moved the downloaded setups to another folder. Rebooted again, disabled all advanced heuristics and ran install_flash_player.exe, but again ekrn.exe bogged down the CPU...

Running 32-bit DEP-enabled Windows XP SP3 (fully patched) with ESET Smart Security 4.0.437.0, 4293 (same module versions as mickhardy).

If this problem can occur with the latest Flash Player, it might also occur with other files (and malware). ESET, please fix this...

[Brambb]

I cant reproduce this; downloading, copying and installing both flash for IE (activex) and other browsers work fine. There is a spike scanning the files but it stops after a (few) second(s).

Running latest v4 on Vista Ult. x64 system.

[Brummelchen]

reproducable here on winxp sp3
causing: real time protection -> threat sense|configure -> objects -> files

the change has been come since
>> Macromedia FlashPlayer 10.0.22.87
and
>> Macromedia FlashPlayer 10.0.32.18

Februar till now *puppy*

[AlunS]

I started having the same problems yesterday also with 4.0.437 for the very first time. I was updating a bunch of apps (npp, filezilla, ccleaner, defraggler, cdburnerxp and a few others) from installers downloaded from FileHippo.com and the first time I ran an installer CPU usage went up to 50% and running the next one it went up to 100%. Only way to stop it was a reboot. 4.0.437 has been on here for a while (XP +SP3) but this is the first time I've had a problem like this.

[Marcos]

We'd highly appreciate if you could try installing the previous archive module to confirm or deny possible connection with yesterday's archive module update. You can install it as follows:
1, disable automatic update tasks so that the archive module will not be updated automatically during testing
2, download the previous version of the archive module from here (ftp://ftp.nod.sk/support/archm1098/em003_32.dat) and save it to the disk
3, restart Windows and start it in safe mode
4, backup the current file em003_32.dat in the ESET installation folder (e.g. by renaming it to em003_32.bak) and copy the downloaded build 1098 instead.
5, restart Windows
6, verify that you have the archive module build 1098 installed (Help->About) and try to replicate the problem

Please let us know if installing the previous archive module build makes a difference or not. We'd need to determine if the problem is actually with the latest archive module or there's something wrong with yesterday's update of the Flash player. When you manage to replicate the problem, generate a complete memory dump per the instructions here (http://kb.eset.com/esetkb/index?page=content&id=SOLN380&actp=search&viewlocale=en_US&searchid=1249057413481) and convey it to customer care along with a description of the problem.

Remember to enable automatic update tasks after you finish testing.

[Hydro]

Marcos, using the previous archive module ( 1098 ) the problem doesn't occur here, even with advanced heuristics enabled. So it looks like the problem was introduced in archive module 1099.

Is there a way we can keep archive module 1098 and still enable updates, until a solution has been found? If module 1099 doesn't handle certain input properly, this problem might not only be inconvenient but also a possible attack vector for malware.

[Brummelchen]

inbetween the spiking occurs on some more events - also on my own compiled files and the new from 2day.
-{ Quote: "You don't have permission to access /support/archm1098/em003_32.dat on this server." }-
Firefox couldnt load it - needed DLM.
After copying & restarting gui&krn i started the setup again. all fine - my files also.

what should we do now?

btw thx for your fast help.

[Marcos]

-{ Quote: "Marcos, using the previous archive module ( 1098 ) the problem doesn't occur here, even with advanced heuristics enabled. So it looks like the problem was introduced in archive module 1099.
" }-

Hi Hydro,
thanks for testing it. Would it be possible for you to generate a complete memory dump and convey it to us? It's a really odd issue as we've tried everything to reproduce this problem with the latest build of the Flash player and archive module on various systems to no avail. It doesn't seem to affect every system configuration, for instance, we haven't got a single report of it here in Slovakia, just one report from the Czech republic and a few others from our distributors. If there was a general problem in the past we received a huge number of reports shortly after the release an erroneous update. Of course, here at Wilders there are more reports of it as people usually come to visit forums to seek a solution when they run into a trouble. I can assure you that we'll do our best to investigate it and make a fix as soon as possible, but we need your assistance. A process dump of ekrn.exe or complete memory dump from the moment when the problem occurs is now the only thing that can help us determine the cause of the problem. Before you create one, make sure to disable Self-defense and restart the computer.

For instructions how to create a process dump, read the following articles:
Windows XP: http://support.microsoft.com/kb/241215
Vista: http://support.microsoft.com/kb/931673

[Hydro]

Wasn't easy to get a successful memory dump of ekrn.exe with the real-time monitor enabled. Even after disabling self-defense + anti-stealth and excluding the kktools folder, userdump.exe froze or couldn't dump ekrn.exe, or the original problem didn't occur anymore (although 4 out of 5 times it did).

Finally succeeded by excluding drive C from the real-time monitor and opening the Flash Player installer on drive D, causing a continuous 100% CPU-load. During the subsequent dump, ekrn.exe CPU-load dropped from 100 to 0% and stalled the dump process (but the dump file appeared to have been completed already, sized approx 100 MB). Had to terminate ekrn.exe for the userdump to finish.

Marcos, I've uploaded the dump to a server and mailed the url to support@eset.sk.

[Hydro]

Did some more testing and noticed that the problem is very hard to reproduce when the real-time scanner is set to "Scan all files", which I think is the default setting. Previously I had disabled that setting and used the default extensions (and added MSI + MSP to the list, but this doesn't appear to be the cause of the problem). Using the default extension list, the problem is very easy to reproduce here: just viewing the properties of install_flash_player.exe is enough in most cases. Same issue with the on-demand scanner: it only seems to cause problems when the extension list is used.

Now I'm wondering: when setting "Scan all files" is enabled, are some files actually skipped or scanned differently from when the extension list is used?

During my tests, at one point, ekrn.exe (using archive module 1099) was consuming 100% CPU and 1.5 GB RAM, and eating another 50+ MB RAM each second... there's a nasty bug somewhere.

[Brambb]

Confirmed.

I also have 50% CPU load with ekrn.exe after disabling 'scan all files' in the ThreathSense settings in the real-time scanner. After reboot I enabled it again and it didn't happen, after disabling it once more it happened again.

Copied two flash install files from one folder to another. After one file 25% CPU, after the second 50% CPU. (have 4 cores)

[MarcR]

Same problem on 2 workstations with Ver. 3.0.684

[rtt_77388]

Hi
I am experiancing the same issue. I have eset smart security 4.0.437.0 and have installed adobe flash ver 10.0.32.18. I am running on a Vista Home Premium 64 bit platform. A few minutes after boot up, the windows process monitor shows ekrn.exe at 100% utilization. I have also posted a support ticket with eset.
Tim

[Demente1982]

Hydro is rigth.. enable "scan all files" on real time proteccion not lock the computer. Also has a problem with Thunderbird so i have to put that folder in exclusion. I waiting for a comunicate from ESET because i have 1000 pcs and a good part of them locked.

[Marcos]

-{ Quote: "Did some more testing and noticed that the problem is very hard to reproduce when the real-time scanner is set to "Scan all files", which I think is the default setting. Previously I had disabled that setting and used the default extensions (and added MSI + MSP to the list, but this doesn't appear to be the cause of the problem). Using the default extension list, the problem is very easy to reproduce here: just viewing the properties of install_flash_player.exe is enough in most cases. Same issue with the on-demand scanner: it only seems to cause problems when the extension list is used.
" }-

Thank you for finding that out, I've managed to reproduce the issue with "Scan all files" disabled in the real-time protection setup. I'm about to create a process dump and convey it to our developers who will analyze it immediately. When a fix is ready, I'll let you know. In the mean time, could everybody having this issue confirm or deny that the problem doesn't occur when all files are scanned?

[Brambb]

Confirmed as I replied earlier, tried making a process dump twice but that took so long and I still had stuff to do so I aborted it. Was planning to let it go on tonight for the dump to complete, but I guess that ain't of use anymore?

[sd_mark]

I am also seeing high CPU but under different circumstances. I started a thread (http://www.wilderssecurity.com/showthread.php?t=249637&highlight=1099) on this but was directed here.

If I understand correctly, the issue in this thread pertains to NOD32 version 4 and the Flash player/installer.

I am experiencing the issue with NOD32 version 3.0.684. All I have to do is log on to the XP SP3 computer and the CPU goes up to 97% and stays there. It is possible that a Flash Player auto-update is attempting to run in the background--I saw and declined a Flash update prompt, I think while NOD32 was disabled.

All my machines run with Real-time file system protection > Setup > Extensions > Scan All Files UNchecked. I can confirm that after checking Scan All Files (and rebooting) that the CPU did NOT go up. I can also confirm that dowgrading to Archive support module 1098 solves the problem.

Mark

[Marcos]

The problem should only occur with scanning all files disabled (enabled by default) and only if certain NSIS installers are scanned. Please enable the "Scan all files" option (enabled by default) in the Setup - Antivirus and Antispyware -> Real-time file system protection -> Threatsense engine parameter setup -> Extensions -> Scan all files.

Those who have been using default settings are not affected even if NSIS installers are scanned. A fix to this issue is being worked on and will be distributed to all users automatically later today. Thank you all who have contributed and helped us pinpoint the issue. My special thanks go to Hydro who found the setting which caused the issue to appear/disappear and navigated us in the right direction.

[joelsplace]

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.

[sd_mark]

-{ Quote: "...only if certain NSIS installers are scanned." }-
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?

[Marcos]

-{ Quote: "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." }-

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 (http://kb.eset.com/esetkb/index?page=content&id=SOLN2289&actp=search&viewlocale=en_US&searchid=1249155770117) article

[Marcos]

-{ Quote: "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?" }-

Right.

[sd_mark]

-{ Quote: "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." }-
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

[Marcos]

-{ Quote: "In my test the high CPU didn't start until I logged on to the machine. " }-

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?

[sd_mark]

-{ Quote: "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.

[sd_mark]

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

210941

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

[joelsplace]

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.

[joelsplace]

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

[joelsplace]

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

[joelsplace]

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.

[Hydro]

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.

[sd_mark]

-{ Quote: "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." }-
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.

210946

[sd_mark]

-{ Quote: "Just received archive module 1100 via the updater - looks like the problem is solved now." }-
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

[joelsplace]

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.

[mickhardy]

-{ Quote: "...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. :thumb: