Ensurepip failing with "Access is denied" error when attempting to read Windows registry

Hi folks, I’m here with a bizarre problem; for months now I’ve just been stuck with Python 3.9 as every time I install 3.10/3.11 I can’t use pip. The normal Windows installer fails to install pip (silently), and using the module “ensurepip” fails with a “WinError 5 Access is denied”. I’ve looked through the code and found that it is failing on this particular step: _mimetypes_read_windows_registry(add_type) which seems to imply an issue reading the registry or something similar. Months ago when I first encountered this problem I eventually manually installed pip but it would run into a similar registry error. This issue does not occur with Python 3.9 or below. Any ideas on how to get this fixed? Thanks!

Pip is installed when python is installed for the python.org installers.
Not sure why you need to use ensurepip at all.

Right, it should be but it isn’t. I’ve un/reinstalled quite a few times now, both with 3.10 and 3.11. I’m using their Windows 64-bit installers each time.

The installer uses the ensurepip bundle. If it fails, then pip won’t be installed.

This function opens the pseudohandle HKEY_CLASSES_ROOT, a merged view of the system and user “Software\Classes”, in order to read all of the defined “Content Type” values. The add_type parameter is a function that gets called to update the types mapping for each type that’s found in the registry.

Try the following:

import mimetypes

This fails with the same error: PermissionError: [WinError 5] Access is denied
Just a note, running as admin doesn’t make a difference.

Check for read access to the HKCR merged view:

import winreg
hkcr = winreg.OpenKey(winreg.HKEY_CLASSES_ROOT, None)

If the above fails, check for read access to the individual registry keys:

import winreg 
hkcru = winreg.OpenKey(winreg.HKEY_CURRENT_USER, 'Software\\Classes')
hkcrm = winreg.OpenKey(winreg.HKEY_LOCAL_MACHINE, 'Software\\Classes')

This worked with no issues. Individual keys worked fine too.

Then there’s a “.<ext>” subkey that doesn’t grant read access, but that should not be a problem. This is a bug in _winapi._mimetypes_read_windows_registry(). This builtin function was implemented to speed up initializing the mimetypes database on Windows. It’s too particular in its error handling. The original implementation based on the winreg module ignored and continued on all errors.

That makes sense; I suppose I should open up an issue on the cpython repo then?

Wow, yeah, just commenting out this

        #Accelerated function if it is available
        if _mimetypes_read_windows_registry:

and skipping straight to the winreg module fallback makes everything work again. Hmm.