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

Discussion in 'ESET NOD32 Antivirus' started by rpremuz, Mar 30, 2009.

Thread Status:
Not open for further replies.
  1. rpremuz

    rpremuz Registered Member

    Joined:
    Jan 18, 2005
    Posts:
    100
    Location:
    Croatia
    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):

    Code:
    |--------------------------------------------------------------------------------------------------------------|
    |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ž/
     

    Attached Files:

  2. rumpstah

    rumpstah Registered Member

    Joined:
    Mar 19, 2003
    Posts:
    486
    Hi Robert:

    What about the workstation configuration?

    The server.xml does not follow the guidelines here.
     
  3. rpremuz

    rpremuz Registered Member

    Joined:
    Jan 18, 2005
    Posts:
    100
    Location:
    Croatia
    Hi, rumpstah!

    Adhering to the recommendations for NOD32 v4 configuration on a server 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ž/
     
  4. rumpstah

    rumpstah Registered Member

    Joined:
    Mar 19, 2003
    Posts:
    486
    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.
     
  5. rpremuz

    rpremuz Registered Member

    Joined:
    Jan 18, 2005
    Posts:
    100
    Location:
    Croatia
    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.
     
  6. rumpstah

    rumpstah Registered Member

    Joined:
    Mar 19, 2003
    Posts:
    486
    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.

     
    Last edited: Mar 31, 2009
  7. rpremuz

    rpremuz Registered Member

    Joined:
    Jan 18, 2005
    Posts:
    100
    Location:
    Croatia
    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.
     
  8. agoretsky

    agoretsky Eset Staff Account

    Joined:
    Apr 4, 2006
    Posts:
    4,032
    Location:
    California
    Hello,

    New releases of ESET Smart Security and ESET NOD32 Antivirus are out, v4.0.417.0, 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
     
  9. not4

    not4 Registered Member

    Joined:
    Mar 20, 2009
    Posts:
    20
    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!!!
     
  10. funkydude

    funkydude Registered Member

    Joined:
    Apr 5, 2004
    Posts:
    6,852
    You're joking right, you're hijacking another thread to complain about incomplete changelog which nearly every single software company does this. :cautious:
     
  11. agoretsky

    agoretsky Eset Staff Account

    Joined:
    Apr 4, 2006
    Posts:
    4,032
    Location:
    California
    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


     
  12. manney

    manney Registered Member

    Joined:
    Jun 29, 2004
    Posts:
    32
    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
     
  13. rpremuz

    rpremuz Registered Member

    Joined:
    Jan 18, 2005
    Posts:
    100
    Location:
    Croatia
    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.
     
  14. rpremuz

    rpremuz Registered Member

    Joined:
    Jan 18, 2005
    Posts:
    100
    Location:
    Croatia
    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.
     
  15. manney

    manney Registered Member

    Joined:
    Jun 29, 2004
    Posts:
    32
    NOD32 AV 4.0.424 definatly has not fixed the problem on server installs, are NOD support ever going to address this problemo_O Not much feedback going on here :mad:
     
    Last edited by a moderator: May 19, 2009
  16. a_kerbouchard

    a_kerbouchard Registered Member

    Joined:
    Apr 17, 2008
    Posts:
    35
    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.
     
  17. rpremuz

    rpremuz Registered Member

    Joined:
    Jan 18, 2005
    Posts:
    100
    Location:
    Croatia
    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.
     
  18. bradtech

    bradtech Guest

    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..
     
  19. rpremuz

    rpremuz Registered Member

    Joined:
    Jan 18, 2005
    Posts:
    100
    Location:
    Croatia
    Yes, I've tried that -- see the post #3 in this thread.

    -- rpr.
     
  20. clutch

    clutch Registered Member

    Joined:
    Oct 10, 2008
    Posts:
    19
    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.
     
  21. rpremuz

    rpremuz Registered Member

    Joined:
    Jan 18, 2005
    Posts:
    100
    Location:
    Croatia
    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.
     
  22. Marv Gordon

    Marv Gordon Registered Member

    Joined:
    Nov 2, 2007
    Posts:
    59
    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.
     
  23. TyeF

    TyeF Former Eset Moderator

    Joined:
    Feb 19, 2010
    Posts:
    78
    The mapped network drive is generating the
    error messages because the svchost.exe and explorer.exe
    processes are being marked as a web browser;
    therefore that traffic to those resources is being scanned as a web browser.

    We recommend that you change the ESET configuration as follows:

    1. Open the main program window by clicking the ESET icon next to the
    system clock or by clicking
    Start → All Programs → ESET → ESET Smart Security or ESET NOD32 Antivirus.

    2. Press the F5 key to open the Advanced Setup window.

    3. From the Advanced Setup tree on the left, click to highlight Protocol
    Filtering in the context tree on the left.

    4. Change the setting to "HTTP and POP3 ports" from
    "Ports and applications marked as Internet browsers or email clients."

    5. Under Protocol filtering, select Excluded applications, and check
    the boxes for svchost.exe and explorer.exe to keep them from being scanned.

    6. Click OK in the Advanced Setup window to save your changes.
     
  24. rockshox

    rockshox Registered Member

    Joined:
    Oct 23, 2009
    Posts:
    261
    Wow, this could be a huge problem and could possibly answer many posts on these forums related to lockups, freezes, file shares etc.

    The first question I have right off is does this affect Windows Vista, 7 and Windows Server 2008?

    Windows Vista SP1/7/2008 do not have the same Protocol filtering options. However, under the "Excluded Applications" menu item on my Windows 7 x64 box I have a list of items that can be excluded. The description at the top says "Selected applications will be excluded from protocol filtering (HTTP, POP3)". In the list below explorer.exe and svchost.exe are listed. Do these need to manually excluded?
     
  25. jimwillsher

    jimwillsher Registered Member

    Joined:
    Mar 4, 2009
    Posts:
    668
    Not sure what prompted TyeF to respond to a post that's 15 months old, but it does have serious repercussions if explorer.exe is marked as a browser.....
     
Thread Status:
Not open for further replies.