shell32.dll could not be recognized

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.

Here some file hashes:

MD5: 8679917A54A08CE5B923A2D0A511BABD
SHA-1: 2328AE3D88439369EE7AF25D48C91AA3D5F1FF96
SHA-512: 5474BAD8DD3087C030B4560E4713BCC121F8210F718715FC0E8F3D42C3048BB5C913DA8F72B44B19EC677C90526721530BCC4BC2355E6DB9727779B59B58D321

It’s a Windows 7 HP 32-bit file from a fresh OEM install.

Not seen this one before!

Files are the same Win 7 32Bit

File: C:\Windows\System32\shell32.dll
Size: 12867584 bytes
File Version: 6.1.7600.16385 (win7_rtm.090713-1255)
Modified: 27 July 2010, 15:03:24
MD5: 8679917A54A08CE5B923A2D0A511BABD
SHA1: 2328AE3D88439369EE7AF25D48C91AA3D5F1FF96
CRC32: E1911954

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.

[attachment deleted by admin]

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

[attachment deleted by admin]

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”. :wink:

I did not find any other workarounds working in my situation.

See picture.

[attachment deleted by admin]

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. :slight_smile:

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.

Now they are found safe. What happens when you reboot the computer? Do they get sandboxed again or not?

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.

If it works, this makes sense I think.

CIS detects hooks as suspicious. This may over-ride trusted status on a fail safe basis.

A sensible thing to do with a suspicious file is to sandbox it.

By default shelll32 is listed as a shell exemption and so does not get flagged as suspicious.

Did you remove shell32 from this list or maybe update/import a 4.x setting?

Best wishes


Nope, fresh computer, fresh install, fresh Comodo 5. :slight_smile: I only started changing the configuration after getting the first message about shell32.dll.


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.

Maybe that help.

Maybe a first step in understanding what is happening would be to do an indpendant file signature check. I have a utility here.


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.

Glad it worked. You assume correctly I think.

Best wishes


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.