Hi

I have a java program running on a windows platform which makes calls
to an external product (dll, .NET) through JNI.

In most cases where an exception is generated in the external code,
the JVM catches it and exits with a mesage "an exception has occurred
in native code outside the VM", and an hs_err_pid file is created.

However, recently I have had cases where the VM exits abruptly, with
no error message and no hs_err_pid file.

After such a crash, by typing "echo %ERRORLEVEL" at the windows
command prompt, the code -529697949 is reported. In hex, this is
0xE06D7363, which from what I have read on the web indicates that the
exception was generated within C++ code when a Win32 Structured
Exception occured.

So it is likely that the exception is occuring somewhere external dll.
The java program's logs lend some support to this theory, but not
conclusive support.

It is possible that when the exception occurs, a C++ abort() is being
called somewhere in the dll, or a dll underneath it.

Another possibility that the exception is being thrown back to the
JVM, but not handled here, causing the abrupt crash. Does Sun's
Windows JVM catch Win32 Structured Exceptions?

Ta,

Barney

On 2 Sep 2004 00:45:44 -0700, Barney wrote:
> I have a java program running on a windows platform which makes
> calls to an external product (dll, .NET) through JNI.
>
> In most cases where an exception is generated in the external code,
> the JVM catches it and exits with a mesage "an exception has
> occurred in native code outside the VM", and an hs_err_pid file is
> created.
>
> However, recently I have had cases where the VM exits abruptly, with
> no error message and no hs_err_pid file.
>
> After such a crash, by typing "echo %ERRORLEVEL" at the windows
> command prompt, the code -529697949 is reported. In hex, this is
> 0xE06D7363, which from what I have read on the web indicates that
> the exception was generated within C++ code when a Win32 Structured
> Exception occured.

Most likely these are not exceptions invoked explicitely by the native
code, rather they are caused by errors in the code and caught by the
operating system, which then kills the process.

Typically, attempting to read or write memory that you had no business
accessing will cause the JVM to crash in the manner you describe. Look
for things like sloppy use of pointers, uninitialized variables, etc.

/gordon

Barney wrote:

> It is possible that when the exception occurs, a C++ abort() is being
> called somewhere in the dll, or a dll underneath it.

You may be able to get more information by running your Java program under the
control of a (non-java) debugger. E.g. start the windows executable program,
java.exe, under VC++. That should catch and halt at abort() or uncaught
Windows exception, and you may be able to work something out from the stack
trace and list of threads. It's a bit of a long shot, mind. You stand a
marginally better chance of tracking it down if you have the "symbol" files for
your windows version installed too (you can get them from MS site).

-- chris