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.)

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.

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][1]. For Server 2012 R2, [KB2919355][2] should be installed first.

[1]: http://www.microsoft.com/en-us/download/details.aspx?id=48234
[2]: http://www.microsoft.com/en-us/download/details.aspx?id=42334

> 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%.

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"?

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

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.

> 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.

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?).

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.)

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.

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.