4

The Microsoft Documentation reads:

Notification icons specified with a GUID are protected against spoofing by validating that only a single application registers them. This registration is performed the first time you call Shell_NotifyIcon(NIM_ADD, ...) and the full path name of the calling application is stored. If you later move your binary file to a different location, the system will not allow the icon to be added again. Please see Shell_NotifyIcon for more information.

Since the documentation on Shell_NotificyIcon is rather sparse on how to unregister the GUID again, the following question arises: How do I properly remove the NotificationIcon again when I uninstall the corresponding app again?

There is the brute force approach which is described here, which deletes all system icons and the process explorer.exe must be restarted again. However I'm wondering if there exists more punctual approach.

Another option would be to just create a new GUID, every time a user installs the application or moves it to a new location. Is this considered best practice?

elvenking
  • 97
  • 6
  • Doesn't `NIM_DELETE` do that? – IInspectable Aug 12 '22 at 13:34
  • 1
    I have never seen spoofing in the real world. I never use a GUID and just code it like its 1995. – Anders Aug 12 '22 at 13:37
  • That spoofing protection is really odd. What if the spoofer registers first? What if they copy the icon resource bits and register their copy? Even if Windows binds the guid to a hash of the image, increasing the hue of a single pixel by one unit (undetectable to the human eye) changes the hash. – ixe013 Aug 12 '22 at 13:52
  • 1
    @ixe013 I assume it stores the exe path + GUID, not the icon image. The optimal icon image size would change if the user changes the DPI etc. – Anders Aug 12 '22 at 13:54
  • @IInspectable No, NIM_DELETE removes it from the taskbar but it does not delete it from the registry (a value named something like "PastIconStreams"?). The whole point is to keep this information around so Windows can remember if the user has promoted/hidden your icon the next time your app runs. – Anders Aug 12 '22 at 14:02
  • I would just create another GUID since the old one is highly unlikely to get ever reused. Plus, judging from the way Windows handles shellicon notifications nowadays, I wouldn't use such notifications at all. – Michael Chourdakis Aug 12 '22 at 14:57
  • 1
    Right, @and, so this feature is largely useless (outside of Authenticode). – IInspectable Aug 12 '22 at 16:50

1 Answers1

2

10 year old answer from a Microsoft employee speaks of a possible workaround when changing the path and at the same time claims there is no way to unregister:

There is no way provided to unregister that. If your binaries are Authenticode signed then the registration can move with the application. See the Troubleshooting section in the NOTIFYICONDATA documentation.

Note The only exception to a moved file occurs when both the original and moved binary files are Authenticode-signed by the same company. In that case, settings are preserved through the move.

Both binaries would need to be present simultaneously when the icon is created for the path to be updated.

I personally never use a GUID, I just use the classic ID mode from Win95.

Anders
  • 97,548
  • 12
  • 110
  • 164
  • 2
    "*I personally never use a GUID, I just use the classic ID mode from Win95*" - +1. There are too many restrictions and gotchas introduced by using a GUID to identify an icon. It is just not appropriate/worthwhile for most use-cases. Using the HWND+ID instead works just fine in most use-cases. – Remy Lebeau Aug 12 '22 at 18:07