v2.5, "WCESCOMM.LOG" is constantly scanned

Hello,
Since upgrading to 2.5 (clean install) when I open my AMON window, I see that it is constantly scanning the file:

C:\Documents and Settings\<my account>\Local Settings\Temp\WCESCOMM.LOG

I then tried adding this file to the EXCLUDE list, which does not seem to work. Also I noticed in the EXCLUDE list, that everything was in ALL CAPS. I thought I remembered reading a while back there was problems with the EXCLUDE list dealing with long file names etc. But I assumed these would be fixed in 2.5.

Am I doing something wrong or is the exclude list broken?
fyi, the "WCESCOMM.LOG" file is part of ActiveSync 3.8 afaik.

***EDIT: perhaps I did not name this thread properly-- the real question I have is regarding NOD32's "exclude" funtion and why it doesn't seem to be working properly. If anyone has further info on that I would appreciate it.

 

Wcescomm.exe is the Windows synchronization manager for Windows CE-based handhelds. It is used to synchronize the content on your handheld with your PC. Stopping this process when your PC is connected to your handheld may cause errors.

That pretty much says it all. I assume you have a handheld device that is not attached to the computer when this is going on. NOD will scan whatever file is being accessed at any given time. Is there a way to not load this program upon bootup so that is will not constantly look for an external device?

 

Update!

This file appears to be part of windows itself. My advice would be to do some research through google.com. I'll look around some more.

 

http://www.answersthatwork.com/Tasklist_pages/tasklist_w.htm

and


http://www.answersthatwork.com/Downright_pages/downrights_a-z.htm


Good luck

 

thanks for those links-- they are interesting. But, the real point of this thread is perhaps why the NOD32 "exclude" function is not working as expected.

 

Try this thread and the other one it links to for a bit of detail that may be of interest
https://www.wilderssecurity.com/showthread.php?t=63303

 

Have you tried to exclude it in AMON both in long and in short file-name?
Maybe that would help.......

 

I don't know if you can exclude a "Temp" folder or file, I wouldn't advise to do so, I think it is a dangerous idea.

Cheers

 

I agree with you about adding Temp files to the exclusion list, it seems like a security risk. I am not sure of any other way, I guess I will just let it constantly scan. Seems like an awful waste of CPU resources. I thought that one of 2.5's new features was that it would not scan the same file twice unless the file had been updated/modified. Has anyone actually verified if this is working as intented? I am not sure that it is.

But I am not sure why even to this day with many versions, do we still need to cumbersomely (sp?) add double entries for all files on the exclusion list. If this is somehow required by AMON, can it not do this "behind the scenes" on its own?

 

WCESCOMM.LOG is continuously modified while there is a device connected. I don't believe it would normally be a problem to exclude this log file, but I agree with Blackspear also - not a good idea to exclude the whole temp directory.
Other than just excluding the individual file as linked to above you can try altering your device update schedule in ActiveSync to either 'Only Upon Connection' or 'Manual' and that should slow its recursive scanning down a bit.

 

Here is how I got it to work.... here

here is what you have to do...:

To definately exclude a file from scanning by AMON, it has to be entered twice. Once in todays naming convention, (complete path) and once in the 8.3 naming convention. (complete path)

Funny you have to add to twice "one each way"... but it works

I put in c:\docume~1\myname\locals~1\temp\wcesco~1.log

 

From the NOD32 Help file "In the case of folders with long name exceeding 8 characters, you might need to exclude both the short and long folder path (e.g. C:\Program files\Eset as well as C:\Progra~1\Eset)."

Glad to hear it's all sorted

 

OK thanks I will try that. But I guess my question is "why"... can't this be done for us automatically "behind the scenes". It is tedious to have to enter each exclusion twice. For such an awesome program it would seem they could come with a nicer solution than this...

 

Slightly off-topic, but -in case you didn't know them- there are several tools with which you can easily get the short file name.

See those two threads:

https://www.wilderssecurity.com/showthread.php?t=49741

https://www.wilderssecurity.com/showthread.php?t=13098

I myself use Ninotech Path Copy on my W98SE machine.
I have posted about it in that second thread.

In that first thread you will see also other tools mentioned.

Just only for your info

Cheers, Jan.

 

Thanks for that Jan.

Cheers

 

It's being scanned because ActiveSync keeps updating this file for comm errors. This is just poor practice by msoft for not providing a "no log" function in ActiveSync

 

Humm.. no worky?

Has anyone gotten this to work with the latest version of NOD? "v2.50.25?

This worked for me with the earlier versions, but since the last update "before last" "2.50.12", I haven't bothered to exclude it again since it doesn't seem to really affect anything.

AFter reading this continued thread... I went ahead and entered it again both ways and it won't work.... even after turning off nod and back on again.
Here are the path names I chose.
c:\docume~1\"myname"\locals~1\temp\wcesco~1.log
I browsed to the file name for the second entry.

I also deleted both and switch the order ... ie: short first, long second vs. the other way around.. still no affect.

I presume it has something to do with the loacation of the file... its in a somewhat protected area that is normally hidden on networks.... that is anything in "documents and settings" is hidden unless you have chosen to share everthing with everyone on your network?

I have not tried to share everything to see if that works... it appears I cannot find where to do that.. I suppose I would have to delete my account from the computer and make a new one..... Its not worth it to mess with that since I have a server etc running I don't want to disturb any of that.

NOD may need to do some experimenting with excluding files that are in the protected area of "documents and settings" to see how they can fix this?

Its a piece of cake getting files in unprotected areas to work.

The inner workings of all that gets quite complicated above my head.... "event settings" etc all have a play in what is shared on the network.

I may be barking up the wrong tree and chasing a cat instead of a squirrel, but thats all I can make of it?

If anyone has actually gotten this to work with the latest version "presently 2.50.25" please post it.
thanks...

 

I say, I say, boy. You a' barkin' up the wrong tree with that, chasin' a cat instead of squirrel. You're a chicken, not a chicken hawk! (Sorry, that just sounded too much like Foghorn Leghorn for me to pass up. )

Actually, NOD32 does not care if the file is hidden or in a "protected" area, just as long as it is actually accessed. The whole C:\Windows folder is also "protected", and that certainly gets accessed by NOD32.

Try this. Go to Start --> All Programs --> Accessories --> Command Prompt. Type in dir %TEMP% to go straight to your temp folder. Now type in dir /x WCESCOMM.LOG . This will give you the 8.3 format of this file. It could be that it has changed to c:\docume~1\myname\locals~1\temp\wcesco~2.log .

Actually, now that I look at it, I am not even sure why the filename would have to be mangled, since WCESCOMM.LOG is already in 8.3 format. Maybe it has changed to \docume~1\myname\locals~1\temp\wcescomm.log .

 

Well I tell ya boy.. you just a be a cottin pikin genius!... that part about using the straight name and all... \docume~1\myname\locals~1\temp\wcescomm.log

That really worked?... humm.... I sure thought I used the other name before.. but I could be wrong... If I was, it would be the first time I was wrong since the last time!!!

Anyways.. thanks for the help..... seems we've solved another mystery in the wide world of cyber!