Network performance problem NOD32 V4

Hello,

we have a Windows 2003 R2 Server (DC) and XP Pro SP3 Clients.
On Clients with NOD32 V4.0.474 (standard config) we have problems with copying small files over the network (we have a programm that creates about 500 small files upon loading a project which usually takes about 5 seconds, but on these machines running V4 it takes about 8 to 10 minutes - you cant work with that programm now).
I did some research and found this:
http://support.microsoft.com/?scid=kb%3Ben-us%3B321098&x=9&y=19
Using xcopy to copy 500 small files to the server takes 2 seconds, but it is slow copying files with the explorer (more then ten minutes). While doing this I get event-id 3019 (MrxSmb) on the client.

After uninstall of NOD32 the problem is gone. Disabling realtime scanner makes no difference. I am now using V2.7, still no problem. This is why I am asking for help her: Has anyone else got this problem? Should I open another support case with Eset?

Thanks.

 

My 1st thought would be a memory issue. Maybe 4.0 uses memory differently and scans more things. I don't know why disableing the real time scan did not work.

I would open a case on line and wait patiently for a call (unlike I did ). There is no sense getting worked up waiting on a call.

 

Have you tried disabling network scanning from the real-time scanner? Have you set up Microsoft's recommended scanning exclusions for Windows systems and domain controllers?

 

On the Server I still use V3 with the settings recommended in Esets KB. Disabling real time scanning on the server makes no difference. On the client I use default settings, but no scanning on network drives.

The Problem seems to be on the client side since uninstalling NOD32 on the client (or using V2.7 instead) makes the difference.
Possibly its a problem with the network filter driver?

I opend a case with Eset on Friday, lets wait and see....

 

Does disabling self-extracting archives, runtime packers or advanced heuristics in the advanced real-time protection setup make a difference? If the problem goes away with v. 2.7 I assume it could be that larger sfx files are scanned internally on create which were not scanned by v2 due to scan limits.

 

I checked this on another client running V4.0.474 (mine is still running V2.7): Disabled the options under advancend settings for real time scanner (without restarting the pc) but made no difference.

The specific program is creating many small, mostly text files on loading a project. For mr I cant see any special on these files (mostly 1 to 5 kB, some are 20 to 30 kB), its only the number (some hundreds) which leads to the long time.

 

So one week has passed since I opend a support case with eset but no response yet (except for the confirmation that they received my mail).

Hm, is this the usual way?
I had opend another case (BSOD eamon.sys) on 10.02.2010, same thing (no respponse yet). Not the way I am used to with other companies...

 

Another week has passed without any news from Eset concerning my support request. Send an eMail yesterday questioning for the status of our problem - no answer.

Is this the usual way Eset is handling support cases?

 

It'd be necessary to convey the files to ESET for perusal. Most likely there won't be other solution than excluding the file extension or the folder containing the files from scanning.

 

Well, that doesnt answer my question:

And if they indeed needed these files, why dont they ask to send them instead of just doing nothing?

As I said there is nothing special to these files, they contain mostly plain text.

This leads me to believe the problem could be like this:
http://support.microsoft.com/?scid=kb;en-us;822219&x=10&y=13

 

I assume that somebody from the US customer care will ask you for details about your ticket and track it down in the system.

Could you confirm or deny that excluding the extension of these files from scanning in the real-time file protection setup makes the issue go away?

 

Well, as you can see looking at my rusty english, I'm not in the US, I'm in Germany ;-)

I send a mail last week asking for the status of our support case but nothing happend. This is the first time I'm in contact with Eset support and it may be the last (in Summer our license expires). Contacting support of other companies like HP brings an answer within HOURS, not weeks or months.

I uninstalled V2.7 and reinstalled V4.0.474 and checked again: Copying a directory with around 500 of these files (which is quite the same like starting the specific programm) takes about 15 Minutes. Then I unchecked "Scan all files" in the real time scanner (and "scan files without extensions" is also unchecked becouse the files dont have extensions), restarted the computer but no difference - takes about 15 Minutes to copy.

 

Could you please PM me your username so that I can pass your complaint to the German distributor for follow-up? We need to make sure that they actually received your request.

This could be considered normal if you're copying a lot of larger sfx archives or runtime-packed files that are decompressed and scanned on file create by default. Try setting a size limit for archive scanning in the real-time protection setup and also disable runtime packers/advanced heuristics on file create (you can, however, enable these options on file execution if it doesn't slow down the performance a lot for you).

 

It makes no difference changing these settings. I can completly disable real time scanner (red icon), copying these files is still slow. Only uninstalling V4 helps.
The files ar not compressed or in an archive.

I will send you a PM with the username und the ticket number.

Thanks for your help.

 

That's really odd. Do you see file names changing and the counter in the Statistics window rising when copying files?