Determining (Almost) Any Shortcut's Target

Wednesday, December 19, 2018

Find the mark every time!

Here is another great utility that hits the mark from Jacques Bensimon

So you’ve installed a Windows application, and now you’re interested in knowing the target executable of one of the shortcuts that were created (to avoid a nasty surprise with a Startup shortcut, for example), but when you look at the shortcut’s Properties, you see something like this, a grayed out product name rather than an executable target:

image

Internally, such “Windows Installer shortcuts” contain a Product Code, a  Feature ID, and, generally, a Component Code (for more information about Installer nomenclature and other useful info, see this previous post).  In the rare cases where the shortcut is missing the Component Code (as determined by the API function MsiGetShortcutTarget), it can be retrieved (as part of a base-85 “Darwin Descriptor”) and decoded from the Registry using the Product Code and Feature ID.  Once the Product Code and Component Code are in hand, a call to function MsiGetComponentPath determines the path to the target executable.  And this is what the IPM console utility LnkTarget does for you.  For completeness, the utility also works with traditional shortcuts that have an explicit target.

image

Notes:

  • The download archive contains 32- and 64-bit versions of the utility.  Use the appropriate one for your operating system’s bitness, not the application’s.
  • To identify the target of an Installer shortcut, the utility must be run on the machine that has the application installed.  The API functions involved are very much dependent on the Registry information associated with the installed application.  This is why viewing the Properties of an Installer shortcut belonging to a non-installed (or uninstalled) application shows an entirely blank Target field.
  • What shortcuts doesn’t the utility work with?
    • The exceedingly rare Installer shortcuts that are both missing a component code and where the component code isn’t retrievable from the expected Registry location, necessitating a key-by-key search.  It didn’t seem worthwhile to implement this feature (maybe someday).  <- [Editor’s note: Hit JB up on Twitter with examples if you need this feature!]
    • UWP (Modern/Metro) app shortcuts, like for Edge.  Don’t get me started on those :(, though I may at some point create a utility to generate “normal” Explorer shortcuts to UWP apps (those that have an associated protocol defined in the Registry are easy, the others not so much).

JB

Be sure to follow Jacques on Twitter at @JacqBens.

Previous
Next Post »