Installer fails to install 3.4 on win7 32 bit
Error: cannot register 64 bit component {BE22BD81-ECE5-45BD-83B8-84BA45846A2D} on 32 bit system. KeyPath: C:\Windows\py.exe

Did you try using the 32-bit (x86) installer from https://www.python.org/downloads/release/python-340/ ?  Unfortunately, I believe the default download button currently only downloads the 64-bit version.

Of course, only official sources
the file is named python-3.4.0.msi and 23,924KB
the name is similar to that of earlier versions which worked fine
So I am not sure, whether it is 32 or 64bit
maybe it would be a good idea to use two different names such as x86 and x64?

There are two different names: the 64-bit installer is python-3.4.0.amd64.msi.  But I see now that the error refers to py.exe, which I believe is the Python launcher.  I've nosyed the Windows experts.

This is the first time I've used msilib, but it does appear that the component is marked as 64-bit:

    >>> import msilib
    >>> msidbComponentAttributes64bit = 256
    >>> sql = ("SELECT ComponentId,Attributes FROM Component "
    ...        "WHERE Component='launcher'")
    >>> db = msilib.OpenDatabase('python-3.4.0.msi', msilib.MSIDBOPEN_READONLY)
    >>> v = db.OpenView(sql)
    >>> v.Execute(None)
    >>> r = v.Fetch()
    >>> r.GetString(1)
    '{BE22BD81-ECE5-45BD-83B8-84BA45846A2D}'
    >>> attr = r.GetInteger(2)
    >>> attr
    264
    >>> attr & msidbComponentAttributes64bit
    256

As it should be according to Tools/msi/msi.py:

http://hg.python.org/cpython/file/04f714765c13/Tools/msi/msi.py#l990

Here's the comment regarding this:

    # msidbComponentAttributes64bit = 256; this disables registry redirection
    # to allow setting the SharedDLLs key in the 64-bit portion even for a
    # 32-bit installer.
    # XXX does this still allow to install the component on a 32-bit system?
    # Pick up 32-bit binary always

For reference, the Component table:
http://msdn.microsoft.com/en-us/library/aa368007%28v=vs.85%29.aspx

I guess this is merely describing the problem and not the solution?
(by the way I had no difficulties with the 64bit version on a 64bit 
win7 system)

Would it be possible to produce the binairies myself using the mingw
compiler? The readme says visual c++ is required.

I compile 32 bit debug binaries from repository with the free VC++ express 2010. I presume the 'install' option works.

Nosy-ing the Windows installer experts; I haven't had any problems with this and am not familiar with the MSI library or tool.

FWIW I've never had any installation problems involving py.exe.

eryksun's analysis is correct. If the component is marked 64-bit then it will not install on a 32-bit OS. This needs to be switched for the 32-bit installer.

(I also don't see why you'd want to set the 64-bit SharedDLLs key for a 32-bit DLL. Is there some reason we need to do this?)


The default download button currently gets the 32-bit version of 3.4.1, which is the correct default even for people with a 64-bit system. Up until you realize that your script legitimately needs more than 2GB of memory, nobody needs 64-bit Python (barring external library requirements).

not sure what you mean:
the installer for 64 bit is working fine
the installer for 32 bit is not working - this is true also 
for the new version 3.4.1
for those who may try: compiling is tricky with VC2010 pro

I think what Steve meant is that *if* the 32-bit installer is working right, then it should be the default because it would then work for everyone, while the 64-bit installer cannot possibly work for people with 32-bit windows.

Here is the rationale:

1. py.exe is a 32-bit binary installed into C:\windows, see PEP 397. It's in C:\windows so that it will be on the path for both 32-bit and 64-bit processes.
2. py.exe is installed by multiple installers (both 32-bit and 64-bit, and multiple versions of Python)
3. to do proper reference counting of the installations, the SharedDLLRefcount component flag is enabled for the py.exe component. As a consequence, py.exe will be removed when the last Python installation is uninstalled from the system.
4. there are two different reference counters for a file on Windows: a 32-bit reference counter and a 64 bit reference counter. A 64-bit installer would manipulate the 64-bit counter, and a 32-bit installer would manipulate the 32-bit counter.
5. by default, this would lead to py.exe disappearing after this sequence of installation steps:
   * install 32-bit 3.3
   * install 64-bit 3.4
   * uninstall 64-bit 3.4
   The 32-bit reference counter would still be 1, but the 64-bit uninstallation would only look at the 64-bit counter, removing the file
6. to prevent that, the component is marked as 64-bit even for the 32-bit installer, to manipulate the 64-bit reference counter.

The code contains a comment

# XXX does this still allow to install the component on a 32-bit system?

I never got to test this out of lack of a 32-bit Windows installation, apparently, it doesn't work.

As a work-around, the 32-bit installer could include an additional component installing py.exe, which would be a 32-bit component and be selected if the host system is 32-bit.

Martin v. Löwis wrote:
> I never got to test this out of lack of a 32-bit Windows installation,
> apparently, it doesn't work.

It does work on my 32-bit machine, though; I have had no issues installing 32-bit Python 3.3 or 3.4 on 32-bit Windows 7 Pro.  If there's anything in particular you would like me to test or check, let me know.

That reasoning makes sense. I don't see any other way to achieve the same thing without requiring a newer version of Windows Installer on the machine (msidbComponentAttributesDisableRegistryReflection requires 4.0).

Having a second component for 32-bit OS may be okay. I don't recall whether the component ID or the key path is used for shared DLLs - if it's the ID then you won't be able to do this, but I believe it uses the key path throughout (obviously the OS uses the path, but Windows Installer may not).

The 3.4.1 installer worked fine for me on a 32-bit OS, but it doesn't seem to have added py.exe into the SharedDLLs key (python34.dll is there).

Zachary: It "shouldn't" work for you, given this report. Please run 

msiexec /i <python msi file> /l*v py.log

and attach the (possibly compressed) py.log. Verify that it actually did install py.exe into c:\windows.

Here's the log, and some notes:

Starting state:
- Python 3.3.5 installed to P:\Python33
- Python 3.4.1 installed to P:\Python34
- py[w].exe present in C:\Windows

State after Python 3.4.1 uninstalled by python-3.4.1.msi (and manually removed P:\Python34 which still contained some debris in Lib and Scripts):
- Python 3.3.5 still installed
- Python 3.4.1 uninstalled
- py[w].exe no longer present in C:\Windows

msiexec /i python-3.4.1.msi /l*v py.log
- Installed for all users
- Destination set to P:\Python34
- Components left at default (all selected except 'Add python.exe to Path')
- Install completed successfully
State afterward:
- Python 3.3.5 still installed
- Python 3.4.1 properly installed in P:\Python34
- py[w].exe now present in C:\Windows

Picking through the log, I find that I did actually get the error the OP noted; it just doesn't seem to matter:

"""
MSI (s) (34:04) [14:27:17:664]: Executing op: ComponentRegister(ComponentId={81B1269C-979C-404A-8E3D-D297B7C38622},KeyPath=C:\Windows\py.exe,State=3,,Disk=1,SharedDllRefCount=1,BinaryType=1)
1: {DF32BB9E-3ED8-36B5-A649-E8C845C5F3A2} 2: {81B1269C-979C-404A-8E3D-D297B7C38622} 3: C:\Windows\py.exe 
MSI (s) (34:04) [14:27:17:665]: Error: cannot register 64 bit component {81B1269C-979C-404A-8E3D-D297B7C38622} on 32 bit system. KeyPath: C:\Windows\py.exe
MSI (s) (34:04) [14:27:17:665]: GetSharedDLLKey called with invalid ibtBinaryType argument!
MSI (s) (34:04) [14:27:17:665]: GetSharedDLLKey called with invalid ibtBinaryType argument!
MSI (s) (34:04) [14:27:17:666]: Executing op: ComponentRegister(ComponentId={C170DD8A-2030-4226-A15D-94E881D68233},KeyPath=C:\Windows\pyw.exe,State=3,,Disk=1,SharedDllRefCount=1,BinaryType=1)
1: {DF32BB9E-3ED8-36B5-A649-E8C845C5F3A2} 2: {C170DD8A-2030-4226-A15D-94E881D68233} 3: C:\Windows\pyw.exe 
MSI (s) (34:04) [14:27:17:667]: Error: cannot register 64 bit component {C170DD8A-2030-4226-A15D-94E881D68233} on 32 bit system. KeyPath: C:\Windows\pyw.exe
MSI (s) (34:04) [14:27:17:668]: GetSharedDLLKey called with invalid ibtBinaryType argument!
MSI (s) (34:04) [14:27:17:668]: GetSharedDLLKey called with invalid ibtBinaryType argument!

...

MSI (s) (34:04) [14:27:19:599]: Executing op: SetTargetFolder(Folder=C:\Windows\)
MSI (s) (34:04) [14:27:19:599]: Executing op: SetSourceFolder(Folder=1\)
MSI (s) (34:04) [14:27:19:599]: Executing op: FileCopy(SourceName=PY.EXE|py.exe,SourceCabKey=py.exe,DestName=py.exe,Attributes=512,FileSize=102400,PerTick=65536,,VerifyMedia=1,,,,,CheckCRC=0,Version=3.4.1150.1013,Language=2057,InstallMode=58982400,,,,,,,)
MSI (s) (34:04) [14:27:19:600]: File: C:\Windows\py.exe;	To be installed;	Won't patch;	No existing file
MSI (s) (34:04) [14:27:19:600]: Source for file 'py.exe' is compressed
InstallFiles: File: py.exe,  Directory: C:\Windows\,  Size: 102400
MSI (s) (34:04) [14:27:19:606]: Executing op: FileCopy(SourceName=PYW.EXE|pyw.exe,SourceCabKey=pyw.exe,DestName=pyw.exe,Attributes=512,FileSize=102912,PerTick=65536,,VerifyMedia=1,,,,,CheckCRC=0,Version=3.4.1150.1013,Language=2057,InstallMode=58982400,,,,,,,)
MSI (s) (34:04) [14:27:19:606]: File: C:\Windows\pyw.exe;	To be installed;	Won't patch;	No existing file
MSI (s) (34:04) [14:27:19:606]: Source for file 'pyw.exe' is compressed
InstallFiles: File: pyw.exe,  Directory: C:\Windows\,  Size: 102912
"""

That the removal of 3.4 removes py.exe despite 3.3 still being installed is easy to explain: the registration of the reference counter failed, hence the file was not reference counted, and the first removal decided to remove it (there being no reference counter).

I can't explain why "cannot register 64-bit component" is fatal on some systems and not on others. Steve?

Uwe: where exactly did you get the message in your original report? What steps did you do, and where did the message show up? Did the installation perhaps complete despite this error?

the installer went 2/3 through the process and was installing
already something in the default dir c:\Python34
Then after a small pause the error message was shown
and the installer removed all the files leaving an empty 
..\lib in the default dir

The behavior is quite reproducible with *.msi 
for python 3.4.0 and 3.4.1
Its independent on whether the prior installation dir is removed
or not
It is not an issue of the antivirus software
(I am running win7 prof sp1 with the latest updates)
It is not clear from the process but I am convinced this happens 
when the installer tries to register python in the registry

It never happened with any of the prior python 3.0 to 3.3.5

For the own compiled version I can run python.exe of the 3.4.1
sources but haven tested whether its executing anything fine.
So it does not seem to be a problem of python3.4.x on 32bit

problem is solved

observation
- installer problem only occurred on win7 32 bit with prior python installation
(my working system)
- When repeating the installer problem I noticed that a window was opened very shortly with python.exe running. An error message from this call resulted in the exit process of the installer
- the window popped up only for about 1second. A was reading (taking a video) that it was complaining about an error in numpy when calling imp.py in /python33/lib (the old installation, something wrong with libtool, bootstrap)
- I removed step by step all installed libraries, but the error still appeared
- I removed the prior python 3.3.5 installation completely, now the installer worked
- when opening the window with python, it was downloading something like setuptools (not absolutely sure about the name)
- a test with nose 1.3.3, numpy 1.8.1, scipy 0.14.0 (all from Gohlkes web site) went ok.
- unfortunately, the error message with the registry was not reflecting the problem

Hence, the solution is to remove the prior installation of python. That was not necessary in older versions and not necessary for win7 64 bit: strange.

I believe I may have hit a related issue yesterday.  I'm using Python 3.3.5 (32 and 64 bit) and 3.4.1 (32 and 64 bit) releases all on the same Windows 7SP1/64bit PC (patched with latest MS updates).  The Tkinter applications that I wrote and have been using with 3.x for a while now stopped working sometime after installing 3.4.1 - I only noticed this behavior yesterday.  All the Tkinter apps run fine as .py files (but with an associated console window); however, they no longer run as .pyw files.  Instead, they silently fail.

I checked my file associations/types and I believe they are correct.  The py.exe and pyw.exe files are in the Windows directory.  None of my colleagues have this issue, but they only have one Python installation (3.4.1 64bit).  My users also only have one Python version installed (3.3.5 or 3.4.1) and they are not experiencing this issue.

I did search for a empty file on the path with the same name as the python script that I was trying to execute, as this will lead to silent failures - but I found none.

I also tried using the Python Windows installer repair facility on the Python 3.4.1 64bit install, but that didn't help.  I then uninstalled and reinstalled my Python 3.4.1 64bit release, but that didn't help either.

I did notice that the py.exe and pyw.exe files in my Windows directory were not identical to a colleague's Python 3.4.1 64bit PC.

I then ran pyw.exe via windbg (e.g. windbg pyw.exe -3.4 irtool.pyw, windbg pyw.exe -3.4-32 irtool.pyw) to see if there were obvious errors.  I discovered that my pyw.exe silently fails whenever it is instructed to use the 3.4.1 release.  However, when I specified Python 3.3.5 (pyw.exe -3.3 or -3.3-32) my Tkinter applications ran fine and as expected, without an associated console window.

I'm reasonably certain that I did not intentionally modify the py.exe and pyw.exe files in my Windows directory.

Also, all my scripts start with the following: 
#!/usr/bin/python3

Unfortunately, I'm not able to uninstall 3.3.5, until we upgrade all users to 3.4.x (probably shortly after 3.4.2 is released).

Peter: as it turns out, Uwe actually reported two separate issue. In this tracker, we have a "one issue at a time policy", and I'm relabelling the issue as the one that Uwe initially reported (cannot register 64bit component).

So I'm quite certain that *your* (Peter's) issue is not the same as the one reported here. Please report it in a separate issue. People following up to this, please only follow-up if you want to contribute to the original problem (namely, "cannot register 64 bit component").

Uwe: thanks for your investigation. I understand that the problem you were concerned about (installation failed) is solved with a work-around. If you want to see it properly resolved/investigated, please submit a new bug report, providing detailed steps to reproduce the issue. 

Without such steps, I'm tempted to declare that this was a problem with a third-party library, and not a problem with Python, or a misconfiguration of your machine. It is not plausible that the 3.4 installation would access the 3.3 installation directory, so if it did, it's either because some extension library, or some system administrator, has messed with the configuration (registry or environment variables).

I am following Martin's suggestion that there is no actionable issue here and that new issues be opened with new details if and when available.