Edited registry keys keep reverting back to their original values

7,083

Solution

You're not supposed to manually edit the content of the MuiCache registry key at all. Whenever the cache gets refreshed, the descriptions are read again from the related executable files, and your changes are reverted back.

Aside from patching the description using e.g. ResHacker, there's a built-in feature which can be useful in this case:

You can also include a FriendlyAppName value to provide the system with a friendly name for your application. The application's friendly name may also be extracted from its executable file, but only if the FriendlyAppName value is absent.

Source: Extending Shortcut Menus

  1. Log on with an administrator account.

  2. Press Win+R, type or paste regedit.exe in the text box, and press Enter.

  3. Navigate to the following registry key:

    HKEY_CLASSES_ROOT\Applications
    
  4. Locate the subkey related to the application you're interested in. In case the application key is missing, follow these steps:

    a. Right-click the Applications key, and choose New > Key from the context menu.

    b. Name the key after the executable name (e.g. whatever.exe).

    c. Right-click the new key, and create a shell subkey. Create an open subkey inside the shell subkey.

    d. Create a subkey called command inside the open subkey. Double-click the (Default) value and set it to the path of the executable, plus "%1" to account the parameter to pass to the program. For example:

    "C:\Program Files\Whatever, Inc.\whatever.exe" "%1"
    
  5. Navigate to the following key, where whatever.exe is the actual executable name:

    HKEY_CLASSES_ROOT\Applications\whatever.exe\shell\open
    
  6. Right-click an empty area in the right pane, and choose New > String Value from the context menu. Name the new value FriendlyAppName, and set it as you like. Changes are applied immediately.

Note The official documentation is not up-to-date. The FriendlyAppName value was meant to be in stored the root application key, but that's no longer the case as of Windows XP.

Additional information

FriendlyAppName

Provides a way to get a localizable name to display for an application instead of just the version information appearing, which may not be localizable. The association query ASSOCSTR reads this registry entry value and falls back to use the FileDescription name in the version information. If that name is missing, the association query defaults to the display name of the file.

Source: Application Registration

After starting a program, the descriptions is usually extracted from the executable file and stored in the following registry keys for later use:

HKEY_CLASSES_ROOT\Local Settings\MuiCache
HKEY_CLASSES_ROOT\Local Settings\Software\Microsoft\Windows\Shell\MuiCache

Those registry keys are actually mapped to the user branch:

HKEY_CURRENT_USER\Software\Classes\Local Settings\MuiCache
HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\MuiCache

Further reading

Share:
7,083

Related videos on Youtube

Makaveli84
Author by

Makaveli84

Updated on September 18, 2022

Comments

  • Makaveli84
    Makaveli84 over 1 year

    OS: Windows Vista Home Premium SP2

    I'm making the following changes so the program names in question are more user friendly in the 'open with' and 'programs' lists:

    [HKEY_CLASSES_ROOT\Local Settings\Software\Microsoft\Windows\Shell\MuiCache]
    "C:\\Program Files\\K-Lite Codec Pack\\Media Player Classic\\mpc-hc.exe"="Media Player Classic Home Cinema"
    "C:\\Program Files\\MKVToolNix\\mmg.exe"="MKV Merge"
    

    Every other week or so they revert back to "MPC-HC" and "mmg.exe" respectively! What is up with that?!

    • and31415
      and31415 over 9 years
      You're not supposed to manually edit the content of that registry key at all. In fact, it's used as a cache for localized strings, and as soon as it gets refreshed all changes are gone - just what you're experiencing. Consider editing the description of both executables instead, e.g. using ResHacker (make sure to create a backup of the original files first).
    • Makaveli84
      Makaveli84 over 9 years
      @and31415 Yes, but what is prompting this refresh? I had already experimented with such changes on Windows 7 and they seem to have stuck. I would've preferred avoiding "hardcoding" the changes, but might end up doing it if all registry hacks fail..
    • Makaveli84
      Makaveli84 over 9 years
      Increasing the mui cache size would probably help, but can it be done?
    • and31415
      and31415 over 9 years
      Now that I think about it, you might want to try setting the FriendlyAppName registry value, as explained here: Application Registration
    • and31415
      and31415 over 9 years
      Yes, I reached the same conclusions while commenting on a related question. The official documentation is not up-to-date. The FriendlyAppName was meant to be in stored the root key, but that's no longer the case as of Windows XP. If the approach is fine with you, I might provide an actual answer :)
    • Makaveli84
      Makaveli84 over 9 years
      By all means, do provide an answer! :) P.S. Microsoft still use FriendlyAppName in the applications' root key for some of their Windows tools (Calendar i.e. wincal.exe, Windows Media Player i.e. wmplayer.exe, etc..). There's still more to this, it seems...
    • Makaveli84
      Makaveli84 over 9 years
      On a separate note, I'm intrigued to why the MuiCache changes seem to have stuck for years on my Windows 7 machine.. Maybe a larger cache limit, or a different "refreshing" algorithm?
    • and31415
      and31415 over 9 years
      Well, apparently whoever put those registry values in the root key was probably following the official documentation. Here's a working example: before / after. As you can see, the value stored in the root key is completely ignored. This can also be confirmed by using Process Monitor. As for the cache, the behavior might have changed slightly in Windows 7 but I don't know for sure. Either way, the FriendlyAppName value works fine there, too.