DETAILS:
"[WinError 5] Access is denied" error is thrown when user attempts to use a different Registry hive other than HKEY_CURRENT_USER.  The first example below will demonstrate that the code snippet works just fine and is implemented correctly.  However, when you try to run the exact same snippet, but with it pointed to HKEY_LOCAL_MACHINE, it will throw "[WinError 5] Access is denied" error.  I have seen plenty of variant examples on how you are supposed to write to the Registry, but when you attempt to do so to other hives, it simply does NOT work.  Complete demonstration below of it working, and not working...

# WORKING example:
registry = winreg.ConnectRegistry(None, winreg.HKEY_CURRENT_USER)
wholeKey = winreg.OpenKey(registry, 'SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon', 0, winreg.KEY_ALL_ACCESS | winreg.KEY_WOW64_64KEY)
winreg.SetValue(wholeKey, 'AutoAdminLogon', winreg.REG_SZ, '1')
winreg.CloseKey(wholeKey)


# NON-WORKING example:
registry = winreg.ConnectRegistry(None, winreg.HKEY_LOCAL_MACHINE)
wholeKey = winreg.OpenKey(registry, 'SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon', 0, winreg.KEY_ALL_ACCESS | winreg.KEY_WOW64_64KEY)
winreg.SetValue(wholeKey, 'AutoAdminLogon', winreg.REG_SZ, '1')
winreg.CloseKey(wholeKey)

Is it working if you run, whatever application you're running python on, in admin mode?

Actually behind the scenes, winreg uses win32api which doesn't allow setting HKEY_LOCAL_MACHINE keys for unprivileged users. Running the application in admin mode may work because at that point your application  getting admin privileges but it also may not work because winreg module may not gain admin privileges even though your application does.

Clarification:
User is a local admin on the machine, and UAC is disabled as well.  I can also add, modify, and delete Registry entries in HKLM (or any other hive) by hand with no problem, so it is definitely not a permissions issue.  I can also write, update, modify, etc. anything in HKLM using C# just fine, but NOT with winreg in Python.  

Note:  Keep in mind that the exact same Registry write methods work as long as you are pointed to HKCU hive. However, if you point to HKLM and do not change anything else, winreg will throw a permissions error every time, no matter what combination of permission flags you specify.  There is no reason why a user should be able to write to HKCU but not HKLM.  Try it and you will experience the same.  This is clearly a major bug and should be fixed.  It severely limits developers from writing to other Registry hives.  While HKCU is quite common to use, HKLM is the most common that developers use, especially when you don't want specific Registry keys to be accessible only to a specific user.

You will be able to reproduce and see the problem if you try the two examples I provided.  Have you tried the two code snippets I provided yet?  Please do so, and confirm the outcome so that you are on the same page.

> I can also add, modify, and delete Registry entries in HKLM (or any other hive) by hand with no problem, so it is definitely not a permissions issue.

When you run regedit you get an admin pop up, right? Like that also run python in admin mode.

> I can also write, update, modify, etc. anything in HKLM using C# just fine, but NOT with winreg in Python.  

I've never used C# but as far as I know it doesn't use win32api while Python does. C# is specifically designed to work with these while C is not therefore it uses win32api. Python uses the C interface of win32api. 

> Keep in mind that the exact same Registry write methods work as long as you are pointed to HKCU hive. However, if you point to HKLM and do not change anything else, winreg will throw a permissions error every time, no matter what combination of permission flags you specify.
> You will be able to reproduce and see the problem if you try the two examples I provided.  Have you tried the two code snippets I provided yet?  Please do so, and confirm the outcome so that you are on the same page.

Please provide an example that does not involve setting of values (I actually don't want to mess with my registry). If this is occurring while setting of values then I am on right track. If it's not then this requires quite a investigation and debugging. 


Lastly a WinError always means Access Denied. AFAICT this is a permission problem.

> There is no reason why a user should be able to write to 
> HKCU but not HKLM.  

Modifying system keys is limited to SYSTEM, administrators, and various privileged accounts and services such as TrustedInstaller. Standard users are not allowed to modify system keys.

> User is a local admin on the machine, and UAC is disabled as well. 

Please show the output from running the following:

    import subprocess
    import winreg

    print(subprocess.check_output('whoami.exe /groups /fo list', text=True))

    hkey = winreg.HKEY_LOCAL_MACHINE
    winreg.OpenKey(hkey, 'SOFTWARE', 0, winreg.KEY_ALL_ACCESS)

If it shows that the administrators group is enabled but full access is still denied to the system "SOFTWARE" hive, then something peculiar is happening here that warrants further inspection.

---

Background

The base object type that implements the registry is the Key type. A key object can contain other keys and values, or a symbolic link to another key. A key can also be mounted by a hive, which is a tree of keys that's persisted in a file.

The root key is named "\REGISTRY". The system mounts user profile hives (i.e. "<userprofile>\NTUSER.DAT") on subkeys of "\REGISTRY\USER" and system hives on subkeys of "\REGISTRY\MACHINE". Each loaded user profile hive is mounted on a subkey that's named for the user's SID string -- e.g. "\REGISTRY\USER\S-1-5-21-<domain id>-<relative id>", except the default user profile hive is mounted as "\REGISTRY\USER\.DEFAULT". The mounted system hives include BCD00000000 (boot configuration database), SYSTEM, SOFTWARE, SECURITY, and SAM. The system hives, with the exception of the BCD hive, are found on disk in the directory "%SystemRoot%\System32\config". 

The "\REGISTRY\USER" and "\REGISTRY\MACHINE" keys are made available via the predefined handles HKEY_USERS and HKEY_LOCAL_MACHINE. These predefined handles can also reference the "USER" and "MACHINE" keys on a remote system via winreg.ConnectRegistry(). In the local case, the API maps the predefined handle to an actual handle that it opens via NtOpenKeyEx(). In the remote case, the predefined handle is mapped to an RPC (remote procedure call) handle that proxies a handle on the remote system.

HKEY_CURRENT_USER is a predefined handle for the user profile key of the current user. It exists for convenience. Otherwise a program would have to get the name of the subkey to use by getting the current user's SID as a string.

The predefined handles that are documented to work with ConnectRegistry() are HKEY_USERS, HKEY_LOCAL_MACHINE, and HKEY_PERFORMANCE_DATA (a virtual key that the API implements) [1]. ConnectRegistry() is not documented to support HKEY_CURRENT_USER. For a remote system, it opens the default profile. This is undefined behavior for an unsupported parameter. It happens to work in the local case when computer_name is None.

A key object is secured by a security descriptor that grants or denies specific users and groups various standard rights and specific key rights. winreg provides the API constants for specific key rights, as well as constants with mapped rights for generic access, including KEY_READ, KEY_WRITE, KEY_EXECUTE, and KEY_ALL_ACCESS. These are defined as follows:

    STANDARD_RIGHTS_REQUIRED:
        WRITE_OWNER
        WRITE_DAC
        READ_CONTROL
        DELETE        

    KEY_READ / KEY_EXECUTE:
        KEY_QUERY_VALUE
        KEY_ENUMERATE_SUB_KEYS
        KEY_NOTIFY
        READ_CONTROL

    KEY_WRITE:
        KEY_SET_VALUE
        KEY_CREATE_SUB_KEY
        READ_CONTROL

    KEY_ALL_ACCESS:
        KEY_READ
        KEY_WRITE
        KEY_CREATE_LINK
        STANDARD_RIGHTS_REQUIRED

From the command line, you can use Sysinternals "accesschk.exe" to check the access that a key grants to a particular user or group, such as the "Users" group. For example:

    C:\>accesschk -nobanner -kdv Users "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
    R  HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
            KEY_QUERY_VALUE
            KEY_ENUMERATE_SUB_KEYS
            KEY_NOTIFY
            READ_CONTROL

Standard users are only granted read access to the "Winlogon" key. Full access is granted to administrators, SYSTEM, and the TrustedInstaller service. 

By default, if UAC is enabled, an administrator uses a non-elevated logon that has the administrators group disabled for everything except denying access to objects. Spawning a process with "run as administrator" uses an elevated logon that enables the administrators group for granting access to secured objects.

---

[1] https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regconnectregistryw

*** Again, I am using a LOCAL ADMINISTRATIVE account. ***

"Actually behind the scenes, winreg uses win32api which doesn't allow setting HKEY_LOCAL_MACHINE keys for unprivileged users. Running the application in admin mode may work because at that point your application  getting admin privileges but it also may not work because winreg module may not gain admin privileges even though your application does."

That is not correct.  What special permissions do I need to leverage winreg to write to HKEY_LOCAL_MACHINE that a normal local administrator does not have?  By default, any user that has adequate permissions to write / modify directly to their HKCU hive, can also do so in HKEY_LOCAL_MACHINE.  The only isolated exceptions are where there are specialized keys in which custom permissions were modified outside the default inherited permissions.  To be clear, there is no "admin mode", but I think what you mean is being logged in either with local Administrator account, or logged in with an account that has local Administrator permissions.  (You can either be logged in as Administrator, or have an account that has local admin privileges, both of which I am doing when I am executing winreg methods that fail with permission errors.)

"When you run regedit you get an admin pop up, right? Like that also run python in admin mode."

No, there is no pop up.  The reason there is no pop up is because as explained previously, my account has local administrative permissions, and secondly, I have UAC turned off.  I can freely make changes directly to the Registry in any hive, including HKEY_LOCAL_MACHINE.  This is NOT a permissions issue in the Registry and / or with the user account I am using.  If there is a permission issue do to a lack of proper winreg security flag, then that is different, and I need to understand which winreg security flag(s) I SHOULD be using so I can correct it.   You don't want popups, especially for processes you want to run automatically and unattended, right?  If there was a pop up during an attempted change to the Registry, then any methods used would otherwise not have a chance to execute correctly, and any application doing this would obviously break.

"I've never used C# but as far as I know it doesn't use win32api while Python does. C# is specifically designed to work with these while C is not therefore it uses win32api. Python uses the C interface of win32api."

Actually, C++ and C# uses Win32 API through .NET framework, while also allows even more intimate and direct connection to Win32 (both in managed and unmanaged interfaces).  Obviously, due to the differences of outcomes, while the interfaces winreg is using to access the Registry are similar, apparently they are quite different, as I can run equivalent Registry functions in C# with C++ Win32 API, and it runs just fine.  Again, no permission issues at all.

"Please provide an example that does not involve setting of values (I actually don't want to mess with my registry). If this is occurring while setting of values then I am on right track. If it's not then this requires quite a investigation and debugging. "

No, you are not on track yet.  How can you test a defect in winreg of writing to HKEY_LOCAL_MACHINE without actually trying to write to it?  You can't, and you are not even investigating it yet.  

If you are not going to leverage the examples provided, then how are you going to learn about this winreg defect? If you don't like the Registry values in the examples, then simply change them to something you are more comfortable with that is equally as innocuous as my examples, as long as you use HKCU on one, and run the exact same one pointed to HKLM, so that you can very quickly and easily see for yourself, and reproduce this defect.  If your account permissions are set up correctly and mine are not, then BOTH examples I gave you should execute and write Registry settings to both HKCU and HKLM, without any errors.

After running into this issue and reviewing documentation all over again, I also see a pattern that every example out there only uses HKCU hive, while there are zero working examples that demonstrate writing to the Registry in the HKEY_LOCAL_MACHINE. This no longer appears to be just a coincidence, but instead a limitation.  While HKCU is quite common for user-specific Registry settings, HKLM is very heavily used for nearly everything that is not user-specific settings.  For winreg not being able to write to HKLM hive successfully, regardless if the user is a local admin and has inherited admin privileges to HKLM even by default, then this is a major bug and a huge limitation to winreg that someone should investigate and implement a solution.    

Also, if you are not going to run the examples I provided (even with your own Registry values you are comfortable with), then provide ONE working example of writing to Registry with winreg to HKEY_LOCAL_MACHINE that actually works, and I will try it.  If you are supporting winreg, then this is a very reasonable request, especially since none of the documentation provides working examples that successfully write to HKEY_LOCAL_MACHINE.

"Lastly a WinError always means Access Denied. AFAICT this is a permission problem."

That is incorrect.  In addition to having local Administrator permissions, the account I am using also has system-level permissions, which is even above default Administrator permissions. I do not receive such errors when I write to HKLM hive using Win32 API in C#. So, if you believe this is simply a permissions issue, then enlighten everyone and provide information on proper security settings for it to work successfully, and I will be more than happy to make any security changes necessary.  This should be a very reasonable request since you are so quick to dismiss this as a permissions issue and without even using the examples I provided you that clearly and concisely indicate there is a bug in winreg.  Otherwise, show me how I am using winreg incorrectly, and provide a single working example that can write to HKEY_LOCAL_MACHINE, and I will gladly adopt your approach.

Do you mind ticking the box, "Run as Administrator" in the Compatibility tab for python.exe and try winreg again?

Ok. I tested it. And I'm now completely sure that you're not running in Administrator mode. I'll give you the steps to solve this problem but first of all where are you running this code from, IDLE, Python or any other IDE? How to run in admin mode depends on where are you running your code from.

(You can also try Eryk's method. The method I used is a temporary workaround while Eryk's is the correct one.)

Eryk:

The whoami process check output shows that my account is in BUILTIN\Administrators, which proves that the account I am logged in as local Administrator permissions.

As for the OpenKey method, it fails with [WinError 5] Access denied, exactly the same way my example also failed, and the reason why these consistently fail is because they are pointed to HKLM, essentially replicating the issue that I pointed out.  I have also tried different combinations of security flags (winreg.KEY_ALL_ACCESS, winreg.KEY_WOW64_64KEY, etc.), but keep getting the same results.

Here's something you should know about Windows, even if a local account is in the Administrators group, it still has restrictions on what it can do, it just has the power to elevate itself without requiring login credentials (VIA UAC prompts).

This group functions very similar to the sudoers group in Linux.

I expect that disabling UAC only causes Windows to automatically approve them on Administrator accounts and deny on non-Administrator accounts for applications that explicitly require the prompt (Run as Administrator special flag).

There exists a hidden deactivated account called Administrator in Windows that functions very similar to root in Linux. UAC prompts are to allow an application to run under a temporary Windows Logon session as this hidden account while using your logon session, aka elevation.

The most easy way to do is right click on the application you're running the code from, click Run as Administrator and then run the code in that application. You'll not get any WinError. And also being in the Administrators group doesn't mean whatever application you run has the permission. You have the permission to do manually not the application right? I'm saying this because I'm the admin of my computer still Python raises WinError if I run it normally. Being the admin of my computer I still have to run Python in elevated mode. Windows considers Python as a third party app and it'll not give admin access to it so easily.

> The whoami process check output shows that my account is in 
> BUILTIN\Administrators, which proves that the account I am 
> logged in as local Administrator permissions.

Please show the output when whoami.exe is spawned from Python. I never questioned whether your account is in the administrators group. I need to know exactly how the group is flagged and/or enabled in the security context of the Python process. For example, a UAC limited logon will include the group with a flag that enables it only for access-denied entries in an object's discretionary access control list (DACL):

    Group Name: BUILTIN\Administrators
    Type:       Alias
    SID:        S-1-5-32-544
    Attributes: Group used for deny only

For the group to apply to access-allowed entries in a DACL, it must be enabled as follows:

    Group Name: BUILTIN\Administrators
    Type:       Alias
    SID:        S-1-5-32-544
    Attributes: Mandatory group, Enabled by default, Enabled group, Group owner

@Eryk:

GROUP INFORMATION
-----------------

Group Name: Everyone
Type:       Well-known group
SID:        S-1-1-0
Attributes: Mandatory group, Enabled by default, Enabled group

Group Name: NT AUTHORITY\Local account and member of Administrators group
Type:       Well-known group
SID:        S-1-5-114
Attributes: Group used for deny only

Group Name: MACHINE_NAME\docker-users
Type:       Alias
SID:        S-1-5-21-3084499296-1678378808-3679662973-1002
Attributes: Mandatory group, Enabled by default, Enabled group

Group Name: MACHINE_NAME\ORA_ASMDBA
Type:       Alias
SID:        S-1-5-21-3084499296-1678378808-3679662973-1028
Attributes: Mandatory group, Enabled by default, Enabled group

Group Name: MACHINE_NAME\ORA_DBA
Type:       Alias
SID:        S-1-5-21-3084499296-1678378808-3679662973-1019
Attributes: Mandatory group, Enabled by default, Enabled group

Group Name: MACHINE_NAME\ORA_OraDB18Home1_SYSBACKUP
Type:       Alias
SID:        S-1-5-21-3084499296-1678378808-3679662973-1025
Attributes: Mandatory group, Enabled by default, Enabled group

Group Name: MACHINE_NAME\ORA_OraDB18Home1_SYSDG
Type:       Alias
SID:        S-1-5-21-3084499296-1678378808-3679662973-1026
Attributes: Mandatory group, Enabled by default, Enabled group

Group Name: MACHINE_NAME\ORA_OraDB18Home1_SYSKM
Type:       Alias
SID:        S-1-5-21-3084499296-1678378808-3679662973-1027
Attributes: Mandatory group, Enabled by default, Enabled group

Group Name: BUILTIN\Administrators
Type:       Alias
SID:        S-1-5-32-544
Attributes: Group used for deny only

Group Name: BUILTIN\Users
Type:       Alias
SID:        S-1-5-32-545
Attributes: Mandatory group, Enabled by default, Enabled group

Group Name: NT AUTHORITY\INTERACTIVE
Type:       Well-known group
SID:        S-1-5-4
Attributes: Mandatory group, Enabled by default, Enabled group

Group Name: CONSOLE LOGON
Type:       Well-known group
SID:        S-1-2-1
Attributes: Mandatory group, Enabled by default, Enabled group

Group Name: NT AUTHORITY\Authenticated Users
Type:       Well-known group
SID:        S-1-5-11
Attributes: Mandatory group, Enabled by default, Enabled group

Group Name: NT AUTHORITY\This Organization
Type:       Well-known group
SID:        S-1-5-15
Attributes: Mandatory group, Enabled by default, Enabled group

Group Name: NT AUTHORITY\Local account
Type:       Well-known group
SID:        S-1-5-113
Attributes: Mandatory group, Enabled by default, Enabled group

Group Name: LOCAL
Type:       Well-known group
SID:        S-1-2-0
Attributes: Mandatory group, Enabled by default, Enabled group

Group Name: NT AUTHORITY\NTLM Authentication
Type:       Well-known group
SID:        S-1-5-64-10
Attributes: Mandatory group, Enabled by default, Enabled group

Group Name: Mandatory Label\Medium Mandatory Level
Type:       Label
SID:        S-1-16-8192
Attributes:

Thank you. The output shows that the Python process is using a UAC limited security context, i.e. the administrators group is enabled only for access-denied rules, and the integrity level is medium (not elevated to high or system level). 

    Group Name: BUILTIN\Administrators
    Type:       Alias
    SID:        S-1-5-32-544
    Attributes: Group used for deny only
    
    Group Name: Mandatory Label\Medium Mandatory Level
    Type:       Label
    SID:        S-1-16-8192
    Attributes:

"The most easy way to do is right click on the application you're running the code from, click Run as Administrator and then run the code in that application. You'll not get any WinError. And also being in the Administrators group doesn't mean whatever application you run has the permission. You have the permission to do manually not the application right? I'm saying this because I'm the admin of my computer still Python raises WinError if I run it normally. Being the admin of my computer I still have to run Python in elevated mode. Windows considers Python as a third party app and it'll not give admin access to it so easily."

@Shreyan, Yes, totally understand that.  I am also keenly aware of this, because often times for low-level, environment-related solutions in Visual Studio, I have had to set Visual Studio IDE to run as administrator in order for certain operations to function properly.  In the case of Python, I am currently using VSCode.  When I have set code.exe to run as administrator, and configure python.exe to run as administrator under Compatibility mode, then both VS Code and Python starts acting strange.  From the IDE, I can no longer run in debug mode, and any output that is generated is launched in a separate console window, which is viewable only briefly.

So... what I also tried was just eliminating VS Code from the equation at the moment.  I run a DOS console as Administrator, then just call Python directly along with the .py, and the WinError 5 stops getting thrown.  However, the other thing I noticed is that when python.exe is set to run as administrator under Compatibility Mode, and you reopen solution in VS Code, I noticed that the winregistry library stops getting recognized.

"Here's something you should know about Windows, even if a local account is in the Administrators group, it still has restrictions on what it can do, it just has the power to elevate itself without requiring login credentials (VIA UAC prompts)."

@William:
Sure, I understand that, which is also why I have UAC prompts disabled.  Also, there are additional security settings that most people do not know about Administrator accounts:  There are permission settings that go much further than Administrator and disabling of UAC, which is also providing your user account "system" level permissions, and "Act as part of the operating system".  This pretty much puts your account in "god mode" where you can do all kinds of things that most of us probably shouldn't need to do for most situations, but it is there when needed.  In any case, it should not be necessary to get Python permissions to execute write / update methods in Python against HKLM hive. I definitely don't need to do much to get it to work in C# or C++ just fine.

Don't run VSCode in admin mode. Just set python to admin mode. See if it works then.

> In any case, it should not be necessary to get Python permissions 
> to execute write / update methods in Python against HKLM hive

HKEY_LOCAL_MACHINE is a predefined handle for the key "\REGISTRY\MACHINE". This key is not mounted by a hive. There are several hives that the system mounts on its subkeys, including the SOFTWARE hive. FYI, the list of mounted hives is stored as values in "HKLM\SYSTEM\CurrentControlSet\Control\hivelist".

The right to modify system keys is restricted to the administrators local group (i.e. alias) and SYSTEM well-known group. In some cases, privileged service accounts are also granted full access, particularly TrustedInstaller. By default, standard users only have at most read access to system keys, if any access at all (e.g. the SECURITY key grants them no access). 

If UAC is disabled (not just its consent prompt), or if an administrator account is exempt from UAC restriction, then an administrator gets logged on with an access token with elevation type TokenElevationTypeDefault, which has full administrator access. (The "Administrator" account, i.e. RID 500, is exempt from UAC, but it's disabled by default.) Otherwise an administrator account gets logged on with a linked pair of access tokens, and the logon returns the limited access token with elevation type TokenElevationTypeLimited. For an interactive desktop session, this limited access token is used by default for all created processes. It has medium integrity level, no administrator privileges (e.g. no SeDebugPrivilege, SeBackupPrivilege, etc), and the administrators group is enabled only for access-denied entries in an object's discretionary access control list (DACL). 

In order to get full administrator access, a request to create an elevated process can be sent to the Appinfo (application information) service, which creates the process with the linked TokenElevationTypeFull access token. The desktop shell's "run as administrator" option does this. The full access token has high (elevated) integrity level, administrator privileges, and the administrators group enabled for granting access via access-allowed entries in an object's DACL. An administrator may not be aware of this because the OS allows some trusted programs to execute with the unlimited access token without prompting for consent. 

One can also elevate via the Task Scheduler service. A task can be executed on demand via the scheduler COM API, the task scheduler GUI, or CLI `schtasks.exe /run /tn taskname`.

I wish you the best of luck in resolving your configuration issues, but this is not a bug in Python. Further discussion is not within the scope of this issue tracker.