Right after resuming Windows from hibernation the dialog from CAV 5 pops up saying that shell32.dll could not be recognized and is requesting unlimited access. The info states that “Although Microsoft Windows has digitally signed their application, they are not yet whitelisted by us.”
Every time I select always trust the publisher of this file, but the dialog still returns.
Possibly try going to Defence+/Trusted Files/Add/Browse to shell32.dll and manually add it.
Also could you check something. Go to Defence+/Computer security policy->Double click the line “All Applications”->Click “Customize”->Click on Modify next to Windows/WinEvent Hooks and see if shell32.dll is listed.
My computer security policy looks the same. The file is listed under “Trusted Files” already.
I also added shell32.dll as a “Windows System Application” under Defense+ Rules but the dialog was still displayed after that.
Another strange thing is that the dialog doesn’t seem to pop up consistently. The last 3 resumes from hibernation with one reboot in between didn’t produce it.
A minor issue with “Access Memory” Defense+ events from Process Explorer is that they won’t go away after following this guide.
There are no less than five additional entries called “@Microsoft Windows” under Trusted Software Vendors and defined by USER. Could it be that Comodo is missing some certificates that should be whitelisted? Too bad it isn’t possible to get any more information on those entries.
Recently Defense+ sandboxed a .NET Framework application because it wasn’t recognized. It seems Comodo likes to do those things at random. The file, called dw20.exe (C:\Windows\Microsoft.NET\Framework\v2.0.50727) and being digitally signed could not be added as a trusted file because it already is a safe file. Sounded a little different a minute ago when the file was being sandboxed, but okay.
I would really appreciate some help. CAV now even sandboxed the file after I removed it from trusted files and also deleted the five user created Microsoft Windows Trusted Vendor entries.
What should I configure so Comodo will leave this file alone?
It is added as Installer/Updater currently
Can’t be added as a trusted file because it is already safe
Can’t be added to the Trusted Vendor list because already listed
I have shell32.dll modified with custom icons. That is probably why it could not be rocognized. It is not certified/signed.
The only way to have Comodo “leave this file alone” is to add a rule in Computer Security Policy/Defense+ rules for shell32.dll as “Installer or Updater”. Then if you have check “Automatically detect the installers / updaters and run them outside the Sandbox” in sandbox setting - Comodo will “leave it alone”.
I did not find any other workarounds working in my situation.
Shell32.dll is already configured as “Installer/Updater” and is neither not the original Windows file nor being modified constantly.
What I did uncheck however is the “Automatically detect the installers…” option because it seems like the recommended thing to do, even though I am not fully sure about what this thing actually does.
The “unlimited access” and sandboxing of shell32.dll was going on before I unchecked that option so turning it back on should have limited effects, but thank you for your suggestion I will try it anyway.
No luck with the “automatically detect installlers” option either. It again sandboxed shell32.dll and just a minute ago the exact same dw20.exe. Doing an online lookup on the file while it was still running in the sandbox came back “safe” and the file was moved to my local database of safe files… or whatever. Hopefully when 5.1 or 6 comes it the issue will magically disappear because nobody else seems to have an idea either.
They have been sandboxed several times since my post from the 13th, the OS was rebooted in that time also.
Now I have also manually added shell32.dll into the list mentioned by Matty_R.
Also could you check something. Go to Defence+/Computer security policy->Double click the line “All Applications”->Click “Customize”->Click on Modify next to Windows/WinEvent Hooks and see if shell32.dll is listed.
To my surprise Comodo allowed me to add the file. It’s now listed as C:\Windows\system32\shell32.dll as well as the default entry. Maybe that will help.
You said that is a fresh system. My problems with shell32.dll disappeared after I did windows updates. Now no notifications anymore from Comodo. Also I removed all rules shell32.dll and removed it from trusted files. So no special rules etc. just default in Comodo, no need to put in trusted files etc… No problem , no notifications, alerts at all. Proactive configuration and defense + on safe mode.
Thank you for the utility. So I check with that utility the shell32.dll from before windows update (I admit that I do update quite rarely and manually) and it was not signed (custom icons I downloaded it from net) and after update is now signed. The updating did not change the icons etc. just “signed it”.
Thats the only difference visible in your utility under verified: - that one before not signed and after update become signed by Microsoft etc. Publisher in both was Microsoft the same.
So I assume that is why Comodo alert and sandboxed before update.
Shell32.dll got sandboxed again. Made another interesting observation. Ignoring the sandboxed popup and letting it disappear, the file isn’t listed under unrecognized files or at “x files will be treated as partially limited and sandboxed”. Nothing is there.
Only the log has a new line saying that shell32.dll was sandboxed.
