Ok, this means that the exception is raised after the finally, when the 
thread is exiting.
Now, at this point the process is exiting and therefore we have trouble 
printing the exception.  (this is probably also the cause of the 
exception in the first place, some cleanup that fails because the 
process is exiting).
Now, the traceback printing code is complex and it could fail in a 
multitude of places, but from the stuff that is output, it would appear 
that printing to sys.stderr is failing.  To find out the error, we need 
to goad python into displaying the exception, even though the process is 
exiting.
On a windows machiine, I would put a DebugBreak() call in t_bootstrap() 
in threadmodule_t and try to find out where the error output code is 
failing.  I don't know if you can do just-in-time debugging on your 
machine.  It would be best, of course, to singlestep through the code at 
line 452 in threadmodule.c.  Then we could pinpoint where the output is 
failing and fix python to make it more resilient at process exit.

Now, lines 452-455 don't produce any output.  For starters, try to 
insert "file=0" before line 452 in threadmodule.c, so that 
PyObject_Print is called instead of PyFile_WriteObject() (which I think 
is failing.)
If that produces output, then we can proceed to hardwire "stderr" into 
the traceback stuff.