New version 3.0.621 available

I signed up for 2 more years with NOD32 just before they released v3. Like you I installed, updated, uninstalled and went back to v2.7 twice before leaving it on v2.7. I see no reason to defect to a different company when v2.7 is just fine. I dare say it will be supported at least until my 2 year subscription runs out. In the mean time I would like to think that v3 will get its act together before then.

 

In a lot of ways Eset very much got there "act together" on this version. However, it is also true that there are still a very small number of minor\major concerns still to be resolved.

Bubba

 

I have used NOD a long time. With ver. 3 I haven't had any problems that I can say that NOD caused it. I have seen a lot of people posting problems they are having. I have had several BSOD's which I had never had before. But because I am also running Comodo Ver.3 I can't say which is the problem. 621 has been running a month now and it seems ESET would have put out a new build by now.

 

I'm trying the NOD32 ver 3.0.621.0 out on my wife, daughter and my computer at work. All different configurations, and no problems, nada, zip, clean.. on all of them. I dare say, had I not "just" purchased a 1 year subscription to Avast Pro 4.7, I probably would have installed and registered the NOD32 on my computer as well. It (NOD32) found 16 infiltrations to my daughters computer that has been running Avast AVG Anti Malware and also Webroot Spysweeper at the same time. They went by-by!

 

I'm sorry, but there's nothing very small about the concerns that have to be resolved. The ones I've seen are universal to those of us running the software in certain intensive computing environments. The official stance of the company -- through tech support and through two enterprise level vendors -- is to NOT install version 3.x in a production environment.

The issues I've seen can be dealt with on workstation type systems. They cannot be dealt with on many Windows Servers -- especially those which must run SQL Server or those which must provide file sharing via DFS.

Eset does not have their act together on this matter. The merest testing on anything but the simplest server environment would have told them that this software was not ready for release to be used in a corporate / production environment. I have created four different test environments specifically for testing the new EAV version, and the antivirus software causes serious issues in all of them. These environments consist solely of Windows 2000 or 2003 with all service packs and patches and configuration to act as members of DFS and / or SQL Server systems. No other software is installed on them, and they are configured as simply as possible.

I'm very much afraid that the problems we are seeing stem from a basic error in design, one which will be very difficult to fix. Eset may eventually get the "drivers" fixed so that the software doesn't cause bottlenecks in system I/O or communications, but the new design itself is not a good one -- at least not to my way of thinking. If Eset can make the design work, they will have accomplished something that no one else has managed, and I will be happy for them.

But too many of Eset's competitors have gone down this same road -- employing a design which interferes significantly in the way the operating system accomplishes communications. Those who write AV software have got to stop trying to make alterations in basic operating system functionality. This software needs to cooperate with the OS -- not to try to grab the OS by the throat and subdue it.

Something that troubles me as much as this design and functionality issue is the lack of responsiveness of Eset's tech support in this whole matter. I have waited more than a week each time I have written them. The last time they responded to one of my e-mails their response proved that they hadn't even been reading the information I had sent them. That's just not acceptable. (If I were just a bit more annoyed I would do something very rude by posting the entirety of that e-mail message thread with Eset to prove my point.)

To those of you who are running EAV 3.x on simple workstation configurations on personal and even business systems, you probably won't see anything much amiss unless you run into something like one of the problems the software has dealing with compressed data from certain types of Web sites (anandtech.com comes to mind) or one of the numerous posted issues having to do with certain e-mail clients. There's no reason for you to be very upset, and I imagine that the storm of controversy brewing amongst people who try to use this software on servers may seem pretty remote to you. But I assure you that there are very real problems for some of us.

To date I know of no one who has been able to configure the 3.x version of EAV on a domain controller (Active Directory environment) that runs SQL Server or which acts as a member of a Distributed File System without causing said server to fail. These are VERY common server configurations out here in the corporate world, and the software should have been tested sufficiently before release to avoid these problems.

It doesn't help my state of mind that I switched my company's production domain to Eset's software because of the new administrative features in version 3.x -- features which aren't nearly as useful in the 2.7 version. But I can't make use of the new admin features because I can't install the software on my server systems without crippling them.

 

Crooked Bloke, when you mentioned "dealing with compressed" data, it got me thinking about something. We have seen on here people ask for what OS they are running, but no one asks what "File System" they are running. There are 32 and 64 bit flavors of Windows, and withing that there are those that run FAT32 like I do on 1 Hard drive(C & D) and NTFS (which I have on 2 of the other drives. Then there comes to mind that you can compress files/folders to save space. The variables from one machine to another really make it difficult to nail down any specific cause of problems.

I agree, that workstations are probably the least affected, but when you look at servers, that is a whole new 'ball of wax' in itself. So now I wonder if there are these issues cropping up in workstations that have compressed files/folders and or NTFS systems running?

 

I'm with CrookedBloke on this one. EAV 3.0 is simply not suitable for use on servers. I have tested it on SBS2003 and WS2003 installations that are not running SQL Server or DFS, with pretty poor results. DNS problems, workstation connectivity problems, server performance problems all result.

Admittedly, EAV3 seems more or less fine on many workstations (though there are some it affects awfully, performance wise), and the latest Remote Administrator seems not to affect servers adversely, though here it appears also that it has not been anywhere near sufficiently tested and debugged. There are all sorts of settings the RA is unable to push out to clients.

Like CrookedBloke I consider the architectural changes made in the EAV3 products to be the prime cause of its problems, and if we are right then Eset are in real trouble, as they will lose the whole server market. Trust is imperative, and sysadmins/network admins have long memories.

If Eset at least engaged with their (potential) customers, it might go some way to ease the fears. That, they have failed to do. I have attempted to report all sorts of problems to Eset UK, but one too many less-than-helpful "it doesn't happen here" responses have put a stop to that. I have no inclination to assist them further.

 

I'm also with a few people here. V3 has caused problems on our network, namely Windows 2000 Pro/Server where it fails to load correctly so i need to reinstall them. Domain Controller Problems with Windows 2003 64bit where using folder redirect onto the server when clients copy large amount of data (by this i mean anything 200MB+) caused the server to lock up, when Nod was removed all went fine but it back on and again lockup. So i had to exclude the profiles folder from being scanned.

All i see are bugs and problems being posted on an offical support forum but yet have not seen an offical notice from Eset to acknowledge the problem or if the latest build will fix any of these errors.

 

Darth AkSarBen:

Nothing I have seen would lead me to believe that EAV 3.x has a problem with any local file system used by Windows, or with compressed data written on such file systems. Rather, what I'm talking about is compressed data streams from certain types of Web sites. For instance, I found that EAV 3.0.621.0 would simply not allow me to visit anandtech.com. As soon as I replaced that version with 2.70.39, the site loaded instantly.

spm:

I'm so frustrated about this right now because I'm the victim of a "perfect storm" of coincidences.

First of all, normally I would NEVER stick a new version of ANYTHING right on to critical systems on a production network. But, in this case, we were using Symantec AV Corporate Edition (company-wide license) when our most heavily used production server just started rebooting spontaneously. I analyzed the crash dump and found that SAV was the cause. Removed it, and the problem went away.

I installed 2.70.39 in a desperate attempt to cover the server, and found that I could run an in-depth scan with all the bells & whistles enabled during production without any noticeable impact whatsoever on the system. I was amazed! The product was definitely weak from the standpoint of remote admin features, however.

Then I read about the improved admin features on version 3 and jumped at the chance to purchase licensing for the whole darned domain. I knew that neither Trend nor McAfee nor SAV nor Sophos was going to work on these servers, considering the way they are hammered.

Well, then I installed version 3. Talk about a burst bubble! Rats! I had used NOD32 on my personal systems for years, and never saw anything like this. I thought that Eset was a company that "got it" -- a company that understood that an antivirus software which causes more disruption than the malware from which it's supposed to protect us was not a good thing.

When I started reading about certain of the technical features of the antivirus scanner itself (proxy, in particular) the hair stood up on the back of my neck. The experience with servers just gradually becoming non-responsive after installation confirmed my gut feeling. I might as well have stayed with SAV. At least then the servers would reboot and become operational again. With EAV 3.x, they just slide into a coma and stay there. I actually have to perform a forced hard shutdown to get them out of the lethargic state!

I sent Eset complete system information on one of my servers, then used Wireshark to collect data for the Eset development team. I never really received any confirmation from them that they had received the data, until I received the most recent insulting e-mail message.

That message proved that they had received the data, because the data was contained (quoted) below their message. But their message was asking me a question about my first message (in which I reported Event ID 6004 errors). They wanted to know if I had seen anything else besides those errors. WTH? The subsequent messages from me in this same message thread contain details about antivirus protection not loaded messages and inability to get automatic updates (both fixed, at least temporarily, by uninstall / reinstall) and servers becoming unresponsive (not fixed by ANYTHING).

It's almost as though they're not even going through the motions -- or like they are married to the new design and are trying desperately to rewrite the miniport (for want of a better word) driver to fix the issues. I'm thinking they need to scrap it and start over. No one else has impressed me with this type of antivirus software. So far, Eset has failed just as miserably as everyone else -- at least with me.

hobbit666:

The only "exclusion" that would allow EAV 3.x to run on my servers without bringing them to their knees was to turn off the antivirus. (Want to hear something funny? SAV would cause these servers to reboot even when it was TURNED OFF! The thought still tickles me. Sort of.)

I experimented with 2.70.39 and found that I didn't actually have to exclude ANYTHING -- not even the usual MS-recommended SQL exclusions -- in order for it to work perfectly on these systems. The difference between 2.7 and 3.x, so far, is night-and-day.

But, as I said, 2.70.39 fails me on the admin side. I'll just have to learn to deal with it, because 3.x isn't going back on to any of these systems until I've seen a RDGE (really d*mned good explanation) from Eset, along with solid assurances that 3.x is fixed. I ain't holding my breath.

And, next year at license renewal time, I guess I'll be in the market again. I certainly wish I knew of some company out there that really gets it.

What I want is antivirus software that's there to help me catch something -- just in case. I've never had downtime on this network (not even on a single workstation) for malware. But I've had a lot of downtime recently because of badly written antivirus software.

 

For me, the bottom line is this ...

With version 2.7 of NOD32, Eset had a winner. It ran light, it was reliable and it did the job. It was pretty much universally praised for these features. So, to move the product along, you would think that Eset would choose to (1) build on the product's strengths, and (2) address its weaknesses. The main weakness that NOD32 2.7 is observed to have is its user interface and, in some peoples' opinions, its remote admin features. Fine, so develop and release a new evolutionary version addressing these perceived weaknesses, but preserve the product's strengths.

But what do Eset actually do? They revolutionise the product by completely overhauling its architecture. They completely redesign the way the product interacts with the operating system (now we have the 'local proxy'). I have to say that, to me, the idea of integrating with servers by using a local proxy is complete madness, and represents a lack of understanding of what servers are all about. This was not a bold decision, but a foolhardy one. So, if they stop to think about things now, can Eset really be surprised that they have blundered?

 

CrookedBloke, we have a saying where I grew up (western Nebraska) "If it ain't broke, don't fix it!". If the 2.70.39 version works, but with just a bit of administrative work, it sound like a much better solution.

What appears as one antivirus for all solutions now looks like it may only be best served on a workstation platform.... at least for the time being.

 

That's it, exactly. I switched from a company noted for ponderous products (Symantec) to a company noted for agile, efficacious products. And got --

ponderous software that kills my servers.

Nice job, design team.

 

Ponderous and efficacious, eh? And I thought they were merely cumbersome and puissant

 

Except that it's not "just a bit" of admin work. The 2.70.39 version's remote admin functionality falls very far short of what most people in my position require. That's why I hadn't already switched to NOD32 years ago. I already knew that it worked just fine on individual workstations. But that's not what I'm dealing with at work. I'm dealing with a system which translates and distributes huge quantities of data to systems which actually operate production lines in a factory. The techniques that would work reasonably well for controlling a small bunch of desktop clients that do e-mail and office type applications won't work on systems that you can't reboot without stopping production lines that run 24/7.

I was forced to go ahead and find SOMETHING when SAV CE started failing on us. I intended to use NOD32 temporarily on the servers until I could find something with decent admin features. Then Eset announced 3.x, and I was ecstatic to see the new admin features.

And then I tried it. Ugh.

Frankly, I've been screwed by the poor design choices of a company that I had learned to trust over the years. I really don't understand why Eset, which stood out amongst the purveyors of this type of software, felt they had to jump on the "me too" train and produce just another invasive, slow, buggy piece of crudware.

If they can fix it at this point, my hat will be off to them. I may even use it if I can't find something lighter. But I'll still think they (and their customers) would have been better off going in another direction.

 

Bwahahahaha!

Thanks, I needed a laugh today.

 

I run it on a Windows 2000 Advanced Server that is in a Domain Controller role, and runs SQL 2005 Standard. This isn't a 1000 user system, but it doesn't have any problems with v3 (knock on wood).

Mind you, it FREAKED OUT on our other 2000 Server Domain controller that's also our Exchange server. Mind you we didn't bother to set up exclusions or anything when we did that, it's not an exchange client version either, and we havn't spent the time to see if we could get it working friendly as a simple file-system scanner, but i would think we could if we excluded the right folders, etc. But having to exclude Exchange files/folder from file-system scanners is par for the course with any antivirus package I've used.

I will agree completely that's it's not very network-ready yet. A lot of the important settings in the master configuration file I set doesn't seem to apply to the clients (ie: exclusions, UI stuff, Threatsense prompting, etc.).

I'm also with you 100% on the Symantec finally bloated itself into uslessnes, and I jumped at NOD once I found out there new admin features finally began to stack up (unlike 2.7). And I got somethinn that I feel like I'm beta testing, and have unfortunatly commited my company and some of our cutomers to it for at least the next year based on what eset's reputation USED to be. Stupid me, money always corrupts, and new ideas are usualy just new ideas, not good ones, pushed forth to make the money-poeple feel like something's getting done and because the developers are determined to use the latest/coolest framework or gadget.

It STUNS me that half the settings are there but they just don't apply from the RAS, like how could they NOT notice that? It makes me want my money back, but of course first I'll have to find the time to spend a few hours on the phone (instead of servicing my customers) so I can speak with some front line goofball who will waste my time trying to figure out why it doesn't work (based on documented responses) and then say "I don't know why that doesn't work, but it's a really good idea, I'll mention it to my supervisor when I see them next!"

 

WS 2000 Advanced running SQL 2005 Standard -- that's an interesting combination. I'm interested in knowing why that works, but I'm stuck with a different combination because of very specific requirements of a proprietary front end.

It did take our most robust server a couple of weeks to get around to failing, but once the failures started the rapidity of the server's approach to unresponsiveness increased with each cycle.

Have you seen any Event ID 6004 errors in the System log of that Advanced Server system? In the case of all of our WS2000 and WS2003 systems, we could cause that error to appear in a server's System log by simply browsing the server's file shares. That error is one that is generally seen during incipient failure of a NIC (or possibly a port on a switch). But our hardware was just fine. And the error stopped appearing when we got rid of version 3.x on the servers.

Anyway, if your system is not heavily taxed it may take quite a while to see this issue -- assuming it's going to happen to your server at all. But I would be mightily surprised to see any server supporting SQL Server and / or DFS replicas that wasn't susceptible. As I said before, we couldn't even manage to build one in a test situation that didn't fail under load.

On the other hand, we do beat our servers 24/7. Maybe a server that gets a rest once-in-a-while is able to recover from error states, or maybe it doesn't incur them in the first place.

 

What's makes it even more interesting is that it's a Dual P3 1.13Ghz 1U.

It's our current Network montioring hub, it's currently collecting WMI+SNMP from about 160 computers every 5 minutes.

The system is actually below the specs suggested by the authors for the current version. It's also what uses the SQl 2005 Standard, including the SQL Reporting services.

So far v3 has been kind to that system.

We also just installed it on our new firewall box, which is simply a Core 2 Duo with XP on it running firewalling software, and so far it's been fine with it as well - but it's only been 20 hours so far.

What source is sending the Event 6004's you're getting? Are they errors or warnings?

 

techie007

Okay, I think that explains it then. Your use of SQL Server appears to be quite different from mine.

I believe that it's not the act of running SQL Server per se that foments failures on my servers. It's that our SQL Servers are translating data that gets sent to network shares (part of a DFS, actually). Any kind of activity that involves moving data to and from those shares, or just browsing them for that matter, causes the Event ID 6004 errors.

The errors contained data like this --

Code:

A driver packet received from the I/O subsystem was invalid.  The data is the packet.
Data:
0000: 0c 00 e0 00 0e 00 00 00   ..à.....
0008: 9e 99 ea 3c cf 47 c8 01   ??ê<ÏGÈ.
0010: 40 00 00 00 00 00 00 00   @.......
0018: 00 00 00 00 04 00 4e 00   ......N.
0020: 00 00 00 00 cb 0b 00 80   ....Ë..?
0028: 00 00 00 00 10 00 00 c0   .......À
0030: 00 00 00 00 00 00 00 00   ........
0038: 00 00 00 00 00 00 00 00   ........
0040: 4d 00 52 00 78 00 53 00   M.R.x.S.
0048: 6d 00 62 00 00 00 5c 00   m.b...\.
0050: 44 00 65 00 76 00 69 00   D.e.v.i.
0058: 63 00 65 00 5c 00 4c 00   c.e.\.L.
0060: 61 00 6e 00 6d 00 61 00   a.n.m.a.
0068: 6e 00 52 00 65 00 64 00   n.R.e.d.
0070: 69 00 72 00 65 00 63 00   i.r.e.c.
0078: 74 00 6f 00 72 00 00 00   t.o.r...
0080: 56 00 49 00 50 00 00 00   V.I.P...
0088: 4e 00 65 00 74 00 42 00   N.e.t.B.
0090: 54 00 5f 00 54 00 63 00   T._.T.c.
0098: 70 00 69 00 70 00 5f 00   p.i.p._.
00a0: 7b 00 37 00 36 00 46 00   {.7.6.F.
00a8: 37 00 37 00 46 00 43 00   7.7.F.C.
00b0: 38 00 2d 00 33 00 44 00   8.-.3.D.
00b8: 34 00 43 00 2d 00 34 00   4.C.-.4.
00c0: 46 00 32 00 35 00 2d 00   F.2.5.-.
00c8: 42 00 33 00 41 00 44 00   B.3.A.D.
00d0: 2d 00 38 00 30 00 31 00   -.8.0.1.
00d8: 30 00 44 00 39 00 00 00   0.D.9...

Once these errors started showing up in the System log of a server I new that it was doomed. Over a period of days or hours the system would become less and less responsive, and then it would cease to respond at all -- either by RDP or at the console. It would have to be forced to shut down. A restart would have it operating for a while, and then the cycle would start again.

I had to remove the version 3 software from all of our servers because it was affecting all of them in this manner. The only way I could prevent the effect was to completely turn off antivirus protection.

Reverting to 2.70.39 resulted in absolutely normal operations. I can even run an in-depth memory and drive scan using the older version WITH NO EXCLUSIONS (even in the realtime module) while these servers are under full operational load with no consequences whatsoever. (I don't normally run without the recommended SQL exclusions, but I did this just as a test.)

I sent all of this information, including complete system information and a set of Wireshark (Ethereal) log captures with EAV version 3 configured in various ways, to Eset tech support. They said they were going to forward it to the development team. That was weeks ago. The only response I've got from them was pathetic. In that e-mail they asked me if I was having any problems other than seeing the Event ID 6004 errors in my System logs. Quoted directly below their e-mail was the entire string of my messages describing the unresponsive servers and all the other issues I had seen (failure to update, antivirus protection not enabled, etc.). It was obvious that tech support wasn't even reading my messages.

Pathetic.

By the way, the particular error message whose description I quoted above came from an old dell dual P3 server with dual RAID arrays, one of the external. But it is running WS2000 Standard SP4 and SQL Server 2000 Standard. But we saw all the same symptoms on WS2003 R2 SP2 systems.

Thanks for the information you've provided. It helps to confirm my suspicions about the actual cause of the issues we were seeing.

 

In the above quote it states that v3 can be installed over a previous version, however in the installation section of the manual it recommends that it be installed to C:\Program Files\ESET\ESET Security. Does it matter to change it to install over my existing directory or should I uninstall v2 first? Also if I were to install Blackspear's setup, should I just do a standard install first? Thanks for your help.

 

Which is it uninstall or install over existing? I'm more confused the more I read.

 

If I am not mistaken, "can be installed over a previous version" refers to installing a 3.0 version build over the top of a newer 3.0 version build.

Regardless of the program my personal preference is to properly remove the existing version, re-boot, make sure nothing remains in folders\registry, re-boot if necessary and then perform the new install.

YMMV

 

Here at least I installed 3.0 over 2.7, the installer detected the previous version, uininstalled it and then installed 3.0. When performing an upgrade in this fashion a reboot is required to totally remove the previous version's files and LSP entries.

 

Thanks Bubba and flyrfan,
Again I get 2 opinions, but caution being the better part of valor, I guess I'll do the uninstall/re-install and then import Blackspear's setup. I hope that's the best way. Thanks again for the help.

 

Bubba,

For those of us reading this thread who are relative newbies, can you...or any other expert for that matter...provide a detailed explanation regarding the steps you go through to "make sure nothing remains in folders\registry"? Apparently simply uninstalling an existing Eset version (or any other program for that mattter) by using that program's own uninstaller or Windows Add/Remove Programs is not sufficient.

I've seen similar comments in other forums about the need to remove related folders and registry entries after uninstalling a program, but I can't seem to find anywhere good, reliable, specific instructions to follow to do that. Can you experts share this knowledge please?

Thanks.