howardagoldberg

Any update on an ETA when this issue will be resolved? The "error" message displayed again this morning (Monday, 10/26 6:30 a.m. Eastern U.S.) on boot. (Icon was green, main GUI showed "fully protected." Please advise. Thanks!

Fantastic! So, I was correct in that it was a "timing issue?" ;-)

Will this be a module update (like HIPS), or a full-blown program update/upgrade? In other words, will we get the fix automatically? In the interim, is there any security risk? Timeframe for getting the fix?

I am encountering the exact same issue. I have installed version 9 on the following systems: 2 Win7 (SP-1) x64 1 Win 8.1 x32 1 Win 8.1 x64 The two Win7 systems are (almost) identically configured software-wise. One is a Dell desktop (OptiPlex 755), the other a Dell XPS15 (L501X). The issue only has manifested itself on the XPS15 laptop. Since upgrading to v9 (last Tuesday, the day it was released), I have probably rebooted at least a dozen times (I normally shut down completely at night, and have rebooted several times for updates, etc.). Twice, only on the XPS15, upon a fresh boot -- the error message below has appeared. So, it's not every boot, and seems random. Further, when I then open the ESET main window while the error message is still visible in the pop up window -- the main ESET interface shows I AM completely protected (no red or orange "warnings," just a green check mark), and the protocol filtering is turned on and shows no signs of not being active. Also, the icon in the task tray has not had a red exclamation point or otherwise been displayed as anything other than then the normal (all systems go) ESET icon. On both occasions where I have seen this message, I have rebooted the computer -- and the message has not reoccurred upon reboot. Based on this behavior, I am guessing that it's a "timing" issue. In other words, ESET is checking to make sure the feature is working correctly, but has not completely entered into memory yet, gets a "did not load" message, but then subsequently loads successfully. But, anything more you can provide (including a fix!) would be appreciated, as any errors with security software make me nervous ;-). Thanks! P.S. As this may be relevant ... On all of my systems, I have Office 2013 installed. But, only on the XPS15, is Outlook 2013 configured and active. (I have never even run Outlook on the other systems.) Also, I have the check-boxes ticked off for all the email client integration options, even though the only email client installed on all these systems is Outlook 2013 (32-bit version of Office on all systems).

... an update: Now, the computer that was on 1173B.3 just received module version 1173.6. The other system is still on 1173.5. Same network. Same desk! Can someone advise as to what is going on here?

I am running ESET NOD32 Anti-Virus on multiple systems: Win7 SP1 x64 Win 8.1 x32 Win 8.1 x64 A few weeks ago, I noticed that the Internet Protection Module was updated from 1173B.1 to 1180 (or 118x, I don't remember the exact number). Shortly thereafter, the module was "downgraded" to 1173B.3. Now, on one Win7 system, the module was upgraded to 1173.5 (no B), but all the other systems are still at 1173B.3. Can someone please advise as to what is taking place, and what the issue is? Thank you.

The update from 8.0.301 to 8.0.304. I am using the U.S. English version, and upgraded to 8.0.301 the day it came out a few weeks back. What is new in .304? There is no change log on the ESET download page.

I see that the full offline install file has been updated to version 8.0.304. But there is no change log on the download page (and it is not available via the in-program update function). What is new and should users update?

Will this fix the pingtest.net issue also? You can try with IPM 1150B by enabling pre-release updates and let us know if it works properly. hxxp://kb.eset.com/esetkb/index?page=content&id=SOLN3415&actp=search&viewlocale=en_US&searchid=1412796137155 After you have updated as instructed in the KB article you can right-click on your systray ESET icon "e" and click "About" then look up the "Internet Protection Module" to see if you now have 1150B. 1150B came through with the latest VSD auto update -- and yes, it resolved the issue with pingtest.net. :-)

Will this fix the pingtest.net issue also?

I am not having any issues with speedtest.net ... However since upgrading to V8 ... pingtest.net does not work at all. It could be an issue at their end (in other words a coincidence), but I am curious to know if anyone else is having issues with this other Ookla service. Pingtest.net chooses a server, and then I get a message that either a firewall is blocking access or there may be an issue with the pingtest server. However, the issue has been ongoing since my upgrade to V8.

The situation is not getting better from this user's perspective. 10:30 a.m. (East coast, U.S.), and the issue remains. Would someone please explain what kind of update is causing this? For security software (which I mostly love), it is not acceptable that the user should need to remember to manually update 4-6 times a day. I think we are in need of a bit more information as to why this happened.

As of 6:00 a.m. Eastern time (U.S.), the issue remains. On all my Windows systems running NOD32 (Anti-Virus) ... had to click manually "update now" about a dozen times. Auto update still not "working." When can we expect the issue to resolve to I can stop checking for updates every 2 hours?

What larger update? Sorry, but this has been going on for at least 10 hours now. If I had not noticed the issue, my signatures would have been way out of date. Can we have a more detailed explanation?

Nope ... if you have a bunch of definitions/modules to update all at once, 11-12MB is perfectly normal :-)

I am running ESET NOD32 Anti-Virus (not Smart Security) version 7.0.317.4. Same issue on two computers running Win7x64 SP1 Ultimate. The solution -- although not a good one, is to keep hitting the "update now" button in the settings "update tab." I have had to hit the button upwards of 10 times in order to trigger an update (and not get the "you are already up to date" message). Given that I am also having the issue -- and on two different systems, my guess is that something is timing out at ESET's update server end. The fact that I occasionally get through manually, provides some anecdotal evidence of that. Hopefully it will be corrected soon. When booting up this morning, I believe I was on 10434. I was able to get it up to 10437 using the "method" described above. When I noticed just a few minutes ago that the signature was up to 10439, I went through the manual click fest again, and both computers are now up to date. Of course, having to watch hxxp://www.virusradar.com/en/update/info is not a good solution. ;-) To ESET folks out there: Yes, on one system, I cleared the update cache. That did *not* resolve the issue. The only thing that works is repeatedly hitting "update now" until the connection takes.

I never said that Windows Updated installed WinZip, of course that is ludicrous. I installed WinZip from WinZip's website (pro/paid version FWIW). What I did say -- is that I have had both ESET and WinZip on my system for years; and now, for no apparent reason, ESET is suddenly detecting an installed file (and not a newly installed file, mind you -- or a file that has actually been run) as a PUA. Therefore, something did change in a module that is causing ESET to flag a specific file in one of the WinZip directories (see my above note) during normal background scanning operations. What I inferred, based on this thread, is that there may be something going on with ESET that is causing it to be slightly more aggressive than it had been before last week in terms of PUAs -- if indeed ESET is flagging MSI files that are being downloaded with Windows Update.

Steve, I am not an expert in these areas (although, fairly well versed/experienced). I cannot say for certain, but I find it *highly* unlikely that Microsoft is distributing software via Windows Update (which employs a robust framework in terms of security) that should qualify as a PUA, potentially dangerous application, or outright malware. I would personally feel a bit more comfortable/validated to hear something back from ESET that explains the reason as to why the file in question is now suddenly flagged as a PUA, but I can only assume it is something to do with a subtle change in the detection logic. Be well, Howie

I have a feeling that the PUA scanning has gotten somewhat more agressive in the past few days. I just sent the following to ESET: Attached is the file WINZIPSSREGCLEAN.EXE, which is installed as part of WinZip 18.5 Pro. This file has been on my system since at least May 2, 2014 (and earlier versions of this file prior to that) and ESET has never detected the file as a threat until the past few days (a few samples of the detection logs are below). At first, I told NOD32 to take no action, but the detection reoccurred last evening. So, last evening, as an experiment, I had the file quarantined, and then restored the file. I tried submitting to VirusTotal, but ESET prevented that action. This morning, I restored the file and told ESET to ignore the file going forward, and did submit to VirusTotal (https://www.virustotal.com/en/file/02eca452990031039cf949c2856fe0335482c0f4eb6b6a5aebadc69db0022976/analysis/1409495907/). Only ESET flagged the file as a potential threat. Of course, that does not mean it is not a threat … but given that it appears a recent module update is a likely culprit, I do suspect a false positive. When scanning the rest of the “Utils\WzSysScan” folder, ESET did not flag any other files. Please advise as soon as possible as to whether you believe this file is an actual threat. Just FYI … I have never actually run this application. It comes as part of WinZip, but I do not use WinZip’s system cleaning/tuning tools. I have also submitted this file twice via the NOD32 interface. (As a side note … ESET has on occasion detected the WinZip-64 MSI executable/install file as a PUP when downloading from WinZip’s site in the past – see example below, but did not flag this specific file during or after the actual install process.) Thank you for your attention to this matter. As of 8/31/2014 11:12 a.m. Eastern (U.S.) time: Virus signature database: 10343 (20140831) Rapid Response module: 4663 (20140831) Update module: 1051 (20140409) Antivirus and antispyware scanner module: 1435 (20140820) Advanced heuristics module: 1152 (20140724) Archive support module: 1208 (20140728) Cleaner module: 1099 (20140811) Anti-Stealth support module: 1060 (20140514) ESET SysInspector module: 1241 (20140410) Real-time file system protection module: 1006 (20110921) Translation support module: 1232 (20140624) HIPS support module: 1144 (20140825) Internet protection module: 1140 (20140806) Database module: 1060 (20140714) *** 08/27/2014 6:29:15 PM Real-time file system protection first detection, I can only assume this occurred during a regular auto background scan after an ESET auto definition/module update, as I have never actually run the program and no WinZip utilities are set to run automatically File C:\Program Files\WinZip\Utils\WzSysScan\WINZIPSSRegClean.exe probably a variant of Win32/Systweak potentially unwanted application Event occurred during an attempt to run the file by the application: C:\Windows\System32\rundll32.exe. There were 8 subsequent detections noted in the NOD32 log through August 29. My system was turning off from late evening August 29 through early evening August 30. Next detection that was not triggered by my actions (below) was just after midnight today (August 31.) 08/27/2014 6:34:42 PM example of an attempt to download WinZip from WinZip website Document protection File hxxp://download.winzip.com/winzip185-64.msi probably a variant of Win32/Systweak potentially unwanted application 08/31/2014 12:51:10 AM Real-time file system protection when trying to upload to VirusTotal File C:\Program Files\WinZip\Utils\WzSysScan\WINZIPSSREGCLEAN.EXE probably a variant of Win32/Systweak potentially unwanted application cleaned by deleting (after the next restart) – quarantined Event occurred during an attempt to access the file by the application: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe 08/31/2014 12:49:17 AM Real-time file system protection when trying to upload to VirusTotal File C:\Program Files\WinZip\Utils\WzSysScan\WINZIPSSREGCLEAN.EXE probably a variant of Win32/Systweak potentially unwanted application Event occurred during an attempt to run the file by the application: C:\Windows\explorer.exe. ESET responded saying that the file in question is in fact a PUA, and it is not a false detection. BUT, given that I have had WinZip, including this file in question, and ESET on my system for a significant amount of time (years, in fact) -- and the only thing that changed in this regard is ESET signature/module updates, it seems likely that something in ESET's detection sensitivity/blacklist has changed recently. I wonder if something similar is happening at your end? It is doubtful that a Windows Update would contain a PUA!

Same issue again ... one computer updated to HIPS module 1133, the other 1131. This is the first time since the differential noted in this post. All other modules are "equal." Any explanation as to why one computer on the same network is getting a different HIPS module earlier than the other? (No BSOD this time ... but on the system with 1133, the log indicates a "program modules updated" this morning, the other computer has no such entry.)

Marcos, Again thank you. That definitely eases my mind :-) It is just a bit unprecedented, if you will -- since the two computers in question are literally sitting next to each other on a desk, plugged in to the same router, etc ... and all the other modules match up. But if you say it's "normal," that's good enough for me.

Marcos, Thank you for your quick reply and offer of assistance. Unfortunately, I have already deleted the memory dump log after not being able to identify a direct/reproducible cause of the BSOD. If the event happens again, I will upload the log so that you can review it. I just booted up both systems this morning (8:30 a.m. Eastern/U.S.), and the "issue" remains. All the signatures/modules are the same on both systems ... Virus signature database: 9498 (20140304) Rapid Response module: 3770 (20140304) Update module: 1047 (20131023) Antivirus and antispyware scanner module: 1421 (20140219) Advanced heuristics module: 1147 (20140114) Archive support module: 1191 (20140210) Cleaner module: 1084 (20140224) Anti-Stealth support module: 1057 (20131125) ESET SysInspector module: 1240 (20131202) Real-time file system protection module: 1006 (20110921) Translation support module: 1145 (20131121) HIPS support module: 1115 (20140206) Internet protection module: 1108 (20140224) Database module: 1054 (20140218) ... except HIPS which is at 1119 on the other system. It seems that on both systems, ESET is updating itself normally otherwise. So to make certain I understand your response: 1) The fact that one system is at 1115 for HIPS and the other is at 1119 for HIPS is nothing to be concerned about and no action should be/needs to be taken? 2) This is the first time that I have seen a difference in modules between the two systems. Is 1119 being rolled out slowly for some reason? Why would two systems with very similar configurations (almost identical, software-wise), on the same network (plugged in to the same router) have different HIPS modules? I just want to make certain that I am fully protected on both systems and that the behavior here is not outside the realm of normal. Thank you again!

I have two computers running: Windows 7 x64 SP1 and ESET NOD32 Anti-Virus 7.0.302.26 This morning (about 13 hours ago), one system BSOD: The computer has rebooted from a bugcheck. The bugcheck was: 0x00000050 (0xfffffa80087d6ca2, 0x0000000000000000, 0xfffff880029c8f29, 0x0000000000000000). A dump was saved in: C:\Windows\MEMORY.DMP. Report Id: 030314-25989-01. After doing some research on this type of error (hxxp://msdn.microsoft.com/en-us/library/windows/hardware/ff559023(v=vs.85).aspx), I have decided (for the moment) this is probably a "one-time" event -- as this is the first BSOD on this system that I can recall in at least several years, and the error has not reoccurred in over 12 hours. (The error occurred while using Skype, if that makes any difference ... and I used Skype frequently afterwards without issue.) But ... here's the issue which I don't know if it is related to the above. On both systems, the modules are the same (as of 10:30 p.m. Eastern/U.S.) ... Virus signature database: 9496 (20140303) Rapid Response module: 3767 (20140303) Update module: 1047 (20131023) Antivirus and antispyware scanner module: 1421 (20140219) Advanced heuristics module: 1147 (20140114) Archive support module: 1191 (20140210) Cleaner module: 1084 (20140224) Anti-Stealth support module: 1057 (20131125) ESET SysInspector module: 1240 (20131202) Real-time file system protection module: 1006 (20110921) Translation support module: 1145 (20131121) HIPS support module: 1115 (20140206) Internet protection module: 1108 (20140224) Database module: 1054 (20140218) ... except on the system that BSODed ... the HIPS support module is now 1119 (20140227) On both systems NOD32 is set for "regular updates," not "pre-release updates" Can anyone confirm whether 1115 or 1119 is the current HIPS module? Did one of my computer's inadvertently pull down a pre-release module or has one computer not updated to the latest HIPS module? In either case, how can I resolve the issue? Thanks for any insights!

System: Dell OptiPlex 755 Windows 7 SP1 x64 ESET NOD 32 AV x64 7.0.302.26 This morning, I booted my computer and everything seemed to be normal. About 5 minutes after logging on, an audible "ding" sounded from the system with the ESET error message "Error communicating with kernel." I clicked OK on the dialogue box, and Windows offered me the option to "allow the program to run" or not. I allowed. Tried to restart ESET, the "Error communicating with kernel" error popped up again, this time immediately. Clicked OK again, Windows again offered to safelist the program, which I did. At this point, I did not try to reload ESET. I rebooted the computer and everything seems to be operating normally. No error messages, EICAR test passed, manual scanning working normally, virus definitions are automatically updating and are current. There are no log entries in ESET indicating that there was an issue. Windows event viewer logged the following (upon the first boot when the error occurred): 1) Error: A timeout was reached (3000 milliseconds) while waiting for the ESET Service service to connect 2) Error: The ESET Service service failed to start due to the following error: The service did not respond to the start or control request in a timely fashion Both errors are timestampled 07:33:09 Eastern Before the first error dialogue appeared, the only thing I had done with the system was log on. No programs launched, etc. The only thing I can determine is that, potentially, something went wrong during a definition update (my other system had a slightly newer definition when booting up just a few minutes later). Again, upon rebooting the system -- everything seems fine. Please advise so as to avoid a future occurrence. Thank you.

... so, is it a problem if we did install .26? Still, 20MB for EULA smells funny. The full file is around 70MB. The update is 20MB. That cannot simply be EULA ... especially since there were no new modules installed via the update.