NOD32 v4 and sharing files on Win Server 2003 (very weird)

[rpremuz]

Hi!

On a MS Windows Server 2003 SP2 with all Microsoft high-priority updates installed I have ESET NOD32 Antivirus 4.0.314 Business Edition (see more details about the server configuration below). The server has a few file shares that have very low traffic. Client systems (MS Windows XP Pro. SP3, fully patched, with ESET NOD32 Antivirus 4.0.314 Business Edition) can copy, save and open files on the file shares without problems with most applications (e.g. Windows Explorer, xcopy, notepad, wordpad, IE7, Firefox 3, MS Office 2003 applications, OpenOffice.org 3 applications).

But if I open a shared file on a client with my favorite text editor VIM (ver. 7.2, both command line and GUI), the file opening is delayed for about 10 seconds. The delay does not depend on file size or type -- it happens even for an empty plain text file. Once the VIM opens the file all subsequent file operations (read and write) are carried out without a delay.

The problem exists only if the files are opened over the network. If the files are opened with VIM editor locally on the server, there is no delay in opening.

The problem disappears if the real-time file system protection is disabled in NOD32 AV v4 on the server. The problem didn't exist with NOD32 AV v3 on that server (I upgraded to v4 two weeks ago).

The Event Log in Windows Server 2003 does not log any errors when the problem occurs, while the Event Log in the Windows XP Pro. SP3 client usually logs the following warning:
Event Type: Warning
Event Source: MRxSmb
Event Category: None
Event ID: 3019
Description:
The redirector failed to determine the connection type.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 00000000 004e0004 00000000 80000bcb
0010: 00000000 c0000010 00000000 00000000
0020: 00000000 00000000

The most serious thing about this problem is that it can make the server unresponsive. I tried to open many files at once with VIM (using the "Edit with multiple Vims" option in context menu in Windows Explorer) -- the server became unresponsive and after waiting for about 30 minutes I shut it down by power button. If I do the same test when the real-time file system protection is disabled in NOD32 AV v4, the server does not experience any problems.

Here follows the summary of more testing of the problem (SMB server is the system that shares files while the SMB client is the system where the shared files are opened):


|--------------------------------------------------------------------------------------------------------------|
|SMB Server ------> |WinServ 2003 SP2 |WinServ 2003 SP2 |WinXP Pro. SP3 |WinXP Pro. x64 SP2 |Ubuntu 8.04 Desk. |
|-------------------|NOD32 4.0.314 |NOD32 2.71.9 |NOD32 4.0.314 |NOD32 4.0.314 |no real-time AV |
|SMB Client ---v | | | | | |
|--------------------------------------------------------------------------------------------------------------|
|WinServ 2003 SP2 | | | | | |
|NOD32 4.0.314 | ? | OK | OK | OK | OK |
|VIM 7.2 | | | | | |
|--------------------------------------------------------------------------------------------------------------|
|WinServ 2003 SP2 | | | | | |
|NOD32 2.71.9 | PROBLEM EXIST | ? | OK | OK | OK |
|VIM 7.2 | | | | | |
|--------------------------------------------------------------------------------------------------------------|
|WinXP Pro. SP3 | | | | | |
|NOD32 4.0.314 | PROBLEM EXIST | OK | OK | OK | OK |
|VIM 7.2 | | | | | |
|--------------------------------------------------------------------------------------------------------------|
|WinXP Pro. x64 SP2 | | | | | |
|NOD32 4.0.314 | PROBLEM EXIST | OK | OK | ? | OK |
|VIM 7.2 64-bit | | | | | |
|--------------------------------------------------------------------------------------------------------------|
|Ubuntu 8.04 Desk. | | | | | |
|no real-time AV | OK | OK | OK | OK | ? |
|VIM 7.1 | | | | | |
|--------------------------------------------------------------------------------------------------------------


Hardware configuration of the server:
Supermicro X6DHE-G (Intel E7520 Chipset)
2 x Xeon 3 GHz FSB 800 MHz
4 GB 333MHz PC2700 DDR ECC Reg.
3WARE SATA RAID 9500S controller
RAID1 250 GB
LAN adapter // driver: Intel PRO/1000 MT // e1000325.sys ver. 8.9.1.0 by Intel

Software configuration of the server:
MS Windows Server 2003 SP2
Active Directory, DNS, DHCP, MS WSUS 3.0
IE7, Mozilla Firefox 3.0.8
All high-priority updates from Microsoft.

ESET software on the server:
ESET RAS 3.0.105, ESET RAC 3.0.105
ESET NOD32 Antivirus 4.0.314 Business Edition
Virus signature database: 3973 (20090329)
Update module: 1028 (20090302)
Antivirus and antispyware scanner module: 1201 (20090327)
Advanced heuristics module: 1092 (20090309)
Archive support module: 1092 (20090324)
Cleaner module: 1039 (20090320)
Anti-Stealth support module: 1010 (20090302)
System status module: 1206 (20090206)
Self-defense support module : 1005 (20081105)
The XML configuration file is in the attachment.

If hope this issue will be fixed ASAP.

-- rpr. /Robert Premuž/

[rumpstah]

Hi Robert:

What about the workstation configuration?

The server.xml does not follow the guidelines here (http://kb.eset.com/esetkb/index?page=content&id=SOLN2144&actp=search&viewlocale=en_US&searchid=1238429949872).

[rpremuz]

Hi, rumpstah!

Adhering to the recommendations for NOD32 v4 configuration on a server (http://kb.eset.com/esetkb/index?page=content&id=SOLN2144&actp=search&viewlocale=en_US&searchid=1238429949872) I've disabled the following options:

Web access protection
In the real-time file system protection

scanning of network drives
scanning of all files in the ThreatSense engine setup


The result is that the VIM editor still opens a file with a delay if the file has one of the extensions scanned by the ThreatSense engine (e.g. .doc, .html), while the file extensions that are not scanned by the engine (e.g. .txt) are opened normally.

It's strange that the problem doesn't exist if files are opened with another application, e.g. Notepad or Wordpad.

Software configuration of the client systems is the following:
MS Windows XP Pro. SP3
IE7, Mozilla Firefox 3.0.8
MS Office 2003
ESET NOD32 4.0.314
VIM editor ver. 7.2
All high-priority updates from Microsoft

As you can see from the table that I posted earlier the problem doesn't occur on the Ubuntu clients with the VIM editor ver. 7.1.

-- rpr. /Robert Premuž/

[rumpstah]

Are the workstations set to scan network drives? If they are, then that option should be disabled as the server is scanning the files in realtime.

[rpremuz]

Yes, the configuration of NOD32 AV v4 on MS Windows XP Pro. SP3 clients includes the real-time scanning of network drives. I would not agree with the suggestion to disable that option if the servers in the LAN have real-time scanning enabled because the clients may also connect to some unprotected network shares that are not on those servers (e.g. a client may establish a VPN connection to a home PC over the Internet and then map network drives to that PC).

For testing purposes I've disabled the real-time scanning of network drives in NOD32 AV v4 on the testing MS Windows XP Pro. SP3 client, but the state of the problem hasn't changed.

-- rpr.

[rumpstah]

Hi Robert:

I understand your reasoning but ask yourself this question. What happens when the file is launched from the Network share/mapped drive (regardless of whether network drive scanning is enabled or disabled)?

A: The file is scanned by the resident protection on the workstation.

I have never had a network install where realtime scanning on the server was enabled and the clients scanned network shares that did not cause slowdowns or lockups (with any AV package). Double duty on scanning is not recommended.

{QUOTE-> Yes, the configuration of NOD32 AV v4 on MS Windows XP Pro. SP3 clients includes the real-time scanning of network drives. I would not agree with the suggestion to disable that option if the servers in the LAN have real-time scanning enabled because the clients may also connect to some unprotected network shares that are not on those servers (e.g. a client may establish a VPN connection to a home PC over the Internet and then map network drives to that PC).

For testing purposes I've disabled the real-time scanning of network drives in NOD32 AV v4 on the testing MS Windows XP Pro. SP3 client, but the state of the problem hasn't changed.

-- rpr. <-QUOTE}

[rpremuz]

{QUOTE-> Double duty on scanning is not recommended. <-QUOTE}

Not recommended by whom? Can you point me to some ESET documentation or KBA about this?

I'd rather have double scanning than no scanning when accessing shared files (I mentioned the example of VPN connections where it might be important).

I still don't have the answer to my problem with opening the shared files with the VIM editor. Even if I carry out all your recommendations about NOD32 AV v4 configuration on the Windows Server 2003 and the Win XP client the problem doesn't go away.

-- rpr.

[agoretsky]

Hello,

New releases of ESET Smart Security and ESET NOD32 Antivirus are out, v4.0.417.0 (http://www.eset.com/joomla/index.php?option=com_content&task=view&id=5905&Itemid=2), which contains some fixes for accessing files over network shares. Would you mind upgrading a test workstation to the new build, repeating your VIM test and posting the results?

Regards,

Aryeh Goretsky

[not4]

{QUOTE-> Hello,

New releases of ESET Smart Security and ESET NOD32 Antivirus are out, v4.0.417.0 (http://www.eset.com/joomla/index.php?option=com_content&task=view&id=5905&Itemid=2), which contains some fixes for accessing files over network shares. Would you mind upgrading a test workstation to the new build, repeating your VIM test and posting the results?

Regards,

Aryeh Goretsky <-QUOTE}

Somebody's lying here;) From your link:
ESET Smart Security and ESET NOD32 Antivirus v4.0.417.0 have been released in Czech, English, French, German, Polish, Russian, Slovak and Spanish for licensed users, with trial versions and other languages to follow. This release contains the following changes:

ALL

Fixed display of size when scanning multi-gigabyte archives
ESET SMART SECURITY

So it looks like in NOD32 you fixed only display of size when scanning multi-gigabyte archives. No mention of any other bug fixed!!!

[funkydude]

{QUOTE-> No mention of any other bug fixed!!! <-QUOTE}

You're joking right, you're hijacking another thread to complain about incomplete changelog which nearly every single software company does this. :dry:

[agoretsky]

Hello,

Testing with the latest build of a program is a very common troubleshooting technique, as that typically is the code which has the most development resources focused on it.

Regards,

Aryeh Goretsky


{QUOTE-> Somebody's lying here;) From your link:
ESET Smart Security and ESET NOD32 Antivirus v4.0.417.0 have been released in Czech, English, French, German, Polish, Russian, Slovak and Spanish for licensed users, with trial versions and other languages to follow. This release contains the following changes:

ALL

Fixed display of size when scanning multi-gigabyte archives
ESET SMART SECURITY

So it looks like in NOD32 you fixed only display of size when scanning multi-gigabyte archives. No mention of any other bug fixed!!! <-QUOTE}

[manney]

I've had an almost identical problem at one of my clients sites. Upgraded nod32 on their server and workstation from 2.7 > 4.0.417 and their network applications ground to a halt, 25-35 seconds to open a document in their accounting system for example which was previously almost instantaneous!

Network drive checking was disabled on both workstations and server. Ended up havig to uninstall nod off the server until I find a solution, once uninstalled everything went back to normal

A solution would be appriciated :shifty:


Manney

[rpremuz]

{QUOTE-> New releases of ESET Smart Security and ESET NOD32 Antivirus are out, v4.0.417.0 (http://www.eset.com/joomla/index.php?option=com_content&task=view&id=5905&Itemid=2), which contains some fixes for accessing files over network shares. Would you mind upgrading a test workstation to the new build, repeating your VIM test and posting the results? <-QUOTE}

I've installed the NOD32 AV 4.0.417 on both the server and one of my WinXP Pro. SP3 clients but to no avail (see the results in my initial post).

-- rpr.

[rpremuz]

Just to add that I've tested this issue (see the beginning of the thread) also with NOD32 AV 4.0.424 on both the Windows Server 2003 SP2 and the Windows XP Pro. SP3 clients but to no avail.

-- rpr.

[manney]

NOD32 AV 4.0.424 definatly has not fixed the problem on server installs, are NOD support ever going to address this problem??? Not much feedback going on here >:(

[a_kerbouchard]

Yep they have not fixed. I have ALL exclusions recommended from ESET and Microsoft. File/Print Servers randomly lock up and have to manually be reset. Good thing we have 21 locations in 3 states. :( AD Servers lock up quick. I removed it (4.0.424) from those machines n went back to 3.0.650.

[rpremuz]

I've tested my issue (see the beginning of the thread) also with NOD32 AV 4.0.437 on both the Windows Server 2003 SP2 and the Windows XP Pro. SP3 clients but to no avail.

-- rpr.

[bradtech]

{QUOTE-> I've tested my issue (see the beginning of the thread) also with NOD32 AV 4.0.437 on both the Windows Server 2003 SP2 and the Windows XP Pro. SP3 clients but to no avail.

-- rpr. <-QUOTE}

Have you tried using Microsoft, and ESETs recommended exclusions list on servers? I am still running 3.0.672 on my servers.. V4 on my clients though..

[rpremuz]

{QUOTE-> Have you tried using Microsoft, and ESETs recommended exclusions list on servers? <-QUOTE}

Yes, I've tried that -- see the post #3 in this thread.

-- rpr.

[clutch]

rpremuz,

I have been experiencing a very similar issue as you describe, the only difference is mine is not localized to one application. Anytime someone launches Windows Explorer, My Computer, the Start menu or any other application that can access the network, I get a 8-10 second delay. Here's what I've done so far...

When I pushed out version 4.0.417 from the RAC, I did not manually uninstall ver. 3 from my clients. I let the automated installation from the RAC perform the uninstall and installation of ver. 4.

I first uninstalled NOD32, rebooted (twice after reading a post in this forum) and reinstalled. This did nothing for my issue. In fact, reinstalling and the issue would soon (not immediate) come back.....it may take several hours or the next day for the issues to resurface.

I then noticed that I could make this symptom disappear by disconnecting all my network drives. When I reconnected them (via login script), the symptom would return. So I then tried to disconnect each of the drives one at a time to figure out which one was giving me trouble. I noticed that our Personal drives (mapped not in the login script, but in the Active Directory user profile) was mapped using a different method than the other mapped drives that I receive via login script. We are using DFS, which if you haven't used DFS drives before, you map drives as \\domain name\share rather than \\servername\share. I noticed that our personal drives were mapping the drive via the short name of our domain \\domain\share. Just for kicks, I changed my drive mapping to use the FQDN (\\domain.com\share) and rebooted. To my surprise, my symptoms went away and have stayed away.
So to move forward, I ensured that any mapped drive, whether the personal drive in the user account's profile or a drive mapped via a login script used the FQDN rather than our short name.

Moving forward, I opened up a case with ESET to ask them why this happened and what was causing it...because it was very strange that using the short name versus the FQDN in a drive mapping shouldn't really have any bearing, as long of the names are resolved by DNS. Reproducing the issue, ESET had me check several settings on both my WinXP clients and on the Win2k and Win2k3 servers, most, if not all you have mentioned above. They had me turn off scanning of Network Drives, omit certain Windows files and folders and turn off Email scanning...just to name a few. These solutions did not resolve my issue.

Their next step was for me to install Wireshark and start accessing network shares, sending ESET the Wireshark log afterwards. I have not completed this step yet.

Since then, changing the network drive mappings has fixed my issue on most clients, but I'm noticing that this issue is a two headed beast. Some people are not having anymore issues since I changed our drive mapping scheme. But others are still having issues. If someone is still experiencing an 8-10 sec. delay in opening up explorer or applications, I can uninstall NOD32, reboot, manually delete any residual files/folders/Registry entries (per ESET manual uninstall instructions), reboot a 2nd time, then push out ver. 4 (4.0.424) and the user doesn't experience anymore issues.

This post prob. doesn't help much, but I wanted to let you know that you are not the only one having this issue. I will try and collect some packets from a workstation that is still having this issue and get it sent off to ESET. Maybe that info. will help them come up with a solution for this issue.

[rpremuz]

clutch,

in my case DFS is not used for file sharing, i.e. share paths have the form of "\\servername\share".

If I use FQDN server names in share paths ("\\servername.foo.bar\share"), the problem doesn't go away -- there is still a delay in file opening.

-- rpr.

[Marv Gordon]

{QUOTE-> clutch,

in my case DFS is not used for file sharing, i.e. share paths have the form of "\\servername\share".

If I use FQDN server names in share paths ("\\servername.foo.bar\share"), the problem doesn't go away -- there is still a delay in file opening.

-- rpr. <-QUOTE}

Delays here too. Win2k3 SP3 R2 Enterprise.

Upgraded to V4 on our main fileserver.

1. Removed V3
2. Deleted any left over files, reg entries
3. Clean V4 Install
4. Applied all recommended server settings.

RealTime kills performance opening and saving files. Accounting reports major delays when they work on server based spreadsheets.

I watched the process. Took 10-15 seconds on average to open an excel file. Removed XL? from scan and the same file opened and saved so fast you couldn't even time it.

Slowdown didn't happen under V3.

I know "go back to V3" is an option, but considering ESET is pushing V4 as the latest and greatest and superior to V3, this needs to be fixed. Customers shouldn't have to to run an "old" product.