locked
Open File Location fails from any shortcut context menu giving a program association error dialog. Win 7 Pro x64. RRS feed

  • Question

  • 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. During that timeout the desktop is busy, meaning I can't right-click the desktop and get the context, launch a desktop shortcut or move an icon, but the taskbar and quick-launch stuff works fine. 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.

    Booted WinPE and did chkdsk on all drives. NTFS is A-OK

    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.



    Saturday, March 3, 2012 4:52 PM

Answers

  • 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.
    It makes sense (now), knowing that the OpenContainingFolder ShellEx context menu extension class launches a new Explorer window via the Folder progid.

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

    GOOD...
    [HKEY_CLASSES_ROOT\Folder\shell]

    Chances are that I will never knlow exactly how this got changed, but should it happen again, I'm prepared.

    I thank all who replied and suggested fixes. The suggested fixes led me to the correct area(s) of the registry to examine. I've learned a ton of stuff about how shell extensions are installed, programmed, and a bit about how to troubleshoot them. 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


    Saturday, April 7, 2012 10:38 PM

All replies

  •  

    Hi,

    Firstly, please let us know the following information:

    1. Can you open all the shortcuts directly with its proper function?

    2. Can you open the shortcut by right click the shortcut->Open with?

    3. Which Target type has the issue, File Folder or special File Type?

    4. Can you open Windows Explorer by using “Windows Key + E”

    4. When did the issue occurred? Did you install some special application or do some special operation?

    Meanwhile, please try the following steps to determine the issue.

    1. Please using your security application to scan your system to check if the issue is caused by Virus.

    2. Run “assoc .lnk” in Command Prompt and make sure the result is “.lnk=lnkfile”.

    3. Run “ftype lnkfile” in Command Prompt and make sure the result is “File type 'lnkfile' not found or no open command associated with it.”

    In addition, please refer to “When you run an .exe file on a Windows XP, Windows Vista or Windows 7-based computer, the file may start a different program” and see how it works.

    Hope this helps.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Monday, March 5, 2012 9:22 AM
  • Thanks for the suggestions...

    1. All shortcuts launch their appropriate app or document type.
    2. yes (for shortcuts to documents.)
    3. any shortcut, regardless of what it is a shortcut to, launches correctly - it's just the "open file location" context that doesn't work.
    4. yes.

    4b. I don't know exactly when - unfortunately. The machine was new in mid-November. Since then, certainly, and I do recall it working properly in this regard at some time past. Just no way to nail it down.

    Scans run clean.

    assoc .lnk returns 'lnkfile'
    assoc lnkfile returns 'shortcut'

    ftype .lnk (and ftype lnkfile) return no association.

    The .exe "fixit" was already visited, and doesn't do it. That per-user explorer association is not broken/modified.

    **but**

    I just discovered this tidbit...

    If I open a windows explorer session, browse to the target folder of one of the desktop shortcuts, leave that session open with the focus on (or in) the folder where the target item is located...

    Then I right-click the desktop shortcut and select "open file location" it then works. The previously-opened explorer session immediately moves its focus to the target item, and no error occurs.

    If I close the explorer session, or move it's focus to a different folder than the target of the shortcut, then the error occurs when I choose 'open file location' from the desktop shortcut.

    From this behavior I see/surmise that the shortcut handlers (?) are having problems launching a NEW explorer session to explore the target item, but work properly when an existing session is already there and focused on/in the appropriate folder.

    Now THAT is just a bit mysterious.

    Monday, March 5, 2012 8:39 PM
  • Hi ,

    Please create a new txt file with the following content and rename it as .reg file.

    Windows Registry Editor Version 5.00
    [HKEY_CLASSES_ROOT\Folder\shell\opennewprocess\command]
    "DelegateExecute"="{11dbb47c-a525-400b-9e80-a54615a090c0}"
     
    [HKEY_CLASSES_ROOT\Folder\shell\opennewwindow\command]
    "DelegateExecute"="{11dbb47c-a525-400b-9e80-a54615a090c0}"
     
    [HKEY_CLASSES_ROOT\opensearchfilefolderresult\shell\open\command]
    @=""
    "DelegateExecute"="{99969a8f-27e6-4adf-ab9f-b5b5e90d4733}"
     
    [HKEY_CLASSES_ROOT\Folder\shell\explore\command]
    "DelegateExecute"="{11dbb47c-a525-400b-9e80-a54615a090c0}"
     
    [HKEY_CLASSES_ROOT\WMP11.AssocFile.m3u\shell\Enqueue\command]
    "DelegateExecute"="{45597c98-80f6-4549-84ff-752cf55e2d29}"

    Note:

    The information is about modifying the registry. Before you modify the
    registry, make sure to back it up and make sure that you understand how to
    restore the registry if a problem occurs. For information about how to back up,
    restore, and edit the registry, click the following article number to view the
    article in the Microsoft Knowledge Base:

    Description of the
    Microsoft Windows Registry

    http://support.microsoft.com/kb/256986

    If this doesn't work, please try to uninstall and reinstall Microsoft IE and see if this works.

    Thanks.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Friday, March 9, 2012 9:59 AM
  • Thanks for the suggestions - I thought we might be onto something

    I examined the registry beforehand and found all 5 of those DelegateExecute values in place and correct. I created and applied the .reg file anyway (just in case my eyeballs deceived) and it didn't fix the error.

    I will do the IE-9 uninstall/re-install later today and report back.

    ...later

    Nope, I uninstalled ie-9 (ctl panel, pgms and features, installed updates, IE-9) then installed a fresh download from MS. It all went well but didn't fix the problem.

    Sigh...

    Friday, March 9, 2012 12:56 PM

  • Hi,

    Please try to update the latest explorer.exe and shell32.dll via the following KB:
    http://support.microsoft.com/kb/2664055
    http://support.microsoft.com/kb/2647401

    Restart the computer and see if this helps.

    Please click Start and type cmd in the search box then press enter. Type the sfc /scannow in the command window to see if any file is corrupted.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Saturday, March 10, 2012 6:37 AM
  • Thanks again.

    Well, replacing explorer.exe and shell32.dll with those hotfixes didn't do the trick either. Both installed just fine, and I double checked version and build to make sure they were in place and working. No change. I have since uninstalled both before loading this month's security updates.

    Today I used the sysinternals listdlls utility to list out all DLLs connected to explorer.exe, and checked to see if all of them were Microsoft, un-modified, and a few such things. Nothing strange there either as best as I can tell.

    I've been round and round, and the system sure looks clean. My only "hunch" suspect is the McAfee security package, as it is one of the few things that installs itself into every nook and cranny of the machine, including many context menus, and still has some activity even when I'm booted into Safe Mode. But you would think if this was a common problem with McAfee it would be noticed as thousands of folks ran into the problem, and I just can't fine many references to my problem "out there" on the net. When my McAfee package expires in a few months I intend to uninstall, and perhaps then I'll learn if my hunch is correct.

    But, until then, I'll continue to tinker as time and inclination permit in hopes of finding the glitch. As always, I'm open to suggestions.

    Thursday, March 15, 2012 3:49 AM
  • Hi ,

    Did you try to use sfc?

    Type the sfc /scannow in the command line window to see if any file is corrupted.

    I experience someone's registry key is corrupt and it also cause this issue. We may can restore a backup of the registry hiv. Please inspect the time stamp of the System, Software, DEFAULT, SECURITY  file in %systemroot%\system32\config. Also see the time stamp of these files in %systemroot%\system32\config\regback. Please try to restore this backup.

    Note: The following method is not a safe way to do and not recommended. Use it at your own risk.

    Insert the Windows 7 install DVD. Restart the server and boot from DVD. Press a key when you are prompted. Select a language, a time, a currency, a keyboard or an input method, and then click Next.
    Click Repair your computer. Click the operating system that you want to
    repair (it should be blank),  and click Next. In the System
    Recovery Options
    dialog box, click Command Prompt.

    (If you have no Windows 7 DVD, press F8 at system start and select "Repair your computer")

    On the command line, see what's the system volume letter. It should be C or D.

    Go to: %systemroot%\ System32\Config

    Run: ren system system.old

    ren software software.old

    ren security security.old

    ren default default.old

    cd %systemroot%\ System32\Config\regback
    copy system  %systemroot%\system32\config

    copy software %systemroot%\system32\config

    copy security %systemroot%\system32\config

    copy default %systemroot%\system32\config

    Note: Replace %systemroot% as the actual path like D:\windows

    Change after the timestamp of the regback might be lost.

    Thanks.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.


    • Edited by HuAaron Friday, March 16, 2012 8:58 AM
    Friday, March 16, 2012 8:57 AM
  • While I appreciate the suggestions, I don't think I'll be doing that. My registry regback files are dated 3/10 (just 6 days ago), but my problem dates back into January or February - exact date unknown. "SFC /verifyonly" reports no issues.

    I have several pristine system partition images that I could restore, dating back to when the computer was near new, but I don't care to go through the business of restoring and booting several system images to find when the problem occurred. And even if I did that, the problem might get "fixed" without understanding what it was or how it got broken in the first place.

    What I was really hoping for is to find a way to troubleshoot the problem. We have a system here that is running flawlessly in all respects except for this one, small, well defined, repeatable error. One would wish that there was a way to actually troubleshoot (and understand) such a problem without resorting to shotgun approaches.
    Friday, March 16, 2012 3:00 PM
  • Hi ,

    1. Maybe you can use  Process Monitor to check the missing registry key. http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/processmonitor.mspx
    2. Is restoring HKLM/software/classes from a backup an option?

    3. Are you using XP mode?

    Thanks.



    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Tuesday, March 27, 2012 12:08 PM
  • Thank you for your suggestions.

    I've tried using Procmon to get an idea of why the failure is happening. But there is just SO MUCH going on that it is almost impossible for a "regular person" (someone who is not Mark Russinovich) to decipher the activity. Earlier in this thread I detailed how I could have an explorer window open and focused at the appropriate folder and the problem wouldn't happen, and then change the explorer focus to a different folder and the problem would happen. I used that to capture two event streams with procmon - one with the failure and one with it working - and then attempt to see what happened differently, using a variety of filters. I'm sure the answer is right there in front of me if I could just recognize it. I even attempted to run procmon from within safe mode where there would be fewer distracting things happening, but it won't run there.

    Yes, I can extract HKLM/software/classes from an early image by retrieving the SOFTWARE hive file from the image, doing a "load hive" from within regedit, and then exporting it to .REG style text where it can be examined and/or modified as desired. I may do that, and attempt to do some file comparisons with my current HKLM/software/classes export, and see what the differences are. As time permits I'll probably work on that idea.

    I'm still working this problem in this manner because I find it interesting and desire to find a way to actually troubleshoot it in an elegant fashion. I know I could do a "repair install" of Windows and it would probably get fixed, but I haven't given up yet.

    By the way, if anyone knows how to run ProcMon from within Safe Mode by starting some additional services (or something), I'd be glad to hear it.
    Tuesday, March 27, 2012 4:03 PM
  • 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.
    It makes sense (now), knowing that the OpenContainingFolder ShellEx context menu extension class launches a new Explorer window via the Folder progid.

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

    GOOD...
    [HKEY_CLASSES_ROOT\Folder\shell]

    Chances are that I will never knlow exactly how this got changed, but should it happen again, I'm prepared.

    I thank all who replied and suggested fixes. The suggested fixes led me to the correct area(s) of the registry to examine. I've learned a ton of stuff about how shell extensions are installed, programmed, and a bit about how to troubleshoot them. 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


    Saturday, April 7, 2012 10:38 PM
  • Had the same problem. I found another spurious key at [HKEY_CLASSES_ROOT\Folder\shell], I removed it and right-click "Open file location" worked fine again! Thank you
    Tuesday, June 6, 2017 10:14 AM
  • I suspect the problem comes up when an old registry file from the 'XP' days is loaded into a Windows 7/8/10 system. The way they did the [HKEY_CLASSES_ROOT\Folder\shell] default value in XP is not compatible with the newer systems.
    Tuesday, June 6, 2017 2:02 PM
  • Can you capture the screen for me, I got the same problem with my Windows 10 laptop. How did you solve it?
    Friday, April 6, 2018 4:30 AM
  • I fixed it using REGEDIT to remove the offending default value for HKEY_CLASSES_ROOT\Folder\shell

    Review this thread for the entry marked as an answer, beginning with "OK! Found it! Fixed it"

    Obligatory Warning: Regedit can get you into trouble if you modify the wrong thing. If you are not comfortable using it then perhaps get some assist from a local geek/nerd/guru.

    I will insert a jpg screenshot of the entry under discussion, with some highlighting.


    Friday, April 6, 2018 11:46 AM