Open File Location doesn't work from any shortcut .lnk file - gets no associated program error. Win 7 pro x64

The problem:

I right-click any shortcut icon on the desktop, choose "open file location" from the context menu, and receive an error dialog from windows explorer:

"This file does not have a program associated with it for performing this action. Please install a program or, if one is already installed, create an association in the Default Programs control panel."

The error also happens if I choose "properties" from the shortcut's context menu, then click the "open file location" button on the properties window.

After dismissing the error dialog, I get a "blue swirly busy" for about 10 seconds, and If I click "cancel" on the properties windows it won't close until that 10 seconds is elapsed. This doesn't seem to take much in the way of cpu cycles, and the machine stays responsive otherwise.

The error happens on any shortcut, in any folder, whether or not is is on the desktop. Usually, however, if the shortcut is in a non-desktop folder, the error does not occur from the shortcut context menu but still occurs from the shortcuts propery window.


What I've done so far:

Users are administrators.
The error happens in SAFE MODE with no networking.
The error occurs when logged on as a different user.
Created a new user, logged on as that user, and the still error occurs as described.
The error occurs if I launch windows explorer elevated as admin, browse to a shortcut and open the shortcut's property windows and click the "open file location" button.

Ran system file checker "SFC /verifyonly" and it reported no issues.

Visited the WinHelpOnline blog, downloaded the Win-7 registry fix file for .LNK files and applied it.
result: not fixed

Examined, in great detail, the registry entries for the hkey_classes_root ".lnk" and "lnkfile" keys, including the shellex context menu handlers and property sheet handlers, and even compared them to another machine running Win-7-home premium, and all seems correct.

No other programs seem to have co-opted, grabbed or set an association for .lnk or lnkfile, and control-panel/default-programs concurs, showing nothing associated with .lnk (as it should be).

I have used the NirSoft SHEXVIEW.exe utility program to view system shell extensions for lnkfile, shortcuts and such, and all seems OK. For testing purposes I used that same utility to temporarily disable non-microsoft shell extensions, and the problem still occurs.

I have run the Microsoft "fix-it" tools to clear and rebuild ShellIcon Cache, and the Bags/BagMRU folder customizations. All seems well there.

Software environment includes Adobe Photoshop CS3, the latest versions of OpenOffice.org, VLC media player, Firefox, IE-9, Roxio Creator Starter, Adobe Reader X, and Mcafee Security center. Bonjour service was installed with CS3, but is now configured to not start. The machine is a Dell, and most of the Dell installed "extras" (Dell Stage, for example) have been uninstalled. Not running bitlocker, not using encrypted file system, not running 'XP' mode.

I CAN go to a library folder, click "open folder location" from the context menu and it works ok.
I CAN go to a search results item, click "open file location from the context menu and it works ok.
 (those two things are similar shell "open location" extensions, but for other file types, so it seems that shell32.dll is functioning correctly).

The machine is up to date with all MS patches and updates.
Everything else on the machine seems to be working flawlessly, and I don't intend to reload windows or restore an image to fix this one thing - especially since I don't know exactly when it started.

COLOR ME MYSTIFIED. I guess I'm looking in the wrong area, or missing something obvious. Suggestions for other things to peek at, or test? I'm all ears.

 

Question Info


Last updated April 16, 2019 Views 2,526 Applies to:
Answer
OK! Found it! Fixed it.
The problem turned out to be one simple item in the "HKEY_CLASSES_ROOT\Folder\shell" key definition within the Folder progid.

The bad entry had a default value of "none" set for the Folder\shell key, and a working entry has either an empty (unset) default value or a null string default value. All of the other keys and values under the "Folder" progid remain the same and work correctly. I have proven the problem by setting and testing that default value back and forth. It's repeatable.

BAD...
[HKEY_CLASSES_ROOT\Folder\shell]
@="none"

GOOD...
[HKEY_CLASSES_ROOT\Folder\shell]

I thank all who replied and suggested fixes. The suggested fixes led me to the correct area(s) of the registry to examine. It would be nice to claim elegant troubleshooting methods, but it's not true - it was just looking, testing and poking until finally stumbled upon.

Regards,
 Phil



10 people were helped by this reply

·

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.