This is actually an old bug that has been going on since I was on vista 32. I have since been on vista 64 and now windows 7 64. What happens can be reproduced this way…
-Create a folder called A.
-Put an .exe into it that upon launch will trigger either a firewall or D+ alert. Let’s call it prog.exe.
-Launch prog.exe. The alert shows up saying that A\Prog.exe wants to do something. Allow it. Close the app.
-RENAME THE FOLDER. Let’s say I rename A to B.
-Launch Prog.exe again. There will be NO ALERTS even though the path B\Prog.exe is different from the former, A\Prog.exe.
-Make Prog.exe trigger an additional alert. The alert WILL BE ATTRIBUTED TO A\Prog.exe.
-Go to Fw or D+ rules, wherever a rule for A\Prog.exe was made and press Purge. DESPITE A\Prog.exe NO LONGER EXISTING IT IS NOT REMOVED.
In other words COMODO just seems to “bind” to a program’s folder by its first name. Subsequent renames OR EVEN MOVES of the folder to another place will NOT break the bond. Except if you move it to another partition. It continues to be identified by its old name and path.
There is one problem of this type I had. I was launching World of Warcraft after some moving around. I was alerted that WoW.exe wants to access DirectX, then the Internet. But I already had a rule set up. So I go into rules and press Purge and ALL of the .exe in the WoW folder show up as missing even though they existed at that EXACT path. I tried renaming the folder and I still got asked that WoW.exe wants to do stuff on next launch. Did it register in Fw and D+ under the new path? No it still registered by its OLD folder name. My only solution was to create a New Folder, move all of WoW into it, and rename that to the old WoW folder.
Creating new folders seems to break the binding as does moving stuff to another drive. Does COMODO bind to something like the folder’s unique file table entry or something?