I have logged all of the calls to my overridden methods for my IconOverlay. It appears to be calling the CanShowOverlay() for each file I display in Explorer. And I am verifying that I'm returning the correct bool.
I also have a log statement at the top of GetOverlayIcon(), and this is called for my class when appropriate. However, no overlay icon ever appears in explorer. I have tried displaying small/medium/large icons and "details". I believe I had this working
a day or two ago, and have double-checked that the icon (testing with the same, gold lock from the sample project) is still in my project's Resources, etc.
Is there something caching somewhere, despite me restarting Explorer using "Server Manager"? The code appears to absolutely be returning the overlay icon, and in the Server Manager "test shell", the target/test files show in bold.
Running Win 8.1 x64, VS 2010, .Net4, SharpShell 2.2.
This appears to be really finicky and I'm worried about developing a production implementation with it if it's got issues that aren't easily explained and worked-around during install/register/etc.
Aug 22, 2015 at 5:40 AM
Edited Aug 22, 2015 at 6:04 AM
I had this problem. This is my story of trying (and eventually succeeding) to solve it. Skip to the end for the TLDR.
The code ran fine, GetOverlayIcon() was called, CanShowOverlay() was also called. I began to think similarly to you, that perhaps the Server Manager was caching some setting somewhere, messing things up. Installed and registered the dll on my laptop instead
of my desktop. Still not working.
I decided that maybe it was because I was running Windows 10 build 10525, maybe it was a Windows 10 thing, or maybe it was a Windows 10 build 10525 thing. Perhaps Microsoft changed something that made the icon overlays not work, or work differently.
Install/register the dll on a Windows 7 virtual machine. Success!
Install/register the dll on a Windows 8 VM. Success!
Install/register the dll on a Windows 10 (build 10240) VM. Success!
Install/register the dll on a Windows 10 (build 10525) VM. Success!
Alright. Well, maybe it has something to do with having Visual Studio installed (I had both 2013 and 2015 installed), something to do with all the .NET installations? I was definitely reaching here.
Install/register the dll on a Windows 10 (build 10240) VM with Visual Studio 2013 installed. Success!
Install/register the dll on a Windows 10 (build 10240) VM with Visual Studio 2015 installed. Success!
Install/register the dll on a Windows 10 (build 10240) VM with Visual Studio 2013 and 2015 installed. Success!
Ok, what in the flying f?
I turn to Google, searching around for a while. Eventually I come across the tidbit that Windows only supports 15 shell icon overlays at once and ignores all others. Yeah, I read that before, but how many could I possibly have installed? Definitely not 15+.
Download/run Nirsoft's ShellExView, sort by Type, scroll to 'Icon Overlay Handler'.
How many installed? 18. I had 18 icon overlay handler's installed including the one I was trying to get to work, named 'Class1'. Alright, awesome. This is it. This is the answer. I figured it out. But hang on, why is mine not
loaded, despite being toward the top of the list alphabetically? I dig a bit deeper, find the registry key where these are stored:
Some of these are named differently from what appeared in ShellExView, but the CLSIDs correspond to what I saw in ShellExView. Interestingly, they are in a different alphabetical order than what appeared in ShellExView, and not just because some have a different
name. Several of these have a space added to the beginning of the key name so they are sorted higher on the list. All of the OneDrive and Dropbox keys have a single space added to the start while the Google Drive keys have
two spaces added to the start so they appear first (Google just
has to be first huh?).
I disable several of these extensions via ShellExView.
Install/register the dll on my original system - Windows 10 (build 10525).
BAM. Mystery solved. I hope this was an enjoyable read, but moreso I hope I save someone several otherwise wasted hours.
Also noteworthy: when the extensions are disabled via ShellExView (and perhaps in other ways), the keys remain in the previously mentioned registry location (...ShellIconOverlayIdentifiers). It turns out that the keys don't get deleted, but a new key gets added
to the following location to mark it as blocked:
TLDR: Check how many icon overlay handlers you have installed on your system. Seriously. Check.
Awesome thanks for the detailed response - turns out had the same thing - on a new machine had move than the 15 Overlays! (Tortoise SVN takes up 9)
Also you can just rename the folders in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers and top 15 are shown.