The problem(abort/hung up) was found in customer's applet application.

JDK : 5.0u11
OS : Windows Vista

After analyzing the dump, Fujitsu found the thread where the problem
occurred used JNIEnv* that belonged to another thread.

---
[j2se/src/windows/native/sun/windows/awt_Toolkit.cpp]
  ...
JNIEnv* AwtToolkit::m_env;
HANDLE AwtToolkit::m_thread;

void AwtToolkit::SetEnv(JNIEnv *env) {
    if (m_env != NULL) { // If already cashed (by means of embeddedInit() call).
        return;
    }
    m_thread = GetCurrentThread();
    m_env = env;
}

JNIEnv* AwtToolkit::GetEnv() {
    return (m_env == NULL || m_thread != GetCurrentThread()) ?
        (JNIEnv*)JNU_GetEnv(jvm, JNI_VERSION_1_2) : m_env;
}
---

The above snippet is where JNIEnv * was used that was set by another thread.
The code uses Windows API GetCurrentThread() that always returns a
constant according to the following page.

http://msdn.microsoft.com/en-us/library/ms683182.aspx
---
GetCurrentThread()
 Return Value
   The return value is a pseudo handle for the current thread.
 Remarks
   A pseudo handle is a special constant that is interpreted
                        ~~~~~~~~~~~~~~~~
   as the current thread handle. The calling thread can use this handle
   to specify itself whenever a thread handle is required.
   Pseudo handles are not inherited by child processes.
---

It is wrong that the AWT code uses the return value of
GetCurrentThread() as thread identity. GetCurrentThreadId() should be
used if Windows API is used.

Additionally, we found the some codes where call AwtToolkit::GetEnv()
and get returned JNIEnv* uses JNU_GetEnv(). These should to be fixed to
call JNU_GetEnv(jvm, JNI_VERSION_1_2).