In Python 2.3.4, if you run pydoc -g under Windows XP
when one of the special XP theme manifest files has
been defined for python.exe or pythonw.exe, pydoc will
cause an access violation when it closes.  One solution
is obviously to get rid of the manifest files, but
wxPython installs them by default and apps written with
it work without a problem.  So it would be nice if
pydoc would also work, and it turns out it didn't take
a big change.  Attached is a patch which fixes the
problem (at least on my system).  I noticed that idle
did not have the access violation problem, and so
copied what it does in PyShell.main.

It might be better to introduce a more general fix for
Tkinter.  The problem seems to be that Uxtheme.dll
frees up some global data before all the windows have
called CloseThemeData (at app shutdown).  The AV seems
to happen when a call to CloseThemeData (presumably in
response to a WM_DESTROY message) passes a bad pointer
to RtlEnterCriticalSection.  Anyway, it seems that if
you get the window handles destroyed earlier in
shutdown, the problem is fixed.  Perhaps there is some
way to provide the Tkinter module with an atexit
handler which would destroy any existing widgets?

Logged In: YES 
user_id=21627

This is quite an obscure problem, so I added a comment an
committed it as pydoc.py 1.86.8.3 and 1.97, NEWS 1.831.4.144.

Logged In: YES 
user_id=86307

I admit the cause is obscure, but I think the problem will
potentially affect most Tkinter programs (see for example,
www.python.org/sf/774188 -- which links to a wiki article
referring to crashes in Tkinter with manifest files
present).  I just tried pynche.pyw, redemo.py, wcgui.py, and
wsgui.py (from the Tools branch) and they all crashed on
exit (at the same location in kernel32, with the same
attempt to read 0x00000028).  This is with Python 2.3.4
under XP (I don't have access to an XP SP2 machine right
now: I wonder if this has been fixed).

Anyway, I added the following to Tkinter, and the crashes
went away (I don't usually use Tkinter, so this may not be
the best way to accomplish this):

import atexit

def _tkAtExit():
    if _default_root is not None:
        _default_root.destroy()

atexit.register(_tkAtExit)

Logged In: YES 
user_id=21627

I'd still woud prefer if a "proper" patch would be found,
i.e. one that doesn't cause a crash in response to
WM_DESTROY. For that, one would have to understand why it
crashes, and see whether it is Tk's fault - if so, Tk should
be fixed. If it really is presumed to be a Windows
bug/limitation, I'd like to see the KB article that
acknowledges the problem, and apply the work-around
suggested in the KB.

Logged In: YES 
user_id=86307

I'm fairly sure the problem is that Tk is calling
DestroyWindow (a User32 function) during handling of a
DLL_PROCESS_DETACH; according to the documentation of
DllMain this is unsupported and may cause access violations
(only calls to Kernel32.dll routines are safe).  The reason
for the AV is presumably that uxtheme.dll gets
DLL_PROCESS_DETACH first and frees its global data (I
believe the AV only happens if DestroyWindow is called on
windows which are, or have children which are, themed
controls).  I haven't built a debug version of the Tk dlls
since I'm not actually sure what source base is used to
produce them.  However, if they are produced from the
tktoolkit project on sourceforge, it appears
DLL_PROCESS_DETACH results in a call to TkFinalize, which
runs a set of exit handlers.  It appears one of these is
DeleteWindowsExitProc, which calls Tk_DestroyWindow on
various windows.  If various conditions are met, this will
result in a call to XDestroyWindow, which may in turn call
DestroyWindow.

Perhaps the answer is to reinstate the Py_AtExit
registration of Tcl_Finalize.  On windows, anyway, the
problem noted in the comment in _tkinter.c still exists in
Python 2.3.4.  If you give a <Destroy> handler to a window
which is not destroyed by Python, it is apparently destroyed
with the DLL cleanup code, triggering a Python fatal error
for a NULL thread state (see the attached test.py, a hacked
up wsgui which I've been using for testing).  So anyway,
some other fix is needed for the <Destroy> handler problem,
and it looks like Tcl_Finalize would run the Tk exit procs
before the handling of DLL_PROCESS_DETACH.