People have a tendency to think that Windows' UAC behaves the same way as
sudo does in a Unix/Linux environment, where your normally unprivileged user account is explicitly performing a privileged action. The way Microsoft designed UAC, it encourages you to think this way, but sadly, this is not the case. When UAC prompts for credentials, it's doing an implicit
Run As..., and performs a full user context switch with the credentials you supply. The user account doing the privileged thing is no longer the one that invoked the UAC prompt.
In your case, you say that you are trying to associate file types with MPC-HC. This is curious to me, because normal, unprivileged users have the rights to associate file types with an application. You could freely associate .doc files to open up in Notepad if you wanted to, and you wouldn't have your credentials challenged to do it. This is because Windows keeps a list of file associations on a per-user basis, and every user is allowed to modify their own environment such that, to the maximum extent possible, it doesn't affect other users of the system.
Here's how this works:
Normally, Windows stores file associations in the registry at
HKEY_LOCAL_MACHINE\Software\Classes. This is in the system's registry hive. The associations there are global and affect every user of the machine. You need elevated permissions to modify most of the data in it.
If a user overrides an association (or creates a new one), Windows records it in
HKEY_CURRENT_USER\Software\Classes. This is the user's registry hive. Each user has their own HKCU hive and has permissions to freely modify their own copy.
Windows combines the two hives into a single, virtual tree at
HKEY_CLASSES_ROOT, which exists only in memory and is not an actual registry hive. When a conflict arises (i.e. the same association is recorded in both locations), the user's copy takes precedence.
Now, when you attempt to change file associations and MPC-HC prompts you with credentials, that tells me one of two things is happening:
- MPC-HC is making changes to the \Software\Classes key in
HKEY_LOCAL_MACHINE and needs elevated credentials to do that.
- MPC-HC is erroneously prompting for credentials because it thinks it has to, and the developer didn't understand how UAC works. You'd be surprised how often supposedly "smart" people get this wrong.
In the first case, MPC-HC is successfully updating the file association in the HKLM hive, but your user account has overridden it in your HKCU hive. This would explain why it doesn't appear to have made a difference. The fix is to delete that association from the registry. NOTE: If you launch
regedit, you will get a UAC prompt. Do not use your administrator account's credentials. If you do, the HKEY_CURRENT_USERS hive you see will be that of the administrator's account, not yours. Use your own unprivileged account's credentials instead. They will work.
In the second case, MPC-HC is probably just updating the association in
HKEY_CLASSES_ROOT and is hard-coded to prompt for elevation because 99% of the time, it redirects to
HKLM (which needs elevation) rather than
HKCU. If this is the case, try supplying your own credentials at the UAC prompt and see if it gets you anywhere.