This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author The Compiler
Recipients The Compiler, astrand, paul.moore, steve.dower, tim.golden, zach.ware
Date 2015-06-23.20:37:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Trying to call a 32bit Python via subprocess from a 64bit one works as expected:

    Python 3.4.2 (v3.4.2:ab2c023a9432, Oct  6 2014, 22:16:31) [MSC v.1600 64 bit (AMD64)] on win32
    >>> subprocess.check_call([r'C:\Python34_x32\python.exe', '-c', 'print("Hello World")'])
    Hello World

However, when passing the `env` parameter, even just as `env=os.environ`, things break:

    >>> subprocess.check_call([r'C:\Python34_x32\python.exe', '-c', 'print("Hello World")'], env=os.environ)
    Fatal Python error: Failed to initialize Windows random API (CryptoGen)

Starting a 64bit Python from the 64bit one works fine:

    >>> subprocess.check_call([r'C:\Python34\python.exe', '-c', 'print("Hello World")'], env=os.environ)
    Hello World

According to issue20614 the "Fatal Python error" happens when SYSTEMROOT is not set, but that's definitely set in the original environment.

Looking at the code, it just passes env to Windows' CreateProcess[1] - I guess this does *something* different in this scenario when None/NULL is given as compared to the os.environ dict?

This breaks virtualenv with --python for me:

    C:\Users\florian\tmp>C:\Python34\python.exe -m virtualenv --python=C:\Python34_x32\python.exe venv3
    Running virtualenv with interpreter C:\Python34_x32\python.exe
    Fatal Python error: Failed to initialize Windows random API (CryptoGen)

Date User Action Args
2015-06-23 20:37:07The Compilersetrecipients: + The Compiler, paul.moore, astrand, tim.golden, zach.ware, steve.dower
2015-06-23 20:37:07The Compilersetmessageid: <>
2015-06-23 20:37:07The Compilerlinkissue24493 messages
2015-06-23 20:37:07The Compilercreate