This problem seems to occur whenever AttachCurrentThread is called from
outside of the main thread.

Operating System: Windows NT 4.0
     Hardware: Pentium / various speeds and memory
     JDK: 1.1.1 (similar symptoms with earlier JDK's)
     Compiler: MSVC++ 4.2
     Language: C++
     Explanation:
     The application need to create and manage MFC objects within multiple
     Threads. The only supported mechanism of creating threads that can
     use MFC objects is AfxBeginThread(). Microsoft documents this
     requirement and adhoc testing verifies that creating MFC objects
     (specifically any CWnd derived object) from within a thread not
     created with AfxBeginThread() causes runtime asserts crashes.
     Therefore the application cannot use new java.lang.Thread to create
     threads that will later create or access MFC objects.
     
     To solve this problem a SalThread class is defined with native methods
     that uses AfxBeginThread to create the native NT thread and then uses
     AttachCurrentThread() to attach the thread to the java runtime.
     
     The invocation of AttachCurrentThread returns successful, however the
     JNIEnv* object which is returned is unusable. Any JNIEnv method calls
     produce either incorrect results or runtime crashes. In particular
     CallVoidMethod () crashes the VM.
     
     A workaround that is partially successful is to ignore the JNIEnv*
     returned by AttachCurrentThread() and instead use the JNIEnv* of the
     main thread. This allows java methods to be called with
     CallVoidMethod (). Using java.lang.Thread methods in the new thread
     are mostly successful. For example,
     java.lang.Thread.currentThread() returns a different object in the new
     thread. java.lang.Thread.getName() returns a new name in the new
     thread.
     
     Unfortunately, this is contrary to the JDK documentation which asserts
     that you should never use a JNIEnv* from a different thread. Also
     various strange and inexplicable runtime errors occur regularly after
     creating the new thread. These include (but are not limited to)
     
     ú Java VM stack tracebacks often show merged stacks from different
     threads.
     ú The JNIEnv* argument in native method calls is always the same in
     all threads (not thread specific).
     ú Occasional corruption of thread local storage (TlsAlloc() ) ** May
     not be related.
     ú Spurious and apparently random java exceptions that terminate the
     app.
     ú Occasional failure of wait/notify synchronization with exception
     complaining about corrupt monitor state.
     ú Occasional unexplained failure (and/or exception) of JNIEnv
     methods.
     
     Background
     Here is some background that may or may not be useful to help diagnose
     this problem.
     
     The application is implemented as an AFX Extension .DLL. A Native
     method is called early in the java main() routine. This native method
     initializes AFX and windows systems then enters the Afx CWnd::Run()
     method for the duration of the application. When WIN32 messages
     arrive the application dispatches these into java method calls using
     the JNI interface.
     
     New threads are created with the java SalThread class. This class
     exports a public method to create a new SalThread object with an
     associated native and java thread. The public method ( createThread()
     ) invokes AfxBeginThread() to create a new thread. The InitInstance
     member of the new thread object invokes AttachCurrentThread() then
     calls CallVoidMethod () to call the init method of the new SalThread
     objected (object was passed as argument to the native method). When
     the init method returns then The init method of SalThread eventually
     calls another
     
     The sample `attach.c' file in the JNI tutorial :
     http://java.sun.com/nav/read/Tutorial/native1.1/implementing/invo.html
     works fine. However, this sample uses _beginthread() not
     AfxBeginThread() which may be a significant difference. We cannot use
     _beginthread() for reasons explained above. I attempted to rewrite
     the JNI portions of the code to use C instead of C++ bindings as is
     done with attach.c, but it failed in the same way as the C++ code.
     
     Differences between the sample attach.c and our code: (may or may not
     be relevant)
     ú attach.c is in C, our code is C++
     ú attach.c code creates the java VM, while in our code this is done
     with java.exe
     ú attach.c is a `console application', our code is MFC based.
     ú attach.c is an executable (.EXE), our code is a MFC Extension DLL
     ú attach.c uses _beginthread(), our code uses AfxBeginThread
     
     
     Code Fragment
     
     Here is the C++ code fragment that attempts to call
     AttachCurrentThread() and CallVoidMethod().
     Code bracketed by `#if DOCUMENTED_TO_WORK_BUT_DOESNT_IN_JDK_1_0B' is
     code that should work as documented but does not in fact work. Full
     C++ and java source available.
      
     
     
      
     
     // NOTE: Member object `m_init' contains values populated by the
     // parent thread before calling AfxBeginThread().
     // For refrence, here is the class def:
     
     
     class SalThreadInit {
     public:Operating System: Windows NT 4.0
     Hardware: Pentium / various speeds and memory
     JDK: 1.1.1 (similar symptoms with earlier JDK's)
     Compiler: MSVC++ 4.2
     Language: C++
     Explanation:
     The application need to create and manage MFC objects within multiple
     Threads. The only supported mechanism of creating threads that can
     use MFC objects is AfxBeginThread(). Microsoft documents this
     requirement and adhoc testing verifies that creating MFC objects
     (specifically any CWnd derived object) from within a thread not
     created with AfxBeginThread() causes runtime asserts crashes.
     Therefore the application cannot use new java.lang.Thread to create
     threads that will later create or access MFC objects.
     
     To solve this problem a SalThread class is defined with native methods
     that uses AfxBeginThread to create the native NT thread and then uses
     AttachCurrentThread() to attach the thread to the java runtime.
     
     The invocation of AttachCurrentThread returns successful, however the
     JNIEnv* object which is returned is unusable. Any JNIEnv method calls
     produce either incorrect results or runtime crashes. In particular
     CallVoidMethod () crashes the VM.
     
     A workaround that is partially successful is to ignore the JNIEnv*
     returned by AttachCurrentThread() and instead use the JNIEnv* of the
     main thread. This allows java methods to be called with
     CallVoidMethod (). Using java.lang.Thread methods in the new thread
     are mostly successful. For example,
     java.lang.Thread.currentThread() returns a different object in the new
     thread. java.lang.Thread.getName() returns a new name in the new
     thread.
     
     Unfortunately, this is contrary to the JDK documentation which asserts
     that you should never use a JNIEnv* from a different thread. Also
     various strange and inexplicable runtime errors occur regularly after
     creating the new thread. These include (but are not limited to)
     
     ú Java VM stack tracebacks often show merged stacks from different
     threads.
     ú The JNIEnv* argument in native method calls is always the same in
     all threads (not thread specific).
     ú Occasional corruption of thread local storage (TlsAlloc() ) ** May
     not be related.
     ú Spurious and apparently random java exceptions that terminate the
     app.
     ú Occasional failure of wait/notify synchronization with exception
     complaining about corrupt monitor state.
     ú Occasional unexplained failure (and/or exception) of JNIEnv
     methods.
     
     Background
     Here is some background that may or may not be useful to help diagnose
     this problem.
     
     The application is implemented as an AFX Extension .DLL. A Native
     method is called early in the java main() routine. This native method
     initializes AFX and windows systems then enters the Afx CWnd::Run()
     method for the duration of the application. When WIN32 messages
     arrive the application dispatches these into java method calls using
     the JNI interface.
     
     New threads are created with the java SalThread class. This class
     exports a public method to create a new SalThread object with an
     associated native and java thread. The public method ( createThread()
     ) invokes AfxBeginThread() to create a new thread. The InitInstance
     member of the new thread object invokes AttachCurrentThread() then
     calls CallVoidMethod () to call the init method of the new SalThread
     objected (object was passed as argument to the native method). When
     the init method returns then The init method of SalThread eventually
     calls another
     
     The sample `attach.c' file in the JNI tutorial :
     http://java.sun.com/nav/read/Tutorial/native1.1/implementing/invo.html
     works fine. However, this sample uses _beginthread() not
     AfxBeginThread() which may be a significant difference. We cannot use
     _beginthread() for reasons explained above. I attempted to rewrite
     the JNI portions of the code to use C instead of C++ bindings as is
     done with attach.c, but it failed in the same way as the C++ code.
     
     Differences between the sample attach.c and our code: (may or may not
     be relevant)
     ú attach.c is in C, our code is C++
     ú attach.c code creates the java VM, while in our code this is done
     with java.exe
     ú attach.c is a `console application', our code is MFC based.
     ú attach.c is an executable (.EXE), our code is a MFC Extension DLL
     ú attach.c uses _beginthread(), our code uses AfxBeginThread
     
     
     Code Fragment
     
     Here is the C++ code fragment that attempts to call
     AttachCurrentThread() and CallVoidMethod().
     Code bracketed by `#if DOCUMENTED_TO_WORK_BUT_DOESNT_IN_JDK_1_0B' is
     code that should work as documented but does not in fact work. Full
     C++ and java source available.
      
     
     
      
     
     // NOTE: Member object `m_init' contains values populated by the
     // parent thread before calling AfxBeginThread().
     // For refrence, here is the class def:
     
     
     class SalThreadInit {
     
        JavaVM *m_jvm; // Java VM of calling thread
        jobject m_jthis; // Java object 'this' derived from SalThread
        JNIEnv *m_jenv; // Java JNIEnv from calling thread ;
        jmethodID m_methodID; // pre-calculated method ID of `init'
     } ;
     //
     // Called from AfxBeginThread to start the thread running.
     // This is called in the context of the newly created thread
     //
     
     BOOL SalThread::InitInstance()
     {
        JDK1_1AttachArgs attachArgs ;
        JNIEnv *j_env = 0;
     
        ASSERT( m_init );
        if( ! m_init )
                return FALSE ;
     
     
        m_tid = GetCurrentThreadId();
     
        // First attach to the current thread
        
        int result = m_init->m_jvm->AttachCurrentThread( &j_env ,
     &attachArgs );
        ASSERT( result == 0 );
        ASSERT( j_env );
     
        
        
     #if DOCUMENTED_TO_WORK_BUT_DOESNT_IN_JDK_1_0B
     // This code is *supposed* to work but causes various runtime errors
     // and crashes. Therefore pre-collect all this data in the init
     // routine
     
        // Get java class for 'this'
        jclass j_class = j_env->GetObjectClass( m_init->m_jthis );
     
        // HERE j_class == 0
        ASSERT( j_class );
        
        // HERE crashes if we try to use the 0 j_class
        jmethodID j_methodID = m_init->m_jenv->GetMethodID( j_class ,
     "init" , "()V" );
        ASSERT( j_methodID );
     
     
     #endif
        
     // Store the init pointer and clear m_init so that a new thread can be
     // created
        SalThreadInit *init = m_init ;
        m_init = 0;
     
     
        // Remember the new j_env for later use
        m_jenv = j_env;
         
        // Init pointer to the SalThreadImp object
        m_jthis = init->m_jthis ;
        
        // Init the TLS data for this thread
        ST_tls->m_thread = this ;
        ST_tls->m_tid = m_tid ;
     
     
     
     
        // Store map of TID to SalThread
        {
                CRLock lock( crSalThread );
                mapTidToThread.SetAt((void*) m_tid , this );
        }
     
     
     #if DOCUMENTED_TO_WORK_BUT_DOESNT_IN_JDK_1_0B
     // This code is *supposed* to work but causes various runtime errors
     // and crashes. Therefore pre-collect all this data in the init
     // routine
     // and use the *WRONG* j_env in the 'real' code.
     // Try this again when we convert to JDK1.1
     
        j_env->CallVoidMethod( init->m_jthis , j_methodID , (int) this );
     #else
     // Use the JNIEnv* from the parent thread to make the call, it
     //works!
        // NOTE: THIS IS ABSOLUTELY AGAINST THE DOCUMENTATION !!!
     
     // Using the JNIEnv* from AttachCurrentThread() causes runtime
     //crashes
     
        init->m_jenv->CallVoidMethod( init->m_jthis , init->m_methodID ,
     (int) this );
     #endif
        // Delete the temporary init object
        delete init ;
        
     
     
        // Dont enter the RUN loop ... this was done by init.
        return FALSE;
     }