MD5 based exclusion lists ... please, we need them

Marcos you did not read my post carefully. The drive's letter DID NOT CHANGE. It only changed in NOD's exclusion list. The drive is still I:. It has always been I:. It always will be I:. However NOD insists on scrambling this up for some reason in the various ways I have outlined above. This problem has become so annoying to me that I now just disable AMON whenever I am working with my USB drives. Obviously this is stupid and ridiculous and leaves me wide open to infection but that's what its come to because I cannot seem to get NOD's exclusion list to cooperate. All I am asking for is to hear someone from ESET say "yes we are overhauling this for 3.0 and it will work right, thank you for your patience" I hope this is not asking too much......

 

LuckMan212,

I think what Marcos is trying to say is that NOD32 stores the target drive in "\Device\Harddisk?" format in the registry. HKEY_LOCAL_MACHINE\SOFTWARE\Eset\Nod\CurrentVersion\Modules\AMON\Settings\Config000\Settings --> exc . The exc value will look like gibberish until you double-click it. Once you double-click it, however, you can make out what it says. From what Marcos is saying, NOD32 does not change this value, but it sounds like Windows is changing the "behind the scenes" definition of the I: drive.

To get an idea of what the "behind the scenes" value of the I: drive is, go to the Device Manager and look for your USB drive. In the General tab, look at the value given for "Location" and tell us what it is.

I suspect what is happening is that the "\Device\Harddisk3\...." value changes slightly when you unplug the USB drive and then plug it back in. Windows just assigns it the letter I: each time, since it is the next available letter. However, NOD32 stores the original "behind the scenes" value of the USB drive. Since it does not match anything currently connected to the computer (since your USB drive is now something else), it shows up as the "next" drive letter, which of course is J:.

I have no way of verifying this myself, since I do not have a USB drive. Maybe you or somebody else can. If we can somehow get a handle on what is going on here, then we may find a way to avoid this problem (either from the user end or the Eset end).

 

so if what you say is true then in other words there is NO WAY to make this work and the only solution is to

a) disable NOD when working with my USB drives
b) do not use this particular program (which is actually not a virus but quite a useful program)

Neither of these solutions is very appealing.
Well anyway I have said what I needed to in the previous posts. Hopefully someone at ESET will have seen this and taken it into account for the 3.0 version.

 

I am not sure about NO WAY. Just some way I haven't thought of. There's gotta be a way....

What if you try webyourbusiness's suggestion of forcing the USB drive to a particular letter? Maybe that will force it to stay consistent. Also, try making it something different than I: or J:, just for the purpose of making sure it is something distinct and away from all the other drive letters. Something like U:, for example.

Once you have forced the USB drive to U:, try deleting the existing AMON exclusion and create a new one. I am interested to see if it stays as U:, changes to I: or J:, or does something totally different. Again, I would try this myself, but I do not have a USB drive.

For people who do not know how to force a drive letter assignment in WinXP, a good tutorial may be found here: http://www.nursing.upenn.edu/otis/helpdesk/how-to/map.asp

 

bump... can we get any idea whether to expect this feature to be added to NOD v3.0 ?