Exclusion Problem

[WilliamP]

I know that this has been posted before,but not solved. I have even downloaded a little program to copy and paste the DOS work around and it still won't work. Had to get rid of BOClean 4.11 because of excludes. When will this get fixed. I have Windows XP Home Edition SP1a

[sig]

Theoretically the exclusion issue was supposed to be fixed in a program update issued months ago as I recall. But that still didn't work according to people with problems. I doubt you'll get an answer here from ESET other than "We're aware of it and rest assured we're working on it. We have many more important things to deal with first." Which one might not unkindly suggest is the gist of most answers to any "when will it be fixed" questions.

Have you contacted support at PSC for BOClean to see if there's anything they can do for you? Some setting or whatever that may help? If you haven't contacted the BOClean folks I definitely would just in case they have a recommendation.

Frankly, I have BOClean and I wouldn't stop using it because of a conflict with NOD. I'd get another AV first. That would be my recommendation. YMMV

[WilliamP]

Well SIG ,I had BOClean 4.10 and didn't seem to have a problem. Then I downloaded 4.11 and I couldn't do anything. The computer would lock up no matter what I tried to do. The good folks at BOClean refunded my money and I purchased TDS 3.

[jan]

Hi William,

I know there was a long discussion about this problem. The solution is not so easy as it looks like. The appropriate developer promised he will put more comments on it at the end of this week.

Thx, :)

jan

[optigrab]

Taken from my post on another thread...

"...here are the exclusions I've worked out to keep Amon from constant scanning of Boclean [v4.11] files on my system. You're welcome to try them.

C:\PROGRAM FILES\NSCLEAN\BOCLEAN\BOCLEAN.EXE
C:\PROGRA~1\NSCLEAN\BOCLEAN\BOCLEAN.EXE
C:\WINNT\BOC411.INI
C:\PROGRA~1\NSCLEAN\BOCLEAN\BOCLEAN.DLL

The first two are tricky! I realize they appear to be redundant, but I have confirmed I need both and [humbly] suggest you to try BOTH simultaneously."

YMMV

[NewNOD]

From OptiGrab (how's the vision?):
{QUOTE-> The first two are tricky! I realize they appear to be redundant, but I have confirmed I need both and [humbly] suggest you to try BOTH simultaneously. <-QUOTE}

Yes. I posted the same type of info in a thread regarding exclusions and JV PowerTools. I agree that to get maximum effect (which may still not be the same as if Amon wasn't running), you have to use the "short path name" in conjunction with the "long path name". See here:

http://www.wilderssecurity.com/showthread.php?t=15707

Seems there is some validity as my experience is confirmed by yours, albeit we have used two different pieces of software in our tests (I note from the other thread about JV Powertools that I posted to that JV Powertools runs fine on your system without even bothering with exclusions...interesting).

Later
______________

Jan,

Thanks for posting the info about the developer looking into the "exclusions" issue. I really appreciate the flurry of activity recently regarding certain issues. Now we'll just have to wait to see if the flurry gets results.

Thanks again.

[optigrab]

Hi NewNOD

The vision's cockeyed ;)

Indeed, the varying success of (and the varying necessity for) AMON exclusions are very interesting!

Regards
Optigrab

[jan]

Hi all,

the thing is that the system can access the files on opening/exexcuting/... :

- with a short names path
- with a long names path
- with a path created by combination of these paths

AMON will exclude the file just when the path given in the Exclusion list is the same as the one system is using when accessing the file. Unfortunately it is not easy to find out which path the system uses.

The developer said he will do his best to improve this situation, but he can't say exactly when.

If the problem at your side is very urgent - you can give us the possibility to reproduce it here and try to fix it. (Not much time, but want to help).

Thanks, :)

jan

[nameless]

Well, I would certainly have preferred for the problem to be described, rather than for vague allusions being made, but I take it there is a conflict between BOClean 4.11 and NOD32 2.0.

{QUOTE-> quoting: optigrab link=board=39;threadid=16154;start=0#msg100584 date=1068574419]
Taken from my post on another thread...

"...here are the exclusions I've worked out to keep Amon from constant scanning of Boclean [v4.11] files on my system. You're welcome to try them.

C:\PROGRAM FILES\NSCLEAN\BOCLEAN\BOCLEAN.EXE
C:\PROGRA~1\NSCLEAN\BOCLEAN\BOCLEAN.EXE
C:\WINNT\BOC411.INI
C:\PROGRA~1\NSCLEAN\BOCLEAN\BOCLEAN.DLL

The first two are tricky! I realize they appear to be redundant, but I have confirmed I need both and [humbly] suggest you to try BOTH simultaneously."
<-QUOTE}

Why a short and long reference to BOCLEAN.EXE, but only a short for BOCLEAN.DLL?

[NewNOD]

Jan said:
{QUOTE-> the thing is that the system can access the files on opening/exexcuting/... :

- with a short names path
- with a long names path
- with a path created by combination of these paths

<-QUOTE}

Yes. The first two are easy to see. Just watch AMON in the Control Center as it scans files or use a utility such as FileMon to see how the OS file system is accessed during any particular operation you're interested in observing.

I'm not sure I've ever seen a file path as a combination of short and long, but maybe I didn't look hard enough or pay close enough attention.

Jan also said:
{QUOTE-> AMON will exclude the file just when the path given in the Exclusion list is the same as the one system is using when accessing the file. Unfortunately it is not easy to find out which path the system uses.
<-QUOTE}

Seems like it would be fairly simple to have the user point to the file or folder as usual in the AMON exclusion dialogue, and then have NOD32 programmed to automatically create the short path name behind the scenes. If some are concerned that this would cause dual entries in cases where this wasn't needed, maybe an option could be placed on the interface (perhaps a check box) allowing the user to decide if he wants the short path auto generated on a case by case basis.

I can't comment on the combo short path / long path situation as I've not seen it and don't know if there is a pattern that could be used to auto-generate an entry.

[optigrab]

{QUOTE-> quoting: nameless link=board=39;threadid=16154;start=0#msg101088 date=1068746124]
Why a short and long reference to BOCLEAN.EXE, but only a short for BOCLEAN.DLL? <-QUOTE}
As I said, I have confirmed that on my system (caveat: YMMV) both long and short filenames are required to completely exclude BOCLEAN.exe. It appears that at any given time there might be one or two instances of BOCLEAN.exe running - one runs constantly, while the other runs, then closes, every few seconds. This does not appear to be the case for BOCLEAN.DLL.

As implied by Jan, a certain amount of trial and error is necessary.

[FanJ]

{QUOTE-> quoting: optigrab link=board=39;threadid=16154;start=0#msg101097 date=1068747904]It appears that at any given time there might be one or two instances of BOCLEAN.exe running - one runs constantly, while the other runs, then closes, every few seconds. This does not appear to be the case for BOCLEAN.DLL.

As implied by Jan, a certain amount of trial and error is necessary.
<-QUOTE}

Heya optigrab,

Two instances of BOClean.exe ?
Are you sure? (oops, I myself might well be wrong here.....).
Are you perhaps confusing BOClean.exe and bocsec.exe ?

[nameless]

BOClean.exe doesn't work that way--there is never more than one instance running. BOClean.exe does run alongside BOCSEC.EXE, though.

[FanJ]

{QUOTE-> quoting: nameless link=board=39;threadid=16154;start=0#msg101103 date=1068749895]
BOClean.exe doesn't work that way--there is never more than one instance running. BOClean.exe does run alongside BOCSEC.EXE, though.
<-QUOTE}

Yep, both need to be running ;)

[NewNOD]

Keep in mind that number of instances of a file (for any program) is not related to the number of file accesses and how the file system accesses the file. The latter is important to the exclusion issue, as stated several times in various previous posts. I think those participating in the BoClean conversation understand this, but it may confuse others into thinking that the main point of OptiGrab's post was wrong. Without specific regard to BoClean, he is correct to say that more than one exclusion (of whichever file) may be necessary to achieve the desired effect.

Since the file system of the OS sees the "accesses" as either:

short path
long path
combination of short & long path

AMON also sees these "accesses" as such, and if you only exclude one type of path, it may not be sufficient to effectively exclude the file and prevent the offending behavior for which you were excluding the file in the first place (generally, for me anyway, it's been utilized to prevent stalls / hesitation / hangs / pauses caused when AMON scans files during a program launch). A symptom of not providing AMON with all the file paths will be ineffective exclusion and continuance of the offending behavior.


In my previous post, I mentioned that I was not familiar with the combination paths that Jan mentioned. I went back and monitored the file system activity on my PC during launch of JV PowerTools and here is some of what I found:


The combination path (short directory paths / full file name):
D:\PROGRA~1\JV16PO~1\JV16 POWERTOOLS.EXE

was "accessed" 32 times during program launch. "Access" types are:

FindClose
FindOpen

If someone can confirm that the pattern for all combo paths is "short directory names / long file name", then it seems this could also be auto-generated by NOD32 when the user excludes a file from the exclusion dialogue. I tried running JV PowerTools with this added to my exclusions, and it did not significantly change the launch time...maybe a second or so reduction, but not enough to worry about. However, the two paths below significantly reduce launch time in combination (note that the short-path and long-path "accesses" are in the hundreds, while the combo-path is only "accessed" 32 times...maybe that is significant maybe not). So, if the "combo-path" can be shown to be irrelevant, maybe a good compromise fix for the Eset guys would be to just ignore this part of the puzzle.

The full path:

D:\PROGRAM FILES\JV16 POWERTOOLS\JV16 POWERTOOLS.EXE

was accessed 264 times. "Access" types are:

Attributes
Close
Read
Seek

The short-path:

D:\PROGRA~1\JV16PO~1\JV16PO~1.EXE

was "accessed" 664 times. "Access" types are:

Attributes
FindClose
FindOpen
Read - majority of the file activity was this type

[NewNOD]

One important addition to my comments:

Regardless of the fix Eset implements, whether similar to suggestions here or something completely different, it will always be up to the user to determine which file or files to exclude in order to achieve the desired result. Not being able to properly identify the file or files may give the impression to the user that the AMON exclusions functionality doesn't work. Removing the obstacle of having to manually enter multiple path names will greatly increase the chances of successful exclusion.

I know that this is fairly obvious, but I wanted to make sure it didn't appear that miracles were expected.

[optigrab]

This is a great opportunity for me to learn the significance of what I've observed on my system regarding BOClean. :) Having installed BOCLean under the Administrator accout, but making observations under a Power User account (Win2K), here is what I see:

Windows Task Manager only lists BOClean.exe and BOSEC.EXE processes. However, System Safety Monitor application window shows these processes:
'BOClean.exe' always present
'BOClean.EXE' executing and closing every few seconds.

[optigrab]

In NOD32, with this DOSNAMES exclusion only (C:\PROGRA~1\NSCLEAN\BOCLEAN\BOCLEAN.EXE), here is what flashes across AMON every few secs...

[optigrab]

... and with this LONGNAMES exclusion only (C:\PROGRAM FILES\NSCLEAN\BOCLEAN\BOCLEAN.EXE), here is what flashes across AMON every few secs...

notice they are NOT exactly the same: one is 'BOClean.exe' and one is 'BOClean.EXE'.

So what is happening?

[nameless]

Here's a thought (since all this concern over 8.3 path names versus long path names seems extremely ridiculous to me): Close BOCLean, then open Regedit and go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, and then for the BOCleanautostart value, try putting quotes around the path.

For example, if the path is this to begin with:

C:\Program Files\NSCLEAN\BOClean\BOClean.EXE

...change it to:

"C:\Program Files\NSCLEAN\BOClean\BOClean.EXE"

If the path uses short file names, change it to the above as well.

This may not solve the problem, but it does determine how Windows submits the path to the EXE--so it might have an impact. But if BOCLean.exe is what is launching another copy of itself, this may not matter.

I run Sysinternals Process Explorer, with a 1-second refresh rate. I see BOClean.exe and BOCSEC.EXE running, and that's it. No second instance of BOClean.exe ever launches (and if it did, I am absolutely sure I'd notice, particularly since the entry would turn blood red for several seconds in the display). I'm not doubting what you're saying, please understand--I'm saying our systems are behaving differently where BOClean is concerned, and I'm at a loss as to why!

[NewNOD]

Nameless said:
{QUOTE-> Here's a thought (since all this concern over 8.3 path names versus long path names seems extremely ridiculous to me): Close BOCLean, then open Regedit and go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, and then for the BOCleanautostart value, try putting quotes around the path.
<-QUOTE}

First, it may seem ridiculous, but concern over long and short path names is the only way to currently get the exclusions to work properly in NOD32. The OS file system accesses files using multiple path types and AMON scans all path types used by the file system. It apparently sees each of these as a distinct file, and as such, each path type may have to be added to the "exclusions" dialogue in order to properly exclude what is in reality only a single file from AMON's scan:

It sees D:\PROGRA~1\JV16PO~1\JV16PO~1.EXE as distinct from D:\PROGRAM FILES\JV16 POWERTOOLS\JV16 POWERTOOLS.EXE as distinct from D:\PROGRA~1\JV16PO~1\JV16 POWERTOOLS.EXE (fill in your fav program in place of JV16 Powertools). It sees those paths just as differently as it would see C:\Program Files\Nameless.exe and C:\Program Files\OptiGrab.exe. I don't know how else to explain it.

Second, the Run section of the registry will have no impact on how the OS accesses BoClean.exe when run after the initial start. I'm not even sure your suggestion will have an impact on the actual access during Startup (meaning, will it prevent multiple path type accesses?), but I'll defer to you on that one 'cause I don't have time to check it out....

________________

OptiGrab,

Here is what is happening as far as I know (which may not be very far):

When you only exclude short path:
C:\PROGRA~1\NSCLEAN\BOCLEAN\BOCLEAN.EXE

You can get a variety of mixed upper case and lower case file names (in your instance, BOClean.EXE because this is allowed with long file names. So, that is what you see AMON scanning ... a valid file name under the long file name convention.

When you only exclude long path:
C:\PROGRAM FILES\NSCLEAN\BOCLEAN\BOCLEAN.EXE

You get only BOCLEAN.EXE, which is a valid short file name under the short file name conventions (all caps). It would be easier to see if BOCLEAN.EXE exceeded the max number of characters; for instance, if the file name were BOCLEANER.EXE, you would see AMON scanning BOCLEA~1.EXE.

Example using JV16 Powertools: when I exclude the short path, I see various file names being scanned by AMON including jv16 Powertools.exe and jv16 powertools.exe. When I exclude the long path, the only file seen being scanned is JV16PO~1.EXE.

I have no thoughts on the multiple instances of BOClean.exe showing up on your PC.

[nameless]

I didn't need it explained. I understand what is going on. But how a program is run does have everything to do with how the path appears in memory.

If I run C:\Progra~1\HandyT~1\hndythng.exe, then NOD32 sees the path C:\Progra~1\HandyT~1\hndythng.exe. If I instead run "C:\Program Files\HandyThing\hndythng.exe", that's what NOD32 sees.

That's why I was suggesting using LFN's and quotes on the command line; as a way to ensure that only LFN's were used. If you use a LFN and quotes in the Run value, there is no way that C:\PROGRA~1 [blah blah] will end up going to AMON, at least as far as the startup entry goes. On my system, keeping the BOClean Run value as it is by default leaves me with SFN's being used. By simply putting quotes around it, there are no SFN's anywhere.

It's a good practice to do things that way anyway. And it was just a suggestion.

The bottom line is that Eset needs to correct this bug (yes, bug).

[Newnod]

Nameless wrote:
{QUOTE-> If I run C:\Progra~1\HandyT~1\hndythng.exe, then NOD32 sees the path C:\Progra~1\HandyT~1\hndythng.exe. If I instead run "C:\Program Files\HandyThing\hndythng.exe", that's what NOD32 sees.
<-QUOTE}

I'll have to respectfully disagree with your assessment. I launch programs from icons with the LFN enclosed in "", and detailed analysis of file system access during the launch shows that regardless of the launch command, many things happen behind the scenes that are not controlled and cannot be controlled by the initial command.

For example, launching JV16 Powertools with this command-line

"D:\Program Files\jv16 PowerTools\jv16 PowerTools.exe"

results in many thousands of file accesses, some related directly to JV and others indirectly related (Windows files, etc. are accessed also). Out of those thousands, JV16 Powertools.exe is acted upon 960 times using 3 different path types (all described in detail in a previous post). Those accesses apparently are not controlled by the initial command-line syntax. And, if the file system accesses multiple path types for a given file, NOD32 / AMON will scan each of them.

I can't really test this on a start-up command because I can't observe the behavior using the utility that I have. But I believe that a program launched from a command in the registry will have essentially the same behind-the-scenes behavior as if launched from a shortcut icon. Why wouldn't it?

Maybe I should throw in the good ol' disclaimer that this is how my system is working. Maybe yours doesn't work the same way.

On the agreement side: yes, all of this discussion is related to a bug. It is relative to its current workaround, and it is relative to how it might be fixed.

Later.

[Kevin McAleavey]

I just became aware that this discussion was ongoing as I was pointed to this by a customer. Before I add a possible solution, I want to apologize for what I'm going to say out of concern that it may at first appear as though there is a mean streak behind what I'm about to offer to the Eset people ... so let me get the first part of this out of the way as an explanation first, then I'll provide an offer that might help Eset sold this problem.

In the past, we've had a difficult relationship with Eset where problems have been encountered in earlier BOClean builds. Windows doesn't like too many things poking around, and BOClean, like other security products MUST in order to do its job in an effective manner. COOPERATION is abundantly important, especially when it comes to wriggly things. In the past, when we've tried to cooperate with Eset in order to resolve problems for those of our customers who have installed NOD, the result was less than satisfactory to us - we were met with rudeness, arrogance and "it's YOUR fault, not ours." As a result, BOClean had to be redone.

Now that AMON finally has exclusion capabilities (we've had to add our own as a result of this phenomenon as well) we were beginning to recommend NOD32 when customers have asked us what other antiviruses are out there besides Norton and McAfee. My heart SUNK when I learned that Andreas Haak is part of the Eset operation. We'd LIKE to be able to cooperate with Eset as we do with many other vendors, but this development makes it very difficult. Just wanted to say that and get that out of the way.

Since there is this unnecessary "wall of separation" between our companies, I'd still like to offer an olive branch and a possible solution for Eset under the assumption that it is coded in C or C++ ... two functions, which combined might alleviate this excluder confusion in code - it's something we had to do in BOClean a long time ago to deal with the 95 legacy and NT legacy code of Windows handling things differently, as well as new wrinkles brought about by patches Microsoft has issued recently which break long filename handling where there's spaces in the filename (why oh why couldn't they have called "Program Files" "Programs" and avoided this?)

With all these issues tossed together, a more reliable and consistent way of handling these variations was necessary in order to ensure consistency since BOClean's design requires it to STORE internally "already seen this and it HASN'T changed, no need to sniff at it again UNLESS something's changed" data ... we came upon a solution that I'd like to offer to the Eset "team" ... might be a nice simple way out of this for you folks ...

INTERNALLY (since you're using a device driver core anyway) the 8.3 is what you need, and in order to eliminate the variations with "case" between upper and lower, the "strupr()" function in C combined with the WindowsAPI "GetShortPathName()" function merrily combine for a solution for the stored data as in:

GetShortPathname(strupr(filenamein), outfile, (DWORD)MAXPATH);

The above simple call would convert any input pathname to upper case, then convert it automatically to the 8.3 name using the system's own symantics to ensure that the proper file is there ... that's what we've done for ages and it works.

There is only ONE instance of BOClean running, so I'm at a loss at the moment to figure out how a "second instance" is appearing - that "blip" every few seconds is a run at the registry and newly added dependencies - will look into it since around here, once a new version of BOClean is released, work begins immediately on the next just in case there's a need to release a new "engine" as a result of new developments.

I know we've had a rough time in the past with Eset, I offer this as an olive branch. We're used to COOPERATING with other vendors, sorry the history of our company and Eset has, in the past, been unnecessarily complex. Wasn't OUR choice. :(

[Kevin McAleavey]

Followup for Optigrab ... Figured out what you're seeing (the "n/a's" are a clue) ... apparently System Safety Monitor is being confused by our talking to our traybar icon and assigning a new process tag incorrectly. Might have something to do with the design of SSM doing a "ThreadWindow" monitoring (limited accounts have limited privileges) and getting confused by one "Window" talking to the other internally. Definitely no second process though, just wanted to let you know. Replicated same here. It's SSM getting confused.

[sig]

Thanks for posting, Kevin. Hope this assists ESET since this appears to be an issue for a number of people involving other products (not just BOClean) as well.

Although I must be one of the lucky ones because (so far at least) I haven't had any problems running both AMON and BOClean on XP.

[optigrab]

NewNOD, Nameless, Sig, and especially Kevin,

Thank you so much for the comments offered specifically to my situation.

For the record, I am not troubled by any BOClean/NOD32 interactions. I merely try to employ the exclusion of other trusted security programs for the sake of efficiency. After NOD32 V2 was released (to my recollection this is when the exclusion feature ceased to work as intended), but before the workaround was discovered, there was no issue for me.

What is more troubling for me is the problem with SSM - a problem not previously described in this thread, but here:
http://www.wilderssecurity.com/showthread.php?t=16272

Kevin's reply (although somewhat over my head) at least comforts me in that he understands the technical reasons for the issue. I will forward his comments to Max at SSM. I will also drop Kevin a private note regarding the "09/02 build" of BOClean 4.11 - I'm sure he could tell me if this would help.

Again, many thanks
Chris

[Kevin McAleavey]

Just answered your question in the other message are that you pointed to in your previous. May not be what folks might wanna hear, but I've got brain damage. Reality is reality, but at least it's the truth. :)

Might just be inexperience ... certainly impresses me as a useful utility once the insects are swatted.

[nameless]

{QUOTE-> quoting: Kevin McAleavey link=board=39;threadid=16154;start=15#msg101460 date=1068871508] INTERNALLY (since you're using a device driver core anyway) the 8.3 is what you need, and in order to eliminate the variations with "case" between upper and lower, the "strupr()" function in C combined with the WindowsAPI "GetShortPathName()" function merrily combine for a solution for the stored data as in:

GetShortPathname(strupr(filenamein), outfile, (DWORD)MAXPATH);

The above simple call would convert any input pathname to upper case, then convert it automatically to the 8.3 name using the system's own symantics to ensure that the proper file is there ... that's what we've done for ages and it works. <-QUOTE}

What if the Win2K or WinXP target system has 8.3 file names disabled (as explained in this document (http://support.microsoft.com/?scid=210638))? Wouldn't the above approach fall on its face?

[burma69]

Then you might prefer using of GetLongPathName function exported by kernel32.dll ;)

[Acadia]

"Just when I think I'm out, they pull me back in!"
Michael Corleone, Godfather III

I can’t believe that I about to say what I’m about to say, but I have to get it off my chest and if I regret it, I’ll just delete it, like I have with other posts in the past concerning NOD (I don't like myself when my temper flares up):

In my case NOD and BoClean get along just fine, at least as far as I know. But in the future if there are any problems between the two and I determine that I actually have to remove one of them, based upon the EXCELLENT tech support that I have always received from Kevin and the, um, (Acadia, let’s be nice here), not quite as excellent (that was good, Acadia) tech support that I have received from NOD, there would be no contest between which one stays and which one goes.

Acadia

[nameless]

{QUOTE-> quoting: Acadia link=board=39;threadid=16154;start=30#msg101753 date=1068990928]
In the future if there are any problems between the two and I determine that I actually have to remove one of them, based upon the EXCELLENT tech support that I have always received from Kevin and the, um, (Acadia, let’s be nice here), not quite as excellent (that was good, Acadia) tech support that I have received from NOD, there would be no contest between which one stays and which one goes. <-QUOTE}

Same here. I've been trying (and buying) a slew of anti-malware products lately, and Eset's support is by far the worst of all of them, from what I've seen. I only wish I'd known that sooner.