Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows installer: precompiling stdlib fails with missing DLL errors #69304

Closed
mgedmin mannequin opened this issue Sep 15, 2015 · 12 comments
Closed

Windows installer: precompiling stdlib fails with missing DLL errors #69304

mgedmin mannequin opened this issue Sep 15, 2015 · 12 comments
Labels
3.8 only security fixes 3.9 only security fixes 3.10 only security fixes OS-windows topic-installation type-bug An unexpected behavior, bug, or error

Comments

@mgedmin
Copy link
Mannequin

mgedmin mannequin commented Sep 15, 2015

BPO 25117
Nosy @terryjreedy, @pfmoore, @mgedmin, @tjguk, @asmeurer, @zware, @eryksun, @zooba
Files
  • Python 3.5.0 installer crash logs.zip: Log files from %TMP%
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
    closed_at = <Date 2021-03-15.22:16:48.323>
    created_at = <Date 2015-09-15.05:26:59.668>
    labels = ['type-bug', 'expert-installation', '3.9', '3.10', '3.8', 'OS-windows']
    title = 'Windows installer: precompiling stdlib fails with missing DLL errors'
    updated_at = <Date 2021-03-15.22:16:48.317>
    user = 'https://github.com/mgedmin'

    bugs.python.org fields:

    activity = <Date 2021-03-15.22:16:48.317>
    actor = 'steve.dower'
    assignee = 'none'
    closed = True
    closed_date = <Date 2021-03-15.22:16:48.323>
    closer = 'steve.dower'
    components = ['Installation', 'Windows']
    creation = <Date 2015-09-15.05:26:59.668>
    creator = 'mgedmin'
    dependencies = []
    files = ['40487']
    hgrepos = []
    issue_num = 25117
    keywords = []
    message_count = 12.0
    messages = ['250722', '250869', '250871', '250872', '250880', '250903', '251374', '251391', '251394', '251412', '388630', '388779']
    nosy_count = 8.0
    nosy_names = ['terry.reedy', 'paul.moore', 'mgedmin', 'tim.golden', 'Aaron.Meurer', 'zach.ware', 'eryksun', 'steve.dower']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue25117'
    versions = ['Python 3.8', 'Python 3.9', 'Python 3.10']

    @mgedmin
    Copy link
    Mannequin Author

    mgedmin mannequin commented Sep 15, 2015

    I installed Python 3.5 on a Windows Server 2012 VM, twice (once the 32-bit, and once the 64-bit version). When it started throwing error dialogs at me, I started taking screenshots: http://imgur.com/a/zwfz4.

    What happened:

    • I selected advanced installation
    • checked "install for all users"
    • changed the install path to c:\python35 (and c:\python35-64)
    • when the installer reached "Precompiling standard library" I got the error: "Python has stopped working".
    • clicking "check online for a solution" produces this explanation: "api-ms-win-crt-runtime-l1-1-0.dll is missing from your computer".
    • dismissing the error dialog leads the installer to say the installation is finished (presumably successfully); Python seems to work.

    (The last dialog about VCRUNTIME140.dll is unrelated -- it's what happens if I try to use Python 3.7 to run virtualenv to create a Python 3.5 virtualenv. I'll file a separate bug, once I figure out if it's a Python or a virtualenv bug.)

    @terryjreedy
    Copy link
    Member

    Pre-compiling should generally not be needed; I try to remember to uncheck it. If you do want everything compiled, read the doc for compileall module.

    @eryksun
    Copy link
    Contributor

    eryksun commented Sep 17, 2015

    There should be a bunch of logs named "Python 3.5.0*.log" in your user's %TEMP% directory. If you don't mind, zip them up and attach the file to this issue for Steve Dower to review when he returns from vacation.

    In the mean time, try directly installing the Universal CRT update, KB2999226. For Server 2012 R2, KB2919355 should be installed first.

    @eryksun
    Copy link
    Contributor

    eryksun commented Sep 17, 2015

    Pre-compiling should generally not be needed

    It's a useful optimization if Python is installed to a directory that doesn't grant write access to regular users, such as %ProgramFiles%.

    @eryksun
    Copy link
    Contributor

    eryksun commented Sep 17, 2015

    Per "Python 3.5.0 (32-bit)_20150914055131.log", the installer detects the OS as NT 6.2.9200 (Windows 8/Server 2012), and installs Windows8-RT-KB2999226-x64.msu.

    [0A68:0EC8][2015-09-14T05:51:31]i001: 
      Burn v3.10.0.1823, 
      Windows v6.2 (Build 9200: Service Pack 0), 
      path: C:\Users\mg\Downloads\python-3.5.0.exe
    
    [0F48:03B4][2015-09-14T05:54:05]i301: 
      Applying execute package: crt_14.0_v6.2_x64, 
      action: Install, 
      path: C:\ProgramData\Package Cache\
            0F275C704EE13CA9E98834DB6DA50D4693FF2BAF\
            Windows8-RT-KB2999226-x64.msu, 
      arguments: '"C:\Windows\SysNative\wusa.exe" 
                  "C:\ProgramData\Package Cache\
                   0F275C704EE13CA9E98834DB6DA50D4693FF2BAF\
                   Windows8-RT-KB2999226-x64.msu" 
                  /quiet /norestart'
    

    which seems to succeed:

    [0A68:0EC8][2015-09-14T05:54:24]i319: 
      Applied execute package: crt_14.0_v6.2_x64, 
      result: 0x0, 
      restart: Required
    

    Yet trying to run py.exe to compile the standard library fails with STATUS_DLL_NOT_FOUND (0xC0000135):

    [0F48:03B4][2015-09-14T05:55:11]i301: 
      Applying execute package: compileall_AllUsers, 
      action: Install, 
      path: C:\ProgramData\Package Cache\
            1D1205B0F2D3B4B31CC368C86271206AEF327163\py.exe, 
      arguments: '"C:\ProgramData\Package Cache\
                   1D1205B0F2D3B4B31CC368C86271206AEF327163\py.exe" 
                  -3.5-32 -E -s -Wi "C:\Python35\Lib\compileall.py" 
                  -f -x "bad_coding|badsyntax|site-packages|py2_|
                         lib2to3\\tests|venv\\scripts" 
                  "C:\Python35\Lib"'
    
    [0F48:03B4][2015-09-14T05:57:24]e000: 
      Error 0xc0000135: Process returned error: 0xc0000135
    

    Your screenshot shows that api-ms-win-crt-runtime-l1-1-0.dll is missing. Does this DLL exist in "%SystemRoot%\SysWOW64"?

    @mgedmin
    Copy link
    Mannequin Author

    mgedmin mannequin commented Sep 17, 2015

    Yes, it exists: http://imgur.com/YCmApN7

    @zooba
    Copy link
    Member

    zooba commented Sep 23, 2015

    The problem here is probably that installing the CRT update required a restart (see the line below from the log), but we didn't interrupt installation to make you restart before continuing.

    From the first log file:

    [0A68:0EC8][2015-09-14T05:54:24]i319: Applied execute package: crt_14.0_v6.2_x64, result: 0x0, restart: Required

    Handling this nicely could be some work. We would want to force the restart immediately if the user is installing pip or precompiling the stdlib, but otherwise they can finish installation and then restart. I'll try and look into this soon, but I don't think it needs to hold up a 3.5.1.

    @eryksun
    Copy link
    Contributor

    eryksun commented Sep 23, 2015

    The problem here is probably that installing the CRT update
    required a restart

    I saw that, but it didn't make any sense to me that the DLL isn't available immediately after wusa.exe exits. Is it in limbo until the system is restarted? I know in Windows 10 these api-ms-win-crt* DLLs are actually virtual API sets managed by the loader (i.e. they all have the same module handle, that of ucrtbase.dll). How does this relate to what's going on with Windows 8/Server 2012, if at all? Marius reports that "Python seems to work", but doesn't mention whether or not a reboot was necessary.

    @zooba
    Copy link
    Member

    zooba commented Sep 23, 2015

    Windows Updates may do something different here. I'd guess it's added to a queue and will be installed on next restart, probably based on something it detected as being in use, or maybe just because it's a server OS (or possibly both - typically a reboot isn't required to install the UCRT for the first time, but maybe an early prerelease version was there?).

    @mgedmin
    Copy link
    Mannequin Author

    mgedmin mannequin commented Sep 23, 2015

    For the record, I rebooted once, after installing both 32-bit and 64-bit versions of Python 3.5.

    (Also, it seems that the Python 3.5 installer didn't install pip for me, which could be fallout from this bug? I had to run python -m ensurepip to get it.)

    @eryksun
    Copy link
    Contributor

    eryksun commented Mar 13, 2021

    Maybe it's worth adding a recommendation in the docs to reboot and try to repair an installation that fails in the final stage due to ucrt not being fully installed yet, i.e. missing api-ms-win-crt-*.dll. Or maybe this case can be detected and display a message box to that end.

    @eryksun eryksun added 3.8 only security fixes 3.9 only security fixes 3.10 only security fixes type-bug An unexpected behavior, bug, or error labels Mar 13, 2021
    @zooba
    Copy link
    Member

    zooba commented Mar 15, 2021

    The UCRT can no longer fail to install - we do an app-local install on Win 8.1, and it's already present on Win 10.

    @zooba zooba closed this as completed Mar 15, 2021
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    3.8 only security fixes 3.9 only security fixes 3.10 only security fixes OS-windows topic-installation type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Development

    No branches or pull requests

    4 participants