In Windows 7 (64-bit Ultimate in my case), is there any way to gain only the rights of an administrator account, rather than effectively "running" the application as <insert administrator name here>?

I am having a dilemma with MPC-HC (Media Player Classic - Home Cinema), where it requires administrator privileges to associate files with it. When I enter the credentials for an administrator account there, it essentially updates the whole environment, so the settings are applied only to the account I supplied, and not the standard account I am logged into. To be clear, I do first run the application under my standard, logged in account, and then click the "run as administrator" button available within the program.

I know I've had the same kind of trouble with some standard Windows control applets as well, so I don't think it's an issue with MPC-HC per se. I can't remember exactly what that was now though, but I'm sure of it.

The only workaround I have managed to come up with so far, is to temporarily add my account to the Administrators group, and quickly remove it again once done. But that feels like a security risk, and it's also quite inconvenient, so I'm really hoping there's a better solution...

  • Well, your issue is odd in that you only need the admin rights to set the file type associations globally, so there is no difference between one user making the change, and another, so everything should work fine when you elevate as another admin user. additionally, file type associations are only meaningful to the shell, not the program. they tell the shell to load the file with the specified program; the program itself doesn't need to know to run a file with itself. but yes, if a per-user setting requires admin to function (which is not standard) you will have to elevate the user. Aug 15, 2016 at 4:08
  • You can be a member of local administrators and your processes won't be running with elevated privileges unless you explicitly choose "run as administrator". Where do you see a security risk in that?
    – techraf
    Aug 15, 2016 at 4:14
  • with a auto-login system or one where the password is well known (as would be common on a families HTPC) I can understand why you might want the default account to be non-admin. I made the same choice some years ago. Its notable that now, those accounts are admins. standing stooped over in front of the TV to type in passwords is not how I want to spend my time. Aug 15, 2016 at 11:47
  • @FrankThomas well, this ain't for an HTPC. Administrative rights are a bad thing if you get malicious software on your computer. Not that I have a particularly vulnerable PC. I have followed several security hardening guides and have gone through all settings I could find in all available applets of Windows 7 to make sure of that. This primarily has to do with real security rather than convenience. Well, it goes hand in hand, really.
    – user966939
    Aug 15, 2016 at 13:30

1 Answer 1


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.

  • yep, after a look in the source code, it seems they are using HKEY_LOCAL_MACHINE to associate files. But I had not previously configured any file associations for my standard account before I ran MPC-HC (it was a brand new OS install at the time), so I don't really see how it's possible that there would've been anything in the user hive overriding anything.
    – user966939
    Aug 22, 2016 at 21:12
  • Pick an extension that normal media player doesn't support; say .mkv. Run the association to .mkv files elevated in MPC-HC and then see if it works. If not, run regedit w/ the standard user credentials (not the admin credentials) and check to see if .mkv shows up in the HKCU hive. If it does, delete it and see if that fixes it.
    – Wes Sayeed
    Aug 22, 2016 at 21:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .