Note the error message in the title is only for Python 2.x - Python 3.x shows an empty string instead, but otherwise seems identical.

This was first brought to my attention via http://sourceforge.net/tracker/?func=detail&aid=3528888&group_id=78018&atid=551954.  I can reproduce it (see below) with the pywin32 installer but believe the problem will exist with any such installer.  All tests done on a Win7x64 VM.  Symptoms are:

* Run the installer with UAC enabled - reliably works.  All "print" statements from the post-install script are shown in the final dialog.

* Disable UAC.  The installation reliably ends with the "close failed..." message shown in the final dialog.  No print output is shown.  The installation did actually complete (but is likely to fail if the output fills stdout buffering).  The UAC is probably relevant as when UAC is enabled, the installer re-spawns itself with elevation.

* The problem with UAC disabled can be reproduced running in the VS debugger.  The problem is that Python sees stdout and stderr with a FILE object that has a fileno of -2 (ie, of _NO_CONSOLE_FILENO).  Then, when Python is finalizing it tries to close these handles and fails due to the invalid fileno.  The other messages are a consequence of the fact stderr itself is what is being closed (ie, Python is trying to report a problem closing stderr to stderr.)  Python 3 seems to handle this case better courtesy of issue 1415, but the fact the output is lost remains in both versions.

* Looking over the installer code, I notice that Python is initialized and terminated twice to compile .pyc/.pyo, then initialized a third time in preparation to run the install script - the handles are redirected prior to initializing the 3rd time.  On a hunch, I hacked the code to perform the redirection *before* Python is initialized for the first time.  This solved the problem when run under the debugger but still failed when run stand-alone (*sigh*).  I fiddled with some params to CreateFile in the redirection code but could not get things working.  Note that avoiding the multiple init/finalize calls may be problematic as Py_OptimizeFlag is set differently between runs.

* I looked over the CRT init code to try and determine why _NO_CONSOLE_FILENO was being used.  It appears the CRT attempts to use the process STARTUPINFO and only falls back to GetStdHandle if that STARTUPINFO doesn't provide valid handles.  So I tried both using GetStartupInfo and putting the redirect handles in the result, and explicitly closing the old std handles, but neither of them worked.

Next step is probably to arrange to step through the CRT init code to see what is going on there.  I doubt I will get back to this any time soon, so this is my attempt at detailing what I've discovered to date incase someone else has a look...