Version 3 – issue running on a WS2k3 DC

Last month I installed version 3.0.566 of NOD32 onto the DC (running WS2k3) of our single server network, upgrading from version 2.7.

The installation went smoothly, and everything seemed ok until several hours later when network access to the sever effectively "locked up", meaning that users could not access shared files and there were huge logon delays as clients were unable to access GPO information. Rebooting the server did resolve the issue, but only for it to recur after approximately a day. After going through the cycle a few times, I removed version 3 of NOD32, replaced it with the old version 2.7 and everything has been fine since.
My research of the issue leads me to suspect the kernel mode filter driver used by NOD32 (indicated by Microsoft KB articles 908370 and 816071).

We (read: management!) are keen to upgrade to version 3, and I note that there is now an updated release of NOD32 available – however as the release notes only list GUI & mail client fixes I don't want to install again until I'm confident that the above issue won't recur.

 

Sorry to bump this thread, but was wondering if anyone had any ideas or had noticed something similar?

 

It sounds very similar to the problem in my thread.

Since uninstalling Hotfix KB941644 last Friday the problem has not re-occurred (so far).

 

Hi,

Even if removing KB941644 from a system seems to fix this issue, I am loathe to do it. The patch we're talking about is listed among various security groups as being very critical. I hope Eset will deal with it. In the meantime, I'm stuck on 2.70.39 for my network.

 

Almost every security update that Microsoft release these days is described by them as "critical". In practice it is unlikely to be so if you have a good AV and firewall.

Surely Microsoft wouldn't release software without thoroughly testing it......
There have been several times in recent years when Microsoft has had to re-release a patch (i.e. issue a patch to fix a previously released patch).
There do seem to be a few reports on the Internet about trouble with this patch.

I thoroughly agree with you. Whether its Microsoft's fault or Eset's they must issue a patch for NOD32 because there will many computers out there who suffer from this conflict.

Uninstalling a Microsoft hotfix is not a satisfactory solution to the problem, but is just a temporary workaround until Eset release a fix.

 

Well, I'd point out that it's not really Microsoft's responsibility to test their patches with every piece of software written by every other vendor out there. They do write their patches with strict attention to maintaining compatibility with the promised feature set and the APIs. The new features of the Eset antivirus software, however, are treading dangerous waters in that they are using techniques which have obviously not been as well thought out as they might have been. No one knows as much about the OS as the people who write it. When a second party software company decides to interfere significantly with the way an OS conducts its business, there's always a fair chance that something untoward will occur.

I wonder if Eset might rethink their strategy here and provide a somewhat less aggressive package for use on systems like the ones I run. I'm not supporting desktop users but real honest-to-goodness production equipment that works very hard for its living. Hamstringing such systems with really aggressive antivirus software can impede the functionality of the production lines -- something with which I've had a fair bit of experience.

This sort of stuff is why I insisted that the Symantec corporate antivirus software be removed from the production network I run. It was causing spontaneous reboots on some heavily laden servers. Version 2.7 of NOD32 was a dream after that experience. But version 3.0, while not being an outright nightmare, has been a real disappointment.

As for the choice of patching or not patching -- IMO, as a person charged with the maintenance of information systems production assets in a corporate environment, I would have little choice but to apply important security updates as they were released -- unless, perhaps, I were running a truly isolated network. I would never assume that an antivirus, regardless of its quality, would protect the network from the type of exploit that this patch was designed to prevent.

Fortunately, I had 2.70.39 to fall back upon. Each of us has to figure out what's her/his own best course. But I'd rather go back to 2.7 than remove the patch in question.

 

Since removing the KB941644 update on our main file server last Friday lunchtime we have had no more access problems.
Previously it would grind to a halt once or twice a day.

However, I do agree with you that there is definitely a problem with NOD32 v3.0.

Just before Christmas I upgraded NOD32 from 2.70.39 to 3.0.566.
We had exactly the same problem with not being able to access files on the file server across the LAN after the server had been running for a few hours.

This was before KB941644 was released and so it obviously cannot be blamed.

When NOD32 3.0.621 was released I decided to try the upgrade again.
It just happened to be installed on the same day as a couple of Microsoft updates including KB941644 (coincidentally).

Fortunately it has only affected the one server in our company and none of the workstations or notebooks.

Eset definitely need to do some work to NOD32 and ESS to ensure that problems like this do not occur and that they are compatible with the majority of software that their customers are likely to use.

 

I'm glad it's working for you now. I would just add that a little caution may be in order. I was seeing what I think was a symptom of the base cause (Event ID 6004 - malformed packet isue) for this overall problem with loss of remote desktop sessions and loss of server responsiveness just as soon as we installed 3.0.621.0 -- quite some time before relase of any of the suspect patches from MS.

The problem started on the PDC emulator / FSMO role holder for the domain but started cropping up over the ensuing weeks on other servers. Eventually, all servers were affected. I would roll the NOD32 version back on a pair of servers at one site only to have the problems start affecting servers at other sites in the domain. Bizarre! I got so that I could predict which server would be next judging from behaviors I was seeing during RDC sessions. Once I started having problems using the DFS applet via RDC on a given server I knew that that server would be folding within a few hours. I actually suspect that it was, in part, the use of the DFS applet that might have been engendering the failures.

I sent Wireshark logs captured from one of the servers to Eset for analysis, but have not heard anything more from them. I wanted to do more research on the matter, but I just had to roll all of my servers back to 2.70.39. They just have to run -- period.

 

If the problem re-occurs now that KB941644 has been removed, then I will probably follow your example and roll NOD32 back to 2.70.39 on the troublesome server (again).

If Eset release a new version and assure me that the issue has been identified and fixed, I may try it on the server.

I agree with you that the servers have to run. I don't like experimenting on a live server because it can cause a lot of grief for everyone.

 

I also begin having random lock ups on an Windows SBS after the installation of version 3. Unfortunately I can’t tell you which exact version he installed as I was under some 'pressure' to solve the problem. I quickly removed V3 and downgraded to the older version, the problem hasn’t returned. I also had the same symptoms on my laptop with Windows Vista Business since installing V3. I uninstalled it from my laptop and the problem has disappeared. Not much help with any details but the issue did affect me!

 

Removing Hotfix KB941644 was a red-herring.

The problem has just come back again.

 

I'm sorry to hear about the setback. After my experience with this over the last several weeks I was afraid that this would be the case.

Would you mind telling us if you're seeing Event ID 6004 in the System log of the affected server?

 

Event ID is in the System event log on 19 Dec 2007 and 16 January 2008, but at no other time.

The upgrade to NOD 3.0.621 took place on the evening of 11 January 2008.

18 December could have been the date that I tried upgrading NOD32 2.70.32 to version 3.0.566 (but I am not sure of the exact date). I subsequently rolled back to 2.70.32 the day after.

 

I found that browsing network shares from the server's console or from a remote desktop connection to the server resulted in a repeatable occurrence of the Event ID 6004.

However, if you should happen to feel like experimenting, be aware that browsing network shares also inevitably led to:

a) failure of remote desktop sessions, sometimes leaving the sessions live but NOT resettable, and

b) a gradual descent of the server being tested into non-responsiveness (with NO info in the logs after a forced shutdown and reboot)

Pretty futile, and annoying.

I confirmed this on FOUR different servers of varying vintage -- three of them being Windows 2000 Server SP4, and one of them being Windows Server 2003 SP2. All were DCs. All had SQL Server 2000 installed, but it was only actually running on one of the 2000 servers and on the 2003 server. The ones running SQL Server failed more rapidly than those which weren't.

I took all 12 servers back to 2.70.39 after seeing the fourth failure. I'm staying there until I see something in the way of solid committment from the folks at Eset. My last message to them, with Wireshark logs they requested, was six days ago. I have received no response. Not a good sign.

Edit: Oh, and I wanted to be sure I added that the proper exclusions for SQL were added to NOD32 settings on all of these servers.

 

1) The server that I am having a problem on does not have SQL server installed. So I don't think it's necessarily along those lines. It -is- a domain controller, however. Just being a domain controller isn't enough though, because I have two other domain controllers running NOD32 just fine.

2) I have seen those Event ID's in my event log from time to time since installation -- but not all the time, and not necessarily right before failure.

3) The server only ever locks up if I have real-time file scanning enabled. I can have the other two scans running without causing the server to lock up.

 

Yes, it was, apparently, the real-time protection that was causing issues. When I ran Wireshark to gather logs for Eset tech support, I tried disabling different modules of NOD32 to see what difference that made in behavior. It was after disabling real-time protection that the error messages ceased to show up when browsing network shares. But I wasn't interested in running part of the package, so I reverted to 2.70.39.

I was certainly seeing the same sort of failure on servers not running SQL Server. It's just that I saw the failures occur more quickly on those which were running it. That may, or may not, have merely been a matter of coincidence. But the failure on my DCs running SQL Server happened DAYS sooner than the failure on those which were not running SQL Server.

 

Just a note, on the SBS machine that I was having problems with, I had verified the correct exclusions for SQL and Exchange. I had also disabled the Email Checking and the Internet Checking. The problems started out seldomly than began to occur more frequently, like a downward spiral. I did not have any out of character events in the logs.

 

I'm so glad (in some ways) that other people have been having the same proplem as me with 2003 Server DC's.

Ours has become more stable (i.e. uptime now 2 weeks) since i added the exclusion of the profiles folder on the DC (users folder redirects).

Any offical response from Eset on this issue and when it will be fixed?

 

You're not alone here. I have been pulling my hair out after deploying v3 on my domain.

The server (Windows SBS 2003 R2) became so unstable (it was less than a month old) that I have had to withdraw it from the domain completely.

I had numerous issues, including:

- EventID 6004
- Users unable to login on their client machines joined to the domain - event ID shows up errors 1030 and 1058 regarding blocked access to certain Global Policy files
- access to shared files became blocked at random times
- And the final straw was that i was unable to login to the server as Admin or with my user name - it hung at "Applying settings" for 3 days, and was totally unreponsive save for responding to pings
- RDP unavailable

It was very random though. The most we had the server stable for was 5 days. Then it would just descend slowly until it just stopped responding. Fantastic when you get a call to say the expensive server has just gone down AGAIN!

I had thought that my limited knowledge of this OS was to blame (and yes I had configured all the recommended MS exclusions), but reading the threads here I feel a slightly relieved. However, I have now had to re-install the server from scratch and will now have to proceed with moving all the users from the old domain onto the new domain I've had to create.

I have no conclusive proof that NOD was to blame, but the errors I had are similar to those reported in this thread and in others here.

I love NOD, but I think I will be steering clear of version 3.0 for a while. I am now going to roll out 2.7 through the domain as this seems to be the answer.

 

just to add my name to this as it were, we are currently rolling back from v3 to 2.7 , we've had problems similar to others with the DC's.

And to be safe we are rolling back all 2003 servers

170 odd v3 desktops are fine

Chris

 

Just noting, we've seem some strange hangups like you are seeing also on windows server 2008 rc1 AD/DC systems... Can't blame them for issues on a beta OS but...

I still have other ekrn high cpu usage issues with certain files, exe packed downloads, etc that hose the system for up to 15 minutes.

Staying with 2.7 for all clients, new installs, etc, anything in production other than our own production network.

Will continue to do so until it appears 3.0 is rock solid, however long that may be.

If 2.7 support and downloads are stopped for any reason before 3.0 is solid, we will switch every single one of our clients to another product and drop our reseller account with ESET.

 

Is there any offical word from ESET? on what they are doing about it or when we can expect a new build to fix the problems?

 

Re: Version 3 – issue running on a WS2k3 DC

Rolled back to 2.7 on my sbs 2003 server install today. Some wierdness with a shared application makes me think nod is a little too aggressive right now and going after the wrong things.

 

On my server that is having the problem (one of three), I notice that it only crashes when it is under somewhat heavy file sharing use... not necessarily CPU usage, it seems more related to the files. I can leave it up all weekend long without any problem. Come 6am Monday morning though when people start showing up to work, I start getting phone calls.

 

For those who are interested, CrookedBloke has been carrying on a meaningful thread here trying to track down the root of these problems. No solutions yet. Currently, he is asking for hardware configurations to see if it can be tracked down to certain RAID/hard drive controllers.