Where do Shortcut icons point to? And how would we know? 1

[jsteph]

Hi all,
So I'm in this folder looking at the shortcut file:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\QuickTime\QuickTime Player

...and I'm looking at the Quick Time Player (.lnk file? shortcut? )

Now, I *know* where to find the quicktime install directory in program files (x86). But suppose I didn't? How on earth would I know where that particular shortcut points to? There are two places on the property pages when I right-click on that which show the location *of that shortcut itself*, but nothing that shows where it points to.

And...somewhat tangentially, the "Change Icon" button is greyed out and it has an icon of another completely different program.

Can anyone tell me how I would:
a. Find where a shortcut icon points to.
b. Change the icon of a mis-iconned shortcut who's change-icon button is diabled.
c. How I would even know it's a .lnk file--I set my Folder options to *not* Hide Extensions, but these files still show up as having no extension.

(I'm a user with admin rights).
Thanks very much for any help,
--Jim

 

[rclarke250]

you can right click and choose "open file location" that will tell you where it points to. And you can also choose properties, and if you look at general tab it shows it is a .ink file and also where it points to.

 

[jsteph]

rclarke,
Thanks, but no, I see none of what you describe. Right-clicking on the shortcut gives no "open file location" option.

Choosing properties does show:
Type of file: .lnk
Description Quick Time Player
Location "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\QuickTime"
(the above is the location of the *shortcut*, not the actual .exe file.

In the "Shortcut" tab of Properties, the "Target Location" shows blank, and the "Target" says "Quick Time"

This is just bizarre. Does anyone know how to de-mystify a simple shortcut?

Thanks,
--Jim

 

[linney]

I think it might be an example of more and more programs "using CLSID based shortcuts" as this old XP thread goes into.

Shortcuts now keeping 'Target' a secret??

http://www.tek-tips.com/viewthread.cfm?qid=1268860

If you have a Shortcut on your Desktop you may have more options than if your Shortcut is in "All Programs"

Have a look in these locations, check what Access Permissions your User has. Permissions may not make that much difference but it is something you can look at,

C:\Users\usernamexxxx\AppData\Roaming\Microsoft\Windows\Start Menu\Programs

C:\ProgramData\Microsoft\Windows\Start Menu\Programs

What might make a difference is if you go to the .exe location (if you ever find it) and create new Shortcuts?

 

[PRPhx]

1) Pick a shortcut.
2) RIGHT click on it.
3) Go to Properties, generally the last item on the popup menu.
4) IF the shortcut tab isn't already open, click on it.
5) Look at the "START IN" box. This is where the executable file resides.
6) The Target box will tell you what the actual file name is.

 

[strongm]

You are encountering a feature Microsoft now call "Advertised Shortcuts". A quick Google should tell you a lot more about them.

 

[jsteph]

linney,
That old thread of mine is close--but still no resolution...no way of actually going to the shortcut itself and finding out what that shortcut actually opens. Unless one copies the text of the "target" name and looks through the registry searching on every instance of that name...skipping through no doubt dozens of intances of that name (quick time in this example) until I find the one that has the actual .exe.

And the users\username\appdata\roaming...etc has no shorcuts, the \users\username\StartMenu is itself a shortcut--but says "Access Denied" when I click on it--and I have full-control permissions on that object--which is another frustration for another thread.

PrPhx,
No, that was my whole reason for this post:

1. The "start in" is empty.
2. The "Target Location" is empty.
3. The "Target" just has a 'friendly name' ("Quick Time" in this example.)
4. The "Location" shows the location of the shortcut .lnk file itself.
5. The "Change Icon" is greyed out

And telling me where Quicktime actually is will not answer the central question--I know where quicktime is but there are others I may not know and I'm just hoping there's an easier way to find what's actually going on when you click on something.

Just very frustrating and uncomfortable feeling knowing there are icons and shortcuts all over the place where we have no idea what actual .exe is being launched.
Thanks,
--Jim

 

[rclarke250]

If you don't have the show file location selection when right clicking the shortcut. do this:

Click Start, type regedit.exe and press {ENTER}

Navigate to the following key:
HKEY_CLASSES_ROOT\lnkfile

In the right-pane, create a String value (REG_SZ) named IsShortcut

Exit the Registry Editor, and restart Windows.

Now you should be able to right click the shortcut, choose show file location, windows explorer will open and hilight the executable, at the top of the window it will break down the folder structure so you can see in what folder it resides in.

 

[strongm]

If you are prepared to download the Windows Installer Powershell Module (

http://psmsi.codeplex.com/releases/view/25856)

then the following Powershell Script I've just put together gets you close:

[blue]get-msiproductinfo | where { $_.ProductState -match "Installed" } | fl AdvertisedProductName, InstallLocation[/blue]

 

[jsteph]

rClarke,
This sounds promising...I checked that regkey, and the IsShortcut exists, but has no value.

Should it be "1", "Yes", or some other string, or is it's existence enough? If so, I'm back to square one. I'm a little hesitant to put a 1 or Yes in there without knowing if that's the correct string value.
Thanks for any more assistance,
--Jim

 

[linney]

When you are finished checking out the other suggestions, can you just clarify this comment, "the \users\username\Start Menu is itself a shortcut--but says "Access Denied""

The location I wanted you to check was this one where all the Shortcuts live.

C:\ProgramData\Microsoft\Windows\Start Menu\Programs, and what about the suggestion of creating new Shortcuts, do they have information missing too?


C:\Users\username\ Start Menu is not a valid shortcut, and never will be. This quote from a Microsoft Tech should explain the "Why".

" this is a known and reported issue. It was resolved as won't fix. Here is the reason behind it. "The junctions are there to only provide appcompat for legacy apps and aren’t meant for a user to traverse through. The junctions have been explicitly set to block read through them by setting Everyone Deny Read. The main reason here is because these are just links to the actual location, so you dont want backup tools and other tools operating on your data twice, once from the original path and once via the junctions. There are scenarios where some of these junctions actually form a loop to support the appcompat for the old namespace in comparison to the new and in those cases allowing read through them is disastrous, for e.g. setup was broken for a week when the file system wasnt honorign the deny read.

Also as far as a user goes, you will never see these as they are system hidden, and you will need to take explicit action to see them by default."

Hope this clears up some confusion."

 

[jsteph]

linney,
Yes, the folder:
C:\ProgramData\Microsoft\Windows\Start Menu\Programs

has the shortcuts of which I originally spoke--a subfolder for the apps, ie QuickTime, etc, then the mystery-shortcuts.

As far as creating shortcuts myself--on some, such as the Microsoft Access ones, I have to create myself, since I may require command-line args for those. But the rhetorical question is "how can I create a shortcut if I don't know where the exe is?". If course I can always find the exe, but my original point is--why should one have to scan the registry to hunt down the directory where an exe resides, or more simpler--but still a "why"--is looking through both the Program Files and Program Files x86 directories and hoping I choose the right .exe. For example, some programs have a dozen .exe files or more, and the 'real' or 'main' program exe may not be easily guessed.

And the 64-bit thing was actually part of my original curiosity--it was in part that I had wanted to simply see if my Quicktime was a 64-bit or not, and my first thought was "Well, I'll just look and see if the .exe is in the 64-bit or the x86 Program files directory".

Anyway, being a technical person it's just a bit frustrating when stuff like that is deliberately hidden. I know most people work on their computers for years and have never known or cared where an .exe file is...they click on the icon they're told to and mostly things work fine and it never matters...but as tech people, I think most of us like to look under the hood and don't like it when it's all abstracted away from us. Well, at least that's my feeling.

strongm, Thanks, I will take a look at that, it might be the only solution.
--Jim

 

[strongm]

It won't help. "Advertised Shortcuts" are not real shortcuts, they are Microsoft Installer links, and without querying Microsoft Installer (or trawling the various Installer keys) you can't directly resolve them to the genuine target folder.

You can, however, get the little arrow to appear on the icon, as this is what ISShortcut deals with - or at least it used to. I have a nagging feeling it does something more dangerous in Vista/Windows 7

 

[strongm]

Um ... the above comment of mine was really directed at rClarke250's post

 

[rclarke250]

my info came from here.

http://www.winhelponline.com/blog/open-file-location-missing-right-click-shortcut-windows-7-vista/

there is nothing after the key my understanding is it just has to be there. I will export from my registry. win7 ultimate x64.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\lnkfile]
@="Shortcut"
"EditFlags"=dword:00000001
"FriendlyTypeName"="@shell32.dll,-4153"
"IsShortcut"=""
"NeverShowExt"=""

[HKEY_CLASSES_ROOT\lnkfile\CLSID]
@="{00021401-0000-0000-C000-000000000046}"

[HKEY_CLASSES_ROOT\lnkfile\shellex]

[HKEY_CLASSES_ROOT\lnkfile\shellex\ContextMenuHandlers]

[HKEY_CLASSES_ROOT\lnkfile\shellex\ContextMenuHandlers\Compatibility]
@="{1d27f844-3a1f-4410-85ac-14651078412d}"

[HKEY_CLASSES_ROOT\lnkfile\shellex\ContextMenuHandlers\NvAppShExt]
@="{A929C4CE-FD36-4270-B4F5-34ECAC5BD63C}"

[HKEY_CLASSES_ROOT\lnkfile\shellex\ContextMenuHandlers\OpenContainingFolderMenu]
@="{37ea3a21-7493-4208-a011-7f9ea79ce9f5}"

[HKEY_CLASSES_ROOT\lnkfile\shellex\ContextMenuHandlers\{00021401-0000-0000-C000-000000000046}]
@=""

[HKEY_CLASSES_ROOT\lnkfile\shellex\DropHandler]
@="{00021401-0000-0000-C000-000000000046}"

[HKEY_CLASSES_ROOT\lnkfile\shellex\IconHandler]
@="{00021401-0000-0000-C000-000000000046}"

[HKEY_CLASSES_ROOT\lnkfile\shellex\PropertySheetHandlers]

[HKEY_CLASSES_ROOT\lnkfile\shellex\PropertySheetHandlers\ShimLayer Property Page]
@="{513D916F-2A8E-4F51-AEAB-0CBC76FB1AF8}"

export your key from the registry and compare the two. you can use notepad to open.

 

[jsteph]

rclarke,
My regky dump is identical except for the key:
[HKEY_CLASSES_ROOT\lnkfile\shellex\ContextMenuHandlers\NvAppShExt]@="{A929C4CE-FD36-4270-B4F5-34ECAC5BD63C}"

I'm not sure but it might be an Nvidia specific thing.

In that link you provided I tried the reg fixes, but my machine said the keys were in use and couldn't be written--I also tried it in safe mode but same error there.
--Jim

 

[strongm]

It won't help. "Advertised Shortcuts" are not real shortcuts, they are Microsoft Installer links

 

[strongm]

After playing around with MSI a little bit more (on the basis that since MSI knows not just the Target Folder but, presumably, the eventual target exe that would start the target program) I have come up with the following (VBScript solution)

[blue][green]' GetRealTarget.vbs
' This version needs to be run under wscript engine rather than cscript

' Pass the full path to an MSI "Advertised Shortcut" lnk file (including the extension) as a parameter
' e.g. assuming that we have a default install of Office 2003 for All Users:
' GetRealTarget "C:\Documents and Settings\All Users\Start Menu\Programs\Microsoft Office\Microsoft Office Excel 2003.lnk" 
' Displays fully resolved target for the MSI shortcut[/green]

Option Explicit
Dim MSITarget

On Error Resume Next [green]' just some simple error handling for purposes of this example[/green]
If wscript.arguments.count = 1 Then [green]' did actually pass an MSI advertised shortcut? Or, at least, a parameter that could be such a thing?[/green]
	With CreateObject("WindowsInstaller.Installer")
		Set MSITarget = .ShortcutTarget(wscript.arguments(0))
		If Err = 0 then
			MsgBox .ComponentPath(MSITarget.StringData(1), MSITarget.StringData(3))
		Else 
			MsgBox wscript.arguments(0) & vbcrlf & "is not a legitimate MSI shortcut file or could not be found"
		End If
	End With
End If
On Error Goto 0[/blue]

 

[jsteph]

strongm,
Yes that worked, and, as I'd said in general I know where these .exe's exist to begin with.

It's just that it's so frustrating that one would have to resort to a vb script to find out what file is actually being run when you click on a shortcut.

I just feel that, even if it's a CLSID shortcut, that clsid knows the .exe location so there's no reason it can't be shown to us.
--Jim

 

[strongm]

The CLSID 'knows' nothing. The CLSID is merely a magic number that tells the shell that the shortcut needs to be handled in a special way (many of the Windows special folders are handled in a similar way). And, in the case of Advertised Shortcuts, that special way is to launch MSI. It is MSI that knows what to do, because it has a related installation package that it can interrogate for further information

So, without interrogating MSI (and thank goodness we can do that) we cannot get to the target folder or executable from the CLSID since there is no direct link.

I do however appreciate the frustration that Microsoft didn't deign to build in to the property sheet the ability to resolve the target in a similar way to my Powershell and VBScript solutions (perhaps the fact that sometimes it might not actually have a target because a component is not actually installed had some bearing on this)