Problems after upgrading NOD32 on File Server

We have a Windows Server 2003 file server that was running NOD32 2.7 with no problems.

Besides running SQL Server 2000 the server is just acting as extra network storage.

I recently upgraded it to NOD32 3.0.621 Business Edition. It is currently running virus database 2794 and all of the latest program components.

Since the NOD32 upgrade it will run for a few hours and then grind to a halt, denying access when trying to open any files on its shared drives.
It is possible to browse the directories with normal speed, but trying to open any file (e.g. doc, xls, pdf or even a simple text file of only a few KB), causes the application to hang and eventually time out without managing to open the file.

If I log into the server locally or via a Remote Desktop Connection it is possible to open those files at a normal speed.
If I examine the processes running with Task Manager nothing is using much CPU time.
Trying to access the files remotely just hangs the application used (e.g. Word, Excel, Notepad etc.)

If I reboot the server everything is fine again for another few hours.

I have disabled advanced heuristics and excluded any SQL Server database files but this does not seem to have improved the situation.

When I rolled back to NOD32 2.7 the problem went away.

NOD32 3.0 is running successfully on all other servers and workstations in the Company except for this one file server.

Any ideas what might be the problem and how to fix it?

 

I have some similar problems as you do, but my server doesn't let me remote in when it decides to stop:
https://www.wilderssecurity.com/showthread.php?t=197748
I'm hoping for solutions as well.

 

Hmmm, I've just encountered a similar problem. One of our clients has a 2K3 R2 Server DC running ISA 2006 and DNS (I know it shouldn't all be on there really but it works...or it did) It's been running NOD32 happily for a couple of years now but since upgrading to NOD V3 on Wednesday we have been receiving the slow down error. Each time requiring a reboot to get it back up and running. The strange thing is the DNS has stopped resolving addresses? I'm going to knock it back to 2.7 later this weekend to see if it restores it back. Will let you know what happens.
Can't believe they haven't tested it enough not to spot this problem.

 

what does event viewer say about this whole affair?

any errors or warnings?

 

There are no errors or warnings in either the System or Application event logs.

On the same day that NOD32 was upgraded from 2.7 to 3.0, some Microsoft updates were also installed. (Yes, I did reboot after each type of update).

We have uninstalled the TCP/IP update KB941644 and so far the problem has gone away.

I will update you in the next few days to let you know whether this has solved the problem or not.

 

I had to roll my entire production domain back from 3.0.621.0 to 2.70.39 because:

1. I was seeing Event ID 6004 errors in the system log of any server when I would log on remotely and browse network shares or check the DFS.

2. I gradually lost the ability to connect to servers remotely via RDP. A reboot would fix the problem temporarily.

3. Some servers running SQL Server would eventually become totally non-responsive. Leading up to non-responsiveness no CPU-intensive processes were seen in Task Manager. Nothing in Event Viewer following forced reboots. (Systems would become so non-responsive that I would have to hold their power buttons in for several seconds to force them to power down. I don't like doing that on multi-cpu, multi-RAID array systems.)

I am presently awaiting a resonse on this issue from Eset support. I hope everyone who is seeing these behaviors is filling reports with Eset. I gathered a Wireshark log for them last week, but I haven't heard anything back from them since then. Not even when I sent them an addendum detailing loss of remote desktop sessions and unresponsive servers. (My first issues were just problems with Event ID 6004 -- malformed packet -- errors.)

 

Sunday evening I installed several security updates (including KB941644) then NOD32 v3 BE, did every restart required.

OS: Windows 2003 Standard R2 SP2, AV: NOD32 V3.0.621 Business Edition

Did the installation on 5 servers:
1. Isa Server 2004, DNS Server (INET side) - About 10-15 minutes after last restart the terminal services console became very slow, eventually i had to close it. Proxy/firewall/routing stopped working several hours later. In the morning I did a reboot and after restart I could not log on at the console - after introducing the password the server never got to the desktop. After a hard reset i had to start in safe mode and disable the eset service then i could start the system and uninstall NOD32.
2. File server - in the morning clients working on that server complained they cannot access their files. I also noted no ping response from server, no Terminal Services Console. After a reboot everything worked properly. At least till now.
3,4. Domain controller, File server, DNS server (AD integrated, LAN side): everything was ok for about 20-22 hours then clients complained they cannot access their files, trying to open or save an already opened document made clients to hang up. Ping by name didn't work anymore, only ping by IP. The clients regained access to their hanged documents in the very second the NOD32 uninstaller stopped the antivirus service.
5. Webserver. Some clients complained they cannot access some web app using Internet Explorer 7, but it worked when using Firefox. It used to work last week before i installed NOD32. Still I can't say if it is related or not to the NOD32 v3 installation.

I have to do some tests to see if removing KB941644 makes NOD32 v3 happy.

 

As stated in this thread the problem seems to have gone away after uninstalling hotfix KB941644.

This is obviously not a satisfactory solution, just a temporary workaround until Eset release a fix.

 

It seems that I spoke too soon about the problem being solved by removing Microsoft Hotfix KB941644.

The problem has just re-occurred again.

Looks like another server reboot!

Maybe I will have to roll back to NOD 2.70.39 until Eset can identify the problem and issue a fix.

 

I rolled my entire production domain back to 2.70.39. I also just rolled my remote admin machines running Vista (not members of that domain) back for other reasons (browser and proxy issues).

I'm afraid it's going to take a bit more than a reassurance for Eset that they've provided another update designed to fix these issues. I've done this two-step (install 3.x, drop back to 2.7) a couple of times now. The "forward" step isn't happening again unless I see something along the lines of a really good explanation, bordering on the conclusiveness of a whitepaper, from Eset.

I have used NOD32 for years on my personal systems. It just happened that SAV CE started really crapping out on my corporate network at just the same time that Eset was coming out with this new version. I had to switch AV software, and fast, because the Symantec software was making my production servers reboot.

If I had known how flakey the new version of the Eset software was going to be, I would have looked elsewhere when setting up a contract for new AV software for my production domain.

I'm happy with the "local" behavior of 2.70.39, but I was counting on the improved admin features of 3.x for deployment on this domain. Now I am well and truly screwed, with no way forward -- short of Eset actually correcting their problems with 3.x or me dropping the contract and going for another company's product.

 

Well I rolled the Server back to 2.7 and everythings been fine since then. So looks lilke I'm gonna have to wait until ESET say they've fixed the problem. I have a clean install of V3 on a brand new server and a small network of 20 wireless laptops that hasn't gone live yet so it'll be interesting to see how the system runs when they start using it everyday. Just got the problem where when the user logs on it pops up the NOD window so had to manually tell it not to show the splash screen (Not sure why that works because it's the actual NOD window not a splash screen that opens and stays open??)

The DNS error turned to be because teh bindings of the NICs had changed - whether the NOD install changed it or it did it by itself?? I don't know.

Don't you just love computers?

 

At one time. I've been supporting them for too long now.

 

This problem has been reported for more than 15 days now. Any official information from ESET?

We've experienced the same symptoms / problems too. Huge headaches!

Adam.

 

I opened a case with ESET. First they wanted me to install http://www.belarc.com/Programs/advisor.exe, which we are not going to do on a production environment. Besides, that just gathers some info I can provide myself.

Then they told me:
---------------------------------
When installing ESET NOD32 3.0 Antivirus on a server, please disable "HTTP checking" from within the Setup menu.

1. Open EAV.
2. Enter the Advanced setup tree (F5).
3. Navigate to Antivirus and antispyware > Web access protection > HTTP.

Please let us know if this works for you.

Thank you,
ESET Customer Care
---------------------------------

That's it, nothing useful. Still no resolution.

I'm disappointed by their lack of willingness to help. They have a great product but a poor support attitude. Very slippery slope....

 

I've used Belarc Advisor at home and at work. It provides a lot of useful information and seems to have no unwanted side effects.

Eset asked me to download Eset SysInspector. This great tool requires no installation and does the same job as Belarc Advisor and more.

Disabling HTTP protection would have no effect as a Web Browser is virtually never run on the file server.

The last time that I heard from Eset support in the UK they told me that the problem was still with Eset in Slovakia. No news about whether the cause of the problem had been identified or whether a fix is being developed.

Since disabling Advanced Heuristics and adding the directories used by Sage (SQL Server database) to the exclusion list the problem has not re-occurred.
Obviously this should only be considered as a temporary workaround.

 

An install recently brought the same "server dissapear" problems.
Turned out to be the 2 p.c's still using ver 2 while the server and all others were on ver 3 corporate. Once they were upgraded the problem went.
Included an issue with a "Sage" form

 

Hello,

if there's anyone willing to cooperate we will appreciate manually performed full memory dump from the "bad" server state.

Please PM me for details.

Thanks.

 

the times I've encountered this it was impossible to even access the console physically, We had to cut the power to reboot it in safe mode to uninstall nod32) The other time the domain controller stopped sharing the netlogon (which now is on the default exclusion list) That server was accessable thru remote desktop and about 10 seconds we uninstalled nod32 it started the netlogonshare normally.

/G

 

Yes, I saw this behaviour too on Windows 2003 SBS. It locked up the server completely. Nobody could logon (access to netlogon and sysvol shares was blocked) and I couldn't even login locally. It was so bad I ended up re-installing the sever.

See my post here: https://www.wilderssecurity.com/showthread.php?t=196980

Now using 2.7 with no problems at all (but have excluded a lot of folders as per MS's recommendations)

 

There is a way to cause a blue screen and generate a memory dump on a hung server. I've used it in the past with another issue. You have to enable the feature _before_ the server hangs. If you're using a PS/2 keyboard, it only requires a registry key change. If you have a USB keyboard, a hotfix is required as well:

Windows feature lets you generate a memory dump file by using the keyboard
http://support.microsoft.com/kb/244139/en-us

I've had this hang a couple times on my SBS 2003 machine after installing NOD32 3.0. If it happens again, I'll try to grab a memory dump.

Mark

 

What you say is true about the way to cause a blue screen error. I'm not quite seeing how it applies though.

In order to save memory dumps with BSOD crashes, you can do the following:
Control Panel > System > Advanced > Startup and Recovery Settings
Under System failure, you can set your options and the memory dump settings.

 

Yes, that's part of the instructions in that KB article. That just governs what happens once the server has in fact crashed.

The problem is what to do when the server is hung and unresponsive (no response to mouse or keyboard) but it hasn't actually crashed, which is what has been happening with NOD32 v3. That's where the forced blue screen can come in handy: instead of pushing the reset button to do a hard reboot of the server, you use the special keyboard combination (right CTRL+SCROLL LOCK+SCROLL LOCK) to cause a crash, which saves a dump (depending on your settings). In the hands of someone who knows how to read dumps, that will let them figure out what was going on when the server was in the hung state.

Mark

 

Ah, I see where you are coming from now. That is a good idea.

 

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.

 

For all of you who are seeing these issues --

It is, of course, possibly instructive for us to post here on the forum. But please communicate directly with Marcos or the other Eset moderators in the hopes of helping ESET find a solution.

In simplest terms you have to do what the MSKB article says about setting your systems up to perform complete memory dumps. Then you edit the registry of the server (as per the MSKB article) to enable the ability to force a blue screen error from the keyboard with the right <Ctrl>+<Scroll Lock>+<Ctrl Lock> key combination. Then you either deliberately cause the failure condition (I can do it reliably on any of my servers with EAV 3 installed simply by browsing to \\machine_name\share_name in Windows Explorer.) or wait for it to happen. You go to the physical console. You hit the key combination. You collect the MEMORY.DMP file to be uploaded (By all means compress it first into an archive.) to the ESET ftp site. You collect the eamon.log file (produced by the special eamon.sys driver), and send that to the moderator with whom you are working.

PLEASE -- do it. ESET need all the help they can get with this matter.

Note: Those of you who have USB-connected keyboards will have to follow the special instructions in that MSKB article to be sure that you can produce the blue screen upon command from the keyboard.