I have had a look at this using the latest trunk code built using VisualStudio 2005 on Windows XP SP2.

I modified the source scripts from bug2.zip so that the code was wrapped in a function and added the same code as a function to main.py; I did this so as to see if the difference in calling method would affect it at all, i.e. if by removing the import of sub.py it would make the issue any better or worse.

Running it in the debugger and modifying the debug output from the engine to include Win32 thread identifiers seems to suggest that the main thread is exiting and cleaning up the Python system modules and then the Win32 system is closing the other Python threads which are then trying to access the global Python modules and they can't find them and they exit. [Though as a /total/ newbie to Python I am only about 40-50% confident of this] And as to be expected the error does not happen all the time - I can run the same script and maybe get the error as listed maybe about 60-70% of the time.

Interestingly in main.c there is a call to a function called "WaitForThreadShutdown" - but sadly it only looks to see if the Python threading module has been imported. I think extending this function to include the Python thread module might be the way to go - but I really don't know and I certainly haven't got to grips with the Python source yet.