FileShortcut entries buildup in [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\UFH\SHC]

[frnds1]

There appears to be a buildup of FileShortcut entries in the registry under [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\UFH\SHC

For all the tests run so far, uninstall invoked from Apps->Uninstall removes the files from the system and entry in the Apps list. However, there appears to be data left behind in the registry.

What would be the cause and remedy for these residual shortcut entries? Are there other registry references to these entries or can they be deleted manually without issues?

[oleg-shilo]

Sorry, I do not have the answer. But I simply checked this registry key and in my case, it contains Install RELEASE (Ubuntu).lnk and no other shortcuts even though I have plenty of installed apps with the shortcuts.

[frnds1]

Thank you. What I have observed is that when you install, the registry definitions for the shortcuts land here and when you uninstall, they should be removed. Auto removal happens for Uninstall shortcut, but not the program shortcuts. It doesn't matter how I define the program shortcuts (FileShortcut or ExeFileShortcut) the behavior is the same. I also noticed the uninstall shortcut has a GUID as part of its string entry and the app shortcuts do not.

I noticed in the Wix website example, that the app and uninstall shortcuts are defined with a single registry key declaration. I also noticed that Wix RegistryValue type is Integer not String.

Could this be a 5.0.2 interference issue? The builds (Wix#3 and Wix#4) are against the current install which is 5.0.2:
1>Compiling myapp.wxs
1>Source base directory: C:\Users...
1>Wix version: 5.0.2

[oleg-shilo]

I looked at the generated wxs of the Shortcuts sample and in both cases (uninstall and app shortcuts) the same WiX element Shortcut is use and no GUID of any sort is provided. The only difference is that in the case of app shortcut, the effective target file is the parent XElement File and in case of uninstall the target is the external file on the target system defined as a Target attribute ([System64Folder]msiexec.exe). All seems OK. Even the MSI Shortcut table looks OK:

Thus the different outcome can only be caused by the way MSI deals with the shortcuts. BTW, WiX can do plenty of "black magic" but I am not sure it is the cause of the problem. I would think more of MSI as a suspect. But I can be wrong.

[frnds1]

Thank you. I noticed all my links have prefix links in their name where your example only has it for Uninstall.

[oleg-shilo]

You can try the very same examples. What I shared with you is the investigation of the msi produced by the Shortcuts sample compiled with WiX v5.0.0 toolset.

TBH I am not sure that prefix would make a difference.