Decided to see if updating KeePass would help.

Downloaded zip fil.

extracted files into D:x

unblocked all files   (Right click > properties > unblock)

Deletedcontents of  c:keepass

Copied, and on second attempt moved, the files from d:x to c:keepass

Tried to add c:keepasskeepass.exe to Webroot Application Protection.

Webroot added d:xkeepass.exe

 

So, I copied procexp.exe (process explorer) to c:keepass and adding it as a protected application worked as expected.

 

---

Final weirdness.

D:x was deleted

The downloaded zip file was copied from c:<name>dlsoftware to c:keepass

extracted all files overwriting existing files.

deleted the zip file

adding c:keepasskeepass.exe but webroot added d:xkeepass.exe

 

next attempt.  Deleted all files from c:keepass

unable to delete or rmdir the folder because it is in use.  Process Explorer can't detect the program locking it..

Reboot.  Delete keepass

d:x is still deleted...

c:<name>dlsoftwarekeepass.zip was extracted to c:keepass

adding c:keepasskeepass.exe but webroot added d:xkeepass.exe

The zip file never existed on drive D:

 

Why would Keepass keep thinking, at this point, c:keepasskeepass.exe is in d:x\keepass.exe?

 

Of course, given the nature of keepass.exe I am concerned about malware.

 

---

great...

Last night adding c:keepasskeepass.exe to Application protection KeePass would add d:x\keepass.exe?

Two hours later the automated backup backed up that folder to W:DC 2013-10-27 03;00;05 (Incremental)KeePass

now.

adding c:keepasskeepass.exe to Application protection KeePass adds  W:DC 2013-10-27 03;00;05 (Incremental)KeePassKeePass.exe.

 

I really, really, don't understand this!

---

Did you install it from the D drive at anytime and if you did that's why as it goes by the Hash of the file in that location on D drive. But to correct this make sure you have KeePass installed correctly, then Download a fresh copy of WSA here and make sure you have a copy of your keycode then Uninstall WSA and Reboot and then install WSA with the new installer and let it finish it's install scan then Reboot again then add KeePass to the ID shield and it should say from the correct Directory on the C drive! I know it's the only work around but it is still protected even though it does not indicate the correct location. When I update Firefox then I look at the ID Shield it shows from the Temp File location but it is still protected.

 

HTH,

 

Daniel 😉

---

Once again, Triple, Thank you!

While I have responded to each question/comment in your post, the only thing I would like for you to read is the first question because of the comment and question that follow.

 

Q: Did you install it from the D drive at anytime and if you did that's why as it goes by the Hash of the file in that location on D drive.

A: Yes.  The portable version of KeePass is being used which means extracting from a zip file into any folder.

Comment.  When I think hash, I think checkup (MD6, SHA-1, SHA-256, etc.) which have nothing to do with the location of the file.

Question: Can you explain this?  Installed KeePass by copying the files from d:x into c:keepass so WSA used d:x then, after Cobian Backup copied the KeePass file from c:keepass into w:folder so now WSA uses w:folder.  Go ahead, tell me you guys are just messing with me!  :D  Seriiously, I don't even know what to search for to find out about this behavior.  More importantly, Process Explorer was extracted from a zip file and copied into c:keepass folder and WSA had no issues knowing where the program existed.  

 

Q: make sure you have KeePass installed correctly

A: heh, old-school install.  It works from any folder including from a USB drive.

 

Q: reinstall WSA add KeePass to the ID shield and it should say from the correct Directory on the C drive!

A: That worked.

 

Q: I know it's the only work around but it is still protected even though it does not indicate the correct location. When I update Firefox then I look at the ID Shield it shows from the Temp File location but it is still protected.

A: Thanks for this information.

 

 

---

Your very welcome and yes when I said hash I did mean MD5 Hash please see here!

 

HTH,

 

Daniel 😉

---

Thanks for the link.  The comment (full comment copied below) about "first filename" is incorrect since, in my case, it recorded either the first instance or the backup of the second instance of the program.  Yet, it doesn't do this for all programs as shown by process explorer.

 

"Yes, and you are correct in your speculation. It protects based on file hash. It only records the first filename it sees for that hash locally, not the current location of the (or all) files that have that hash."

 

 

---

Well it was as close as I could get the info maybe someone from Webroot can comment to give even more information to make it more clear for all of us? :D

 

Daniel

---

heh

 

With the information you provided I'm asking a couple of friends if they can elaborate.

 

You resolved my concerns (in record time).

 

Thanks!

---

Us volunteers try our best to help others when we can!

 

Thanks,

 

Daniel 😃

---

ROFL.  I was going to post a follow up.

 

I now sort of understand what was meant by, "It only records the first filename it sees for that hash locally, not..."

 

"It" is looking up the hash value in a lookup "table" and returns the file and path it first finds in the table.  The table is not necessarily in an order we would expect it to be as evidenced by two files starting and ending in the same folder but the lookup returns different folders for each file.

 

if I find a better explanation it will be posted here.  Look, I had 5 hairs left when this started and I'm now down to 2.  Perhaps the information will help others keep all of theirs.  ;P

---

ROFL and thanks for the extra info at least you have 2 hairs more then I do! :D

 

Daniel XD

---