IHAC with a NT Service program which starts a Java program. The java
 program is a simple program with a server socket waiting to accept socket
 connections. The program is installed and everything works fine until the user
 decides to log off. Since the Java program is installed through the NT Service,
 the program should continue to work even when the user logs out of the
 system. But on the contrary, the program goes into an unstable state and the
 program hangs. I have enclosed the stack trace which I managed to capture by
 making the NT Service interact with the desktop, so we get to see the console.

 This problem does not occur with JDK1.1.x. This happens only for JDK1.2 and
 greater versions. The Java thread dump and testcase TestNTSvc.tar.Z is
 in the attachments.
 

Follow these instructions to reproduce the problems:
SOURCE MODIFICATION
=============================================================
1)In the clienttest.java file edit line 16:
   s = new Socket("sworks.eng.sun.com",7990);
  with your test system's host address. Save and recompile. 


INSTRUCTIONS FOR INSTALLING SERVICE ON WINDOW NT 4.0
==============================================================

1. Extract the contents of the zip file to say C:\
2. Assuming this, you would now have a directory C:\testntsvc
3. Create an "System Variable" TEST_ROOT in Environment tab of the System
   Properties from the "Control Panel" Settings
and set C:\testntsvc
to
   TEST_ROOT.
4. Append C:\testntsvc to your classpath settings in control panel and also 
   make sure your CLASSPATH is a "System Variable". 
5. Go to DOS command prompt and go to the directory c:\testntsvc
6. Type TestNTSvc -install to install the NTService.
7. Now go to your control panel settings and click on the "Services"
   icon to see if the NT Service "TestNTSvc" is installed.
8. If it has not been installed please contact me at  xxxxx@xxxxx 
or 650 526 3336.
9. If it has been installed, then select the "TestNTSvc"
in the services window, click on the button "Startup" and set
the "StartUp Type" to Manual(from Automatic). 
Also check the checkbox for "Allow Service to interact with the Desktop".
10. Now  click on OK Button and close the control panel settings.
11. Now ensure that you have installed JDK1.1.6, JDK1.1.7b and Java2 on your 
	NT Workstation.
12. Open the file "cmdscripts.cfg" file in C:\testntsvc, and update your
directory path for the various jre vms. You can comment all the lines
except the line which you intend to invoke a particular JVM, so for example
you intend to run jre1.2.2, then the following would be the text in the
file cmdscripts.cfg file:

================================================================================
adm=d:/jdk1.2.2/jre/bin/java -mx256m -DTEST_ROOT=%TEST_ROOT% testserver
#adm=f:/jdk1.1.7b/bin/java -mx256m -classpath %classpath%;f:/testntsvc -DTEST_ROOT=%TEST_ROOT% testserver
#adm=f:/jdk1.1.7b/bin/jre -mx256m -cp f:/testntsvc -DTEST_ROOT=%TEST_ROOT% testserver
adm=f:/jdk1.1.6/bin/jre -cp f:/testntsvc -DTEST_ROOT=%TEST_ROOT% testserver
#adm=f:/jdk1.1.6/bin/java -classpath %classpath%;f:/testntsvc -DTEST_ROOT=%TEST_ROOT% testserver
================================================================================
13. Save the file and close it.
14. Reboot your workstation so that the classpath and the new "System
variables" comes into effect.
15. After booting go to the control panel.
16. Go to the services panel in control panel and
start the NT Service "TestNTSvc". You should now see the Java console
for d:/jdk1.2.2/bin/jre with the statement "Getting Connected" being printed
in the console.

17. Run the Java test program testclient.java on the command prompt,
by typing in at the command prompt c:\testntsvc>java testclient
18. The program works and  exits normally after printing the statements
"Creating a Socket", "Created the client Socket" on the console. This 
is what a remote client system would see when accessing the Server service.

19. Now try logging off the NT Workstation and you will see in the Java console
    that the JVM dumps a Java thread trace and the service hangs unresponsive
    when you log back in.






java version "1.3.0rc2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0rc2-Y)
Java HotSpot(TM) Client VM (build 1.3.0rc2-Y, mixed mode)


I'm writing NT-service by JDK1.3 (and some C codes).

1.NT-service start by manual. (check "System Account")
2.logoff

...then, NT-service(running JVM in service) stop process.

I hope, cancel shutdown JVM.
(Review ID: 103003)
======================================================================




java version "1.3.0rc1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0rc1-T)
Java HotSpot(TM) Client VM (build 1.3.0rc1-S, mixed mode)

Using ServiceInstaller 1.1 (http://www.kcmultimedia.com/smaster) install a
simple Java app as a service that outputs some trivial data to a file every
10 seconds.

Here's the simple demo service:

import java.io.*;
import java.util.*;


public class Test2
{
    public static void main(String[] args)
    {

        Date now;
        PrintWriter out;

        try{

            

            while(true){

                now = new Date();
                out = new PrintWriter(new FileWriter("test2.out",true), true);
                out.println(now.toString());
                out.close();

                Thread.sleep(10000);

            }

        }catch(Exception e){

            System.out.println(e.toString());

        }
    }
}

Start the service from the Control Panel|Services Applet, and check the
contents of the file test2.out, which should append a line showing the
date and time each 10 sec.

Log off, and log back in.

Although NT thinks the service is still running, it is not. You will see
that lines are no longer appended to the file.

This seems to only occur with JDK 1.3 RC1. Under JDK 1.2.2, the test app
keeps running thru the login/logout
(Review ID: 102993)
======================================================================




java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

I am using JNI 1.2 with JRE 1.3:

Write an NT Service that uses JNI to call the main method of a Java class
(NOTE user.name will be "SYSTEM")

Install & start the service.

Logoff.

Service dies!!!

NOTE:  JRE 1.2 deals with this correctly--when user logs back in the service is
still running.

I have thoroughly checked that my code is not exiting--
    env->CallStaticVoidMethod(jcl, m_methID, m_jobjArr);
never returns & there exists NO System.exit() in my java class.
(Review ID: 111892)
======================================================================

The workaround is to create a new thread in the parent process to read the pipe.
In this way, the pipe between the parent and child process will not get overflowed. The application will not hang any more. Also if the return value 
from read is -1, the read thread may be dismissed to retain resources.

 xxxxx@xxxxx  2000-06-02

It seems that this is not a bug.

In 1.1.x, runtime.exec create a new process which is a detached process, so the
child process will not accept signals (like ctrl+break) from the console of the 
parent process. That's why in 1.1.x, there's no thread dump. 

In 1.2.2, runtime.exec create a new attached process, the child process can 
still accept the signal from the console of the parent process, it's stderr is 
linked to the parent's pipe. After it received the signal, it sent out thread 
dump to stderr which redirects to the pipe, as the pipe has a limited capacity, 
another thread needs to read from the pipe to keep it going, otherwise, 
the child process appears hang.


 xxxxx@xxxxx  2000-04-18

------------------------------------------------------------

The evaluation above is incorrect; a corrected one follows. A solution
exists for this problem; please see the end of this evaluation for it.

The problem was caused by the addition of the shutdown hook mechanism
to 1.3. Shutdown hooks, compared to the System.runFinalizersOnExit()
mechanism, have stronger guarantees regarding when they are run; for
example, if the VM is terminated by a Ctrl-C, finalizers will not be
executed via runFinalizersOnExit, but shutdown hooks will be run.

On Win32, shutdown hooks are implemented by adding a console control
handler (see the documentation for SetConsoleCtrlHandler) which, upon
seeing a condition like a Control-C or a "user logoff event", raises
the termination condition in the VM. This causes the shutdown hooks to
be run.

Both the shutdown hook mechanism and the Ctrl-Break stack dump require
signal-like information. 1.2 implemented the Ctrl-Break stack dump
using the POSIX "signal" call on Win32. It turns out (as was noted in
the 1.3 VM code by  xxxxx@xxxxx ) that this mechanism translates all
console events except Ctrl-C into SIGBREAK, which is not sufficient
granularity to support both Ctrl-Break and shutdown hooks. This is why
the console control handler was added in 1.3.

When the VM's console handler receives the CTRL_LOGOFF_EVENT, it
informs the rest of the VM of pending termination (thereby causing
shutdown hooks to be run) and returns TRUE. According to the MSDN
documentation, a return value of TRUE for this event will cause the
popup window for process termination to be displayed. It seems that
this return value was chosen because the VM is still doing work
(running the shutdown hooks asynchronously) after the
CTRL_LOGOFF_EVENT is received, and the author thought that returning
false would cause the VM to be terminated by the OS while doing this
work (as is stated in the MSDN documentation: the system's default
handler terminates the process).

The MSDN documentation is not specific about the relationship between
services and the CTRL_LOGOFF_EVENT. Conceptually, a service runs in
the background and should not be associated with any particular user's
login session, so one might expect that a service should not be
notified of logoff events. However, Win32 does send these events to
services. Interestingly, the default console handler for services
differs from the default for ordinary console processes; services
continue to run after their default handler executes. This is what
allows ordinary programs (which either do not install a console
handler, or which return FALSE in their console handler for
CTRL_LOGOFF_EVENT) to work with, for example, ServiceInstaller.
However, it does not seem that there is a way for a process to query
whether it is running as a service. If there were, the correct
behavior for the VM upon receiving the CTRL_LOGOFF_EVENT if it were
running as a service would be to skip running the shutdown hooks, not
signal the termination condition to the rest of the VM, and return
FALSE. Otherwise, the two possible workarounds are either to provide
another command line option to java.exe ("running as a service on
Windows NT") or to somehow intercept the CTRL_LOGOFF_EVENTs at the
service wrapper level.

--

Since the time this bug was filed, its original submitter (who is the
author of ServiceInstaller) has released a revised piece of software,
called JavaServ, which solves this problem elegantly by using the JNI
Invocation API to create a Java VM and installing a console control
handler afterwards which intercepts the CTRL_LOGOFF_EVENT and prevents
it from being passed to the VM. It also contains other useful features
like allowing pure Java programs to receive service control events.
JavaServ may be downloaded from

http://www.kcmultimedia.com/javaserv/

The comments on the JDC also contain the source code to a similar
program.

 xxxxx@xxxxx  2000-08-30

-----------------------------------------------------------------

Since the time the above evaluation was written, other problems have
been discovered on Unix platforms involving the interaction between
the signals/events the VM now catches to implement the shutdown hook
mechanism and application code which may rely on catching those
signals; see bug 4345157 and related bugs. It was agreed that it is
necessary to have a cross-platform mechanism to inform the VM that the
user will take care of calling shutdown hooks (by calling
System.exit()), but because he/she either needs to catch SIGINT or
similar signals on Unix or run the VM as a service on NT, the VM must
not install signal handlers or attempt to catch console control
events. It appears that similar reasoning informed the addition of the
-Xrs flag in the Classic VM.

The -Xrs flag has been reused to support this functionality; if it is
specified on Windows NT, for example, java.exe can again be run with
the ServiceInstaller wrapper (http://www.kcmultimedia.com/smaster/).
This fix will appear in 1.3.1 and be documented in the README.

 xxxxx@xxxxx  2000-11-08

This is a HotSpot problem, not a jdk 1.3 problem - the 
problem also occurs with HotSpot-2.0/jdk 1.2.2

This is a bug!!  I can run my Java application as an NT 
Service using JDK 1.2.2, but can NOT run it with JDK 1.3 
RC3.  Nor can I get it to work when running with Java 
HotSpot, regardless of which VM I use.  My only solution is 
to run with JDK 1.2.2 without Hotspot ( too slow.... ).  

I have downloaded several programs that create NT Services 
for Java apps, and see the this same behavior, regardless of 
which one I use. I also see this behavior when I create the 
NT Service using Microsoft's srvany.exe. 

You would think it would be in Sun's best interest to make 
it VERY easy to create an NT Service for a Java Application. 
Don't they want Java Applications to proliferate on NT?? I 
had hoped that Sun would have provided such a tool, but this 
is not the case...

Instead, here's the tools I've tried in addition to srvany:
http://www.kcmultimedia.com/smaster/ 
http://www.formida.com.au/firedaemon

This has been a major headache for us and I really hope this 
is fixed before JDK 1.3 is officially released!!

Not a bug ?????
So how do you have a Java server application on NT ?

It keeps going on with rc3. Using Mike Jennings framework, services
DO WORK with 1.2.2 Hotspot, but they don't work with any 1.3 prerelease.

The evaluation assumes a separate process is created by
the JVM. This bug occurs when the NT service is a SINGLE
process that uses the JVM.

Something in the hotspot JVM kills the process when the user
logs out. Other services (like MS personal web server) keep
running when user logs out.

Either the process using the JVM crashes, or shuts down 
nicely when the user logs off. 

Looks like this is still a problem with the released version
of 1.3 on NT. It causes JRun or JWS (or, presumably, any
Java-based web or application server) to crash on logout, 
meaning 1.3 is unuseable on the server for us.

The reason for this behaviour probably is the setting "Allow Service to interact with the Desktop". This is 
wrong.

A service which has this switch set receives the WM_QUERYENDSESSION on which each Windows 
application is expected to terminate. Furthermore, it can be manipulated by the user who logged in.

JavaVM stops when works as WindowsNT service at the same time that 
a user does log-off. I investigated the cause by referring to SCSL.

JavaVM(JRE1.3) utilizes SetConsoleCtrlHandler() function in Windows 
NT and collects some events. When a user does log-off, CTRL_LOGOFF_EVENT 
event occurs. As a result JavaVM(JVM.DLL) receives a CTRL_LOGOFF_EVENT 
event and has stopped.

I used JNI and evaded this problem by seizing CTRL_LOGOFF_EVENT event 
by force. I pray for this problem being solved formally.

I'm using JDK 1.3 on Windows NT and have experienced the 
same problem. Logging off the user also kills rmiregistry, 
which I run as a service using ServiceMaster.

If SUN is serious about supporting server side Java on the 
Windows NT platform, this problem has to be fixed. The 
performance improvement of 1.3 is great, but we cannot use 
it if we can't log off the user without killing our 
applications.

We choose Java on Win NT as our development platform 
because it allowed us to have the flexibility to choose 
more scalable platforms (ie SUN) in the future, while 
taking advantage of the lower start up costs of the PC 
platform. Making server side Java unusable on Win NT will 
make this a less attractive option.

same problem happen with java2-sdk1.3.0 on win2000
and winNT4.0.
application is JRUN2.2.3 and Jakarta-tomcat-NT-service1.1.

This is a serious bug!!! I cannot advise my company to use the JDK 1.3 if this kind of know bug is allowed to 
remain! It will seriously hamper our web development process to have to code our services around having a 
user logged on at all times!

This problem needs to be resolved.  Our web server was 
shutdown about a dozen times (affecting about 8 developers 
each time) before we discovered that HotSpot was causing 
our web server (IIS) to go down.  IIS was going down since 
our servlet engine was using 1.3 and was tied into IIS.  
We've now gone back to classic JVM 1.2.2 to prevent our web 
server from going down.

This is not a bug in the VM, but the service wrapper. The service wrapper that I wrote (specifically for 
Java2) doesn't have any problem with JDK1.3 when the user logs out. Even for JDK1.2 I had to 
provide my own handler with SetConsoleCtrlHandler in order to keep the service running when logging out.
The key difference may be that I also had to call AllocConsole in order for the handler to get properly
registered.

I would say this is a bug, it doesn't matter in what part 
of java it occures. To take java 1.3 seriously on NT, it 
should work at least as good as 1.2 versions.
I've tried jdk 1.3 on TomCat 3.1 & Jrun 3.0 and both gave 
the same problem.

I've been getting a bunch of questions from people regarding my Java service wrapper. Although I developed 
it for my company and it is proprietary, I can still offer pointers. I developed it last year for JDK1.2, but it 
works just fine with JDK1.3 without any modifications. Unlike some other service wrappers that spawn off 
another process, this one creates a JVM in the same process using the invocation API. I install my console 
event handler immediately after I've created the JVM, in order for it to be called first. Now, I didn't have any 
luck at this (under JDK1.2 even) until I added a call to AllocConsole at the beginning of the service's start 
callback. I think this is the magic step in order to make this work reliably. Calling AllocConsole does not 
produce a visible console window unless the service is set to interact with the desktop. Here's a skeleton 
version of my console event handler:

// Console event handler routine.
BOOL handlerRoutine(DWORD dwCtrlType) {
    switch (dwCtrlType) {

    case CTRL_C_EVENT:
    case CTRL_CLOSE_EVENT:
    case CTRL_SHUTDOWN_EVENT:
        // Call method to stop service
        ...
        return TRUE;

    case CTRL_LOGOFF_EVENT:
        // Ignore logoff events.
        return TRUE;
    }

    // Let parent handler (the VM) take care of anything else.
    return FALSE;
}

Thanks for posting the above. Unfortunately, the workaround cannot be implemented with canned wrappers 
like SRVANY and others that generically install services including, but not limited to, Java. The problem 
persists when JDK 1.3's java.exe is spawned by the service wrapper (rather than using JNI invocation.) I 
believe this needs to be addressed by JavaSoft so that the JDK 1.3 runtime responds to a logoff in the same 
manner as JDK 1.2.2.

JDK1.2.2 didn't actually respond correctly to the logoff event or close event. Instead of stopping the 
process, these would cause a thread dump to be printed to error out just like with ctrl-break. If JDK1.3 
ignored the logoff event completely, then when a user running a client app logs out from windows, the VM 
might not shut down gracefully and the Java exit hooks won't get invoked. I'm not sure if the VM could tell 
whether it was being run as a service or not. If its running as a service, the logoff event can be ignored, 
but it cannot be ignored otherwise.

A solution is to write a genric launcher class in java.
The launcher will just overide 'handlerRoutine' with JNI
and then call your main class with the proper parameters.

To execute 'com.company.server.Main arg1 arg 2' as a sevice
you'll execute 'Launcher com.company.server.Main arg1 arg 
2' instead.

This can be used with virtually any service wrapper.

Anybody know when this will be fixed?

I agree that application run by the clients should be stopped after logout, if not specified purposely (eg 
install as service).

If JavaSoft can kindly develop a NT service wrapper for Java application, I think the problem would be 
solved. At least the JavaSoft developers won't need to have JVM support most (if not all) wrappers.

This  is a bug!! I had the same problem installing a  java 
based service with invoker.exe, and had to revert back to 
jre1.2.2.  This problem seemed to be introduced in jre1.3. 
Everything works fine for me using jre1.2.2.

take a look at
http://www.kcmultimedia.com/javaserv/
for working JNI service wrapper

It's like "Hotel California"... you can check in BUT can't check out. We just found
it the hard way... in PRODUCTION... while doing a $3 Billion Dollar Trade in Java...
thanks to JavaSoft for making me look like a moron in front of my users!!!
Few more bugs like this... the users will force us back to doing Demo programs in JDK 1.1.0!!!
Not even a patch release!!! I got a better idea... why don't you CLOSE this bug - like you
do with all other critical ones!!! Mark it un-reproducible with NT Service Pack 9.8.7.6.5.4.3.2.1.

We picked up an excellent NT Service package at http://jsrvany.sourceforge.net .  It includes C++ source 
for the service installer and runtime wrapper, and nice Java classes which make it easy to implement 
handlers for the NT Service events, including "stop"/"pause"/"continue", which was lacking in most of the 
other packages we evaluated.  

The jsrvany package doesn't solve the the JDK 1.3 bug, but I think it's an excellent base on which to 
experiment with briano's SetConsoleCtrlHandler() / AllocConsole() solution.

I know it is humiliating to chase MS with the NT/2k Server "service" mess, but your customers really need 
robust support to provide competitive Java(tm) applications.  In my opinion if you don't support "service's" 
then you don't support Windows.

Please deliver a complete solution (included with the JDK), and fix this bug too.

In case anyone is interested, I have recently posted a free 
utility that allows you to run your Java app as an NT 
service.  It shields the JVM from the NT logoff event (by 
running the JVM in the service process and handling the 
related events) AND (optionally) allows you to specify a 
method in your Java code to perform graceful shutdowns when 
the service is stopped.  Check out 
http://www.eworksmart.com/jnt

I just patched my Java Service Launcher with the above described AllocConsole, SetCosnsolCtrlHAndler
approch. It's available at www.roeschter.com.
Moreover I want to point out that there is also a solution for all those using off the shelf service launchers.
It's feasable to recompile the java.exe from SUN's sources with a small patch which catches the
LOGOFF event.
This can be achieved by installing the ControlHandler after the JVM has been initialized but before
the main() method is called.

For details please contact me at michael@roeschter.com
or look into for the source of my JSL (specifically java.c) 
at www.roeschter.com

Ok, this bug has enough votes.. They get the point.. Please 
vote for this bug instead: (4314208) 
http://developer.java.sun.com/developer/bugParade/bugs/43142
08.html

That bug is a serious screen distortion for several widgets 
on Java 1.3 on Win32 on some hardware setups. It makes 1.3 
apps with GUI's totally unfeasible since they won't work on 
many very common systems.

Why not just add a "-Xservice" command line option that will make the JVM not respond to the 
CTRL_LOGOFF_EVENT? This should be really easy to implement, and would take care of this bug for good...

Fix ASAP please!

As of July 25 javaserv doesn't handle this, though it claims to.
I modified javaserv source using jsl source code as a model and
ended up with a working solution.  I passed on jsl because it
appeared to rely on the service monitoring a socket.  I may
reevaluate my decision.  Anyway -- key point is that you'll
just get frustrated if you use javaserv out of the box -- modify
it as per jsl!

This is a Bug!! Our process works fine using 1.2.2, but when using 1.3, a log-out kills the process.

We use ServiceMaster to wrap our Java applications as 
services on NT. With JDK1.2.2, the services continued to 
work even after the user logged out. In JDK 1.3, the 
services stop as soon as the user logs out. This is a huge 
problem for us in our production environment, as we want 
our server side java applications to restart automatically 
after a power failure or reboot.

We can not migrate to JDK 1.3 until this bug is fixed or a 
workaround is provided.

This is indeed a pretty nasty bug.
I hope Sun gets with it and fixes it as there
are a LOT of people who need to be able
to have services running when a user merely logs out.

I also say that this is a bug: I use RunExecSvce from WinWinsoft and it works well with JRE 1.2 but not 
at all with JRE 1.3.
I took me a long time to identify the problem !

This is a HotSpot bug!  It happens when you use JDK with 
HotSpot.  JDK 1.3 comes with HotSpot by default.  I tried 
different combinations with JDK 1.2.2, 1.3 with/without 
HotSpot on ServletExec 3.0 and the only combination work is 
JDK 1.2.2 Classic.  Others kill IIS when a user logs out.

This problem also manifests itself when the JVM is started 
by the JNI Invokation API (JNI_CreateJavaVM()) instead of 
the service doing CreateProcess on java.exe. This is with 
JDK 1.3 on Windows 2000.

In this case, a thread is creating the JVM and calling into 
a static Java method that is designed to not return. When 
the user logs out, that thread is destroyed without 
returning from the static Java method.

Here is the complete c code of a NT-Service starter, that 
stays, if it got an LOGOFF-Event.
And additionaly a excample of a java class.
The most important part is to LEAVE the main method of the 
java-class, so that a CtrlHandler can be installed after 
calling the main method of the java-class.
///////////////////////////////////////////////////////////
// Program, that starts the java virtual machine and 
handles console events by itself
// This program can be used for starting an NTService with 
JDK 1.3.0

// includes
#include <jni.h>
#include <windows.h>
#include <string.h>

// typedefs
typedef jint (*P_JNI_GetDefaultJavaVMInitArgs)(void *args);
typedef jint (*P_JNI_CreateJavaVM)(JavaVM **pvm, JNIEnv ** 
penv, void *args);



/***********************************************************
*****************
    Usage of the program.
************************************************************
****************/
void printInfo()
{
	printf("no parameter found.\n");	
	printf("Usage: \n");	
	printf("Parameters are.\n");	
	printf("arg[1]	: jvm library		e.g. 
c:\\jdk\\jre\\bin\\classic\\jvm.dll \n");	
	printf("arg[2]	: classpath		
	e.g. c:\\myclasses\\myproject.jar \n");	
	printf("arg[3]	: lib-path		
	e.g  c:\\mylibs \n");	
	printf("arg[4]	: java-class-file	e.g. MyMain 
\n");	
	printf("arg[5]ff: additional parameters for main-
method in MyMain.class\n");	
}
/***********************************************************
*****************
    static globals.
************************************************************
****************/
static HMODULE			hLib			
	= NULL; 
static JavaVM			*jvm			
	= NULL;    
static JNIEnv			*env			
	= NULL;    
static JavaVMInitArgs	vm_args;
static jclass			clsMain			
	= NULL; 	
static jclass			clsString		
	= NULL; 	
static jmethodID		midMain			
	= 0;	
static JavaVMOption		options[20];

/***********************************************************
*****************
    Invoke JVM and call of the static main method of the 
given javaclass
************************************************************
****************/
int __cdecl invokeJVM(int argc, char* argv[])  
{
	P_JNI_GetDefaultJavaVMInitArgs
	pfnGetDefaultJavaVMInitArgs		= NULL;
	P_JNI_CreateJavaVM			
	pfnCreateJavaVM					= 
NULL;
	jint						
	res						
		= -1;
	jstring						
	jsTemp;
	jarray						
	stringArray;

	char						
	clsOptions[255];
	char						
	libOptions[255];
	char						
	jvmLibrary[255];
	char						
	czTemp[100];
	int						
		i;

	// Load JVM library (jvm.dll)
	strcpy (jvmLibrary, argv[1]); 
	hLib = LoadLibrary(jvmLibrary);
	if(hLib == NULL) 
	{
		printf ("Cannot load library %s", 
jvmLibrary);
		return 0;
	}

	// ClassPath
	strcpy (clsOptions, "-Djava.class.path=");
	strcat (clsOptions, argv[2]);
	// LibPath
	strcpy (libOptions, "-Djava.library.path=");
	strcat (libOptions, argv[3]);

	// JDK 1.3.0 Options
	options[0].optionString = clsOptions;	
	options[1].optionString = libOptions; 

	vm_args.version = JNI_VERSION_1_2;
	vm_args.options = options;
	vm_args.nOptions = 2;
	vm_args.ignoreUnrecognized = TRUE;

	// Create JavaVM
	pfnCreateJavaVM = (P_JNI_CreateJavaVM) 
GetProcAddress(hLib, "JNI_CreateJavaVM");
	if(pfnCreateJavaVM != NULL)
	{
		res = (*pfnCreateJavaVM)
(&jvm,&env,&vm_args);
		if (res < 0) 
		{
			printf("Error! Cannot create Java 
VM");
			return 0;
		}
	}
	else
	{
		printf("Error! Cannot create Java VM, 
function pointer = null");
		return 0;
	}

	// FindClass argv[4]
	clsMain = (*env)->FindClass(env, argv[4]);
	if (clsMain == 0)
	{
		printf("Cannot find Class %s", argv[4]);
		return 0;
	}

	// FindClass String
	clsString = (*env)->FindClass
(env, "java/lang/String");
	if (clsString == 0)
	{
		printf("Cannot find Class String");
		return 0;
	}

	// get methodId of Main.main
	midMain = (*env)->GetStaticMethodID(env, 

How do I get back my virtual machine?

Problem browsing applet in environment Mac Netscape, you 
have have reponse. plis sending your message======>
Message error
9/16/2000 @ 15:54:53
An exception occurred:
java.lang.ClassNotFoundException: com.hostfront.HFEmulator
	at 
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
	at 
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
	at 
com.apple.mrj.JManager.JMAppletClassLoader_ROOT.loadClass
(JMAppletClassLoaderOld.java)
	at 
com.apple.mrj.JManager.JMAppletViewer_OLD.doLoadCode
(JMAppletViewerOld.java)
	at 
com.apple.mrj.JManager.JMAppletViewer_OLD.setState
(JMAppletViewerOld.java)
	at com.apple.mrj.JManager.JMViewerEvent.post
(JMAppletViewerOld.java)
	at com.apple.mrj.JManager.AVDispatcherThread.run
(JMAppletViewerOld.java)
9/11/2000 @ 13:27:23
An exception occurred:
java.lang.ClassNotFoundException: com.hostfront.HFEmulator
	at 
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
	at 
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
	at 
com.apple.mrj.JManager.JMAppletClassLoader_ROOT.loadClass
(JMAppletClassLoaderOld.java)
	at 
com.apple.mrj.JManager.JMAppletViewer_OLD.doLoadCode
(JMAppletViewerOld.java)
	at 
com.apple.mrj.JManager.JMAppletViewer_OLD.setState
(JMAppletViewerOld.java)
	at com.apple.mrj.JManager.JMViewerEvent.post
(JMAppletViewerOld.java)
	at com.apple.mrj.JManager.AVDispatcherThread.run
(JMAppletViewerOld.java)
9/11/2000 @ 13:28:18
An exception occurred:
java.lang.ClassNotFoundException: com.hostfront.HFEmulator
	at 
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
	at 
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
	at 
com.apple.mrj.JManager.JMAppletClassLoader_ROOT.loadClass
(JMAppletClassLoaderOld.java)
	at 
com.apple.mrj.JManager.JMAppletViewer_OLD.doLoadCode
(JMAppletViewerOld.java)
	at 
com.apple.mrj.JManager.JMAppletViewer_OLD.setState
(JMAppletViewerOld.java)
	at com.apple.mrj.JManager.JMViewerEvent.post
(JMAppletViewerOld.java)
	at com.apple.mrj.JManager.AVDispatcherThread.run
(JMAppletViewerOld.java)
9/12/2000 @ 11:30:45
An exception occurred:
java.lang.ClassNotFoundException: com.hostfront.HFEmulator
	at 
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
	at 
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
	at 
com.apple.mrj.JManager.JMAppletClassLoader_ROOT.loadClass
(JMAppletClassLoaderOld.java)
	at 
com.apple.mrj.JManager.JMAppletViewer_OLD.doLoadCode
(JMAppletViewerOld.java)
	at 
com.apple.mrj.JManager.JMAppletViewer_OLD.setState
(JMAppletViewerOld.java)
	at com.apple.mrj.JManager.JMViewerEvent.post
(JMAppletViewerOld.java)
	at com.apple.mrj.JManager.AVDispatcherThread.run
(JMAppletViewerOld.java)


 jrivera@farabi.com

Problem browsing applet in environment Mac Netscape, you 
have have reponse. plis sending your message======>
Message error
8/25/2000 @ 15:54:53
An exception occurred:
java.lang.ClassNotFoundException: com.hostfront.HFEmulator
	at 
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
	at 
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
	at 
com.apple.mrj.JManager.JMAppletClassLoader_ROOT.loadClass
(JMAppletClassLoaderOld.java)
	at 
com.apple.mrj.JManager.JMAppletViewer_OLD.doLoadCode
(JMAppletViewerOld.java)
	at 
com.apple.mrj.JManager.JMAppletViewer_OLD.setState
(JMAppletViewerOld.java)
	at com.apple.mrj.JManager.JMViewerEvent.post
(JMAppletViewerOld.java)
	at com.apple.mrj.JManager.AVDispatcherThread.run
(JMAppletViewerOld.java)
9/11/2000 @ 13:27:23
An exception occurred:
java.lang.ClassNotFoundException: com.hostfront.HFEmulator
	at 
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
	at 
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
	at 
com.apple.mrj.JManager.JMAppletClassLoader_ROOT.loadClass
(JMAppletClassLoaderOld.java)
	at 
com.apple.mrj.JManager.JMAppletViewer_OLD.doLoadCode
(JMAppletViewerOld.java)
	at 
com.apple.mrj.JManager.JMAppletViewer_OLD.setState
(JMAppletViewerOld.java)
	at com.apple.mrj.JManager.JMViewerEvent.post
(JMAppletViewerOld.java)
	at com.apple.mrj.JManager.AVDispatcherThread.run
(JMAppletViewerOld.java)
9/11/2000 @ 13:28:18
An exception occurred:
java.lang.ClassNotFoundException: com.hostfront.HFEmulator
	at 
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
	at 
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
	at 
com.apple.mrj.JManager.JMAppletClassLoader_ROOT.loadClass
(JMAppletClassLoaderOld.java)
	at 
com.apple.mrj.JManager.JMAppletViewer_OLD.doLoadCode
(JMAppletViewerOld.java)
	at 
com.apple.mrj.JManager.JMAppletViewer_OLD.setState
(JMAppletViewerOld.java)
	at com.apple.mrj.JManager.JMViewerEvent.post
(JMAppletViewerOld.java)
	at com.apple.mrj.JManager.AVDispatcherThread.run
(JMAppletViewerOld.java)
9/12/2000 @ 11:30:45
An exception occurred:
java.lang.ClassNotFoundException: com.hostfront.HFEmulator
	at 
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
	at 
com.apple.mrj.JManager.JMAppletClassLoader_IMPL.loadClass
(JMAppletClassLoaderOld.java)
	at 
com.apple.mrj.JManager.JMAppletClassLoader_ROOT.loadClass
(JMAppletClassLoaderOld.java)
	at 
com.apple.mrj.JManager.JMAppletViewer_OLD.doLoadCode
(JMAppletViewerOld.java)
	at 
com.apple.mrj.JManager.JMAppletViewer_OLD.setState
(JMAppletViewerOld.java)
	at com.apple.mrj.JManager.JMViewerEvent.post
(JMAppletViewerOld.java)
	at com.apple.mrj.JManager.AVDispatcherThread.run
(JMAppletViewerOld.java)


 jrivera@farabi.com

The latest release of jsrvany (http://jsrvany.sourceforge.net) implements a workaround based on the 
SetConsoleCtrlHandler() workarounds suggested above.

I certainly hope SUN fixes this one. We need an easy to 
install patch for all of us java-illiterate folks. I'm 
using JRE 1.3 and Jrun 3.0 and the bug is still there.

Hey SUN, how about a fix already?!

How can Sun recommend the solution to THEIR bug is 
installing javaserv, a third party app? This is a bug with 
THEIR software. Fix it where it is broken!

It is nearly a show-stopper.
sorry Sun, no love for M$ here, but Server-Software
has to run as deamon == nt-service.

It is hard enough to convince my colleages to install
something besides IIs für WEB-Apps. Do not make it
inpossible

Maybe a tip to bypass the problem: I don't have this problem using NT Terminal Server.

Does anyone know when this problem is targeted to be fixed?
Or how to find out what the status of this is, other than just "in progress"?
Thanks in advance for any suggestions!

'nuff said.  it's not really such a big issue:  all you 
have to do is reregister your consolecontrolhandler AFTER 
loading the JVM and befor calling main.  simple, huh ?
i've written a fairly complete nt service that does just 
that.  if anyone wants the code - it's free - just drop me 
a line.  

I agree with the previous post from katsnelson regarding 
the seriousness of this bug and the lack of response from 
Sun.  I have not seen any good, simple workarounds for 
running off-the-shelf packages like JRun as a service, 
where you do not have access to the source code. If there 
is a simple solution to this that I missed please let me 
know. It is really disheartening to see Sun let a problem 
as serious as this go on for this long without a fix.  It  
has been a major headache for our company. We are an NT 
shop.  The whole premise of Java is supposed to be multi-
platform compatibility.  Well guess what, if you cannot 
depend on a Java program to stay running as a service under 
NT/2000, Java  cannot be considered a viable 24x7 
production solution in those environments!

Back to the bug: the point is "... it does not seem that there is a way for a process to query whether it is 
running as a service." Are you serious ? Can't you at least get the PIDs of all running services and check 
against your own ? I can't believe no one at Sun or M$ can come up with a way to do this.

If it is, indeed, impossible, please provide a command-line switch as suggested. It may be less elegant but it 
would be much easier for developers to use than a CTRL_LOGOFF_EVENT interceptor.

Welp, I'm back again to check SUN's marvelous 
progress...It's only the #1 bug in the top 25, and still 
nothing. I agree with the above posts - not all of us are 
Java experts, and are able to manipulate the source code. 
So the alternative is - <cough> SUN....FIX THE BUG!

At least let us know when a fix is expected ! That is, if 
you value your customers, if not, keep doing what you've 
been doing since March...

unbelieveable...

Is anyone at Sun aware that this is causing a lot of grief 
for Allaire's JRun Servlet engines when they run as an NT 
Service with the 1.3 jdk. Log off and Poof the service is 
dead. Wake Up! We are almost home. Don't let a simple 
problem like this keep us from running Java on the backend 
of an NT box. Please, I can't go back to Active Server 
Pages -- Gasp!

I went through most of the postings for this awful bug. 
Most solutions appear to be aimed at Services that launch 
the JVM over which you have control. Was there a solution 
ever posted here by a user or SUN for Services [like IIS] 
that launch a JVM??

This is very critical for us, and any reply would be really 
really appreciated!

thanks

Ok, I think we (temporarily?) got past this problem of the 
jvm closing the web server [iis] on a logout. There is a 
check-box on the IIS Manager that allows the jvm to be 
launched as a separate process. Once we checked this box, 
the jvm no longer kill IIS on a logout.

The problem is this:  The JVM registers a Console Control 
Handler which isn't logoof resistant.   If you have access 
to the code of the Java service you can simply reregister 
your own handler.  If not, you are buggered.  Or are you ?  
How about a little wrapper around your 3rd party program 
that registers the desired handler ?  And here it is:  

The CPP bit.  Compile this to a DLL and keep it in your 
path.  

#include <windows.h>
#include <winbase.h>
#include <stdio.h>
 #include <jni.h>

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, 
LPVOID lpvReserved)
{
   return TRUE;
}

BOOL __stdcall HandleConsole(DWORD dwMsg)
{
   switch (dwMsg)
   {
      //case CTRL_C_EVENT :
      //case CTRL_BREAK_EVENT :
      //case CTRL_CLOSE_EVENT :
      //case CTRL_SHUTDOWN_EVENT :
      case CTRL_LOGOFF_EVENT :
         return TRUE;
   }
   return FALSE;
}

JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void 
*reserved)
{
   SetConsoleCtrlHandler(&HandleConsole, TRUE);
   return 0x10002;
}

The Java bit.  Compile it to a class file and use it as the 
main class for your program.  Pass the name of the real 
main class as a parameter, e.g. Java  DVWin32 MyProgram.  
Of course, you would probably use JService or JavaSer 
instead of Java.  

import java.lang.reflect.Method;

public class DVWin32
{
	static
	{
		System.loadLibrary ("DVWin32");
	}
	
	public static void main (String [] args)
	{
		if (args.length < 1)
		{
			System.out.println ("No target 
class specified");
			return;
		}
		try
		{
			Class c = Class.forName (args [0]);
			
			Class [] p  = new Class [] 
			{
			    String [].class
			};			
			Method m = c.getMethod ("main", p);
			
			Object [] o  = new Object [] 
			{
			    args
			};			
			m.invoke (null, o);
		}
		catch (Exception x)
		{
			x.printStackTrace ();
		}
	}	
}

What's nice about this approach is that it works for normal 
Java apps launched by a service too.  

OK, Just got an email saying this bug has been fixed....so 
where's the fix? Anyone know other than Sun? If anyone 
figures out what I have to do to patch this one up, please 
email me....thanks

The release notes for JDK133_01 does not mention the fix of 
this bug.  I'm curious too as where the fix for this bug 
would be.

Isn't it good idea to copy  2000-08-30 comment in evaluation to
the 'workaround'? If the JavaServ solution is better than the current
workaround suggestion. (Thank Mr. Bill Biel!)

Especially till 1.3.1 released, and for people still have to use
1.2.x by other reasons (like me).

Oops. It's Mr. Bill Giel. Sorry, just a typo.

Well, the status of this bug is fixed !!!
I don't find the new release in any place

When Will 1.3.1  be released?

Presumably this means that rmid does not function as a 
Service ?
I cannot find any source code for rmid or ActivationSystem 
or Activator implementations. Therefore activation and nt 
services don't work together. 
Will sun release code to allow me to write my own rmid ?

Dear Sun,

I would greatly like to use java version 1.3, however this 
problem prevents me from doing so.  I agree with the many 
comments indicated below.  This being, can you add a 
command line option like -xnoclose or something like this 
for both the java.exe and the rmiregistry executables 
(perhaps even for javaw and rmid).  I will not be able to 
use java 1.3 in a Windows NT Server environment until this 
problem is resolved.

SUN - get your act together.

You can't say the bug is FIXED unless you have the fix 
available to users! 

Making us all wait for version 1.3.1. is irratating. 
Especially when you say it's fixed, and it's still broken 
on all of our servers! 

If it's fixed - release a patch!

jslabber's fix of Nov 09 2000 seems to work well for us - 
thank you very much.

I have discovered one bug with it however - the argument 
list passed to the main function includes the name of the 
class as the first element, which is not the same as when 
that class is run directly.  My fix is to replace:

  Object [] o  = new Object []
  {
    args
  };	

with:

  String[] newArgs = new String[args.length - 1];
  System.arraycopy(args, 1, newArgs, 0, args.length - 1);

  Object[] o = new Object[]
  {
    newArgs
  };

Hope this helps someone else.

The JDK 1.3.1 BETA is supposed to fix this now:

http://developer.java.sun.com/developer/earlyAccess/j2sdk131/fixed_bugs/runtime.html

I've tried the JDK 1.3.1 BETA, but i've still the problem
that the Service aborts when user logs out.
Any suggestions 

I also experienced the NT service stop even if I installed JDK 1.3.1 beta.
This bug is not fixed in this beta release.
 

JVMI2 - The Java/NT Services Utility NT4/2000 Version 2 - April 14, 2001
Available at http://www.kcmultimedia.com/jvmi/

JVMI2 provides everything needed for running pure Java applications as NT services. 
In addition to its original role as a simple alternative to java.exe for trapping 
logoff events with JDK 1.3.0, it provides a great deal of new functionality. 

1) Command line installation or removal of your Java applications as NT services 
2) Easy configuration of service and display names, working directory, redirection of
   System.out and System.err to a log file, service dependencies and arguments to
   the JVM and your application, using XML formatted text files. 
3) Automatically traps logoff events if using JDK 1.3.0 
4) Provides a simple mechanism for pure Java applications to receive stop events
   from NT by implementing the provided SCMEventManager Java code. 
5) Improved event-logging and error reporting to assist in debugging troublesome
   installations. 

This bug seems still not be fixed in the JDK1.3.1 RC2.

This *is* fixed but it is *not* enabled by default.  The 
release notes tell you how to use it.  Simply add the 
following JVM parm in your call to java.exe:  -Xrs

Release notes are here:
http://developer.java.sun.com/developer/earlyAccess/j2sdk131
/relnotes.html#vm

How do you specify the -Xrs flag to the JVM when the JVM is 
being loaded by an ActiveX bean inside of another server 
application like IIS?  I have tried to add the flag as a 
Java Runtime Option in the Java Plugin Control Panel, but 
this does not work.  I am running 1.3.1 RC2.

I am still experiencing this bug with Current Release of 
jdk1.3.1.  Anyone else get over it?  Driving me crazy!

This is still a problem. We are using the -Xrs flag as stipulated with version 1.3.1 of the JRE and the service still dies when the NT user logs off.

hey guys, remember that the jdk 1.3.1 fix only affects the 
way the jvm handles the windows logoff event.  basically it 
lets your app tell windows "bugger off, i'm not shutting 
down"  and windows responds "aha, a diehard - let's nuke 
it".  it does not prevent your app from getting nuked - 
together with all other diehard apps - at logoff.  to 
prevent it from getting nuked you still have to run it as a 
windows nt service.  to do this you need a java.exe 
replacement such as my jservice.exe or the one by bill 
giel.  these java.exe replacements have the ability to run 
a java app as per normal or as a windows nt service.  btw, 
since my first posting here i have given the source and exe 
for jservice to over 100 people but so far only one person 
has given me any feedback.  thanks richardloxley.  as for 
the rest of you guys - hey, i'm curious - what do you think 
of my program ?  does it suck ?  can it be improved ? (i 
know it can)  are you using it ?  feedback PLEASE !

For us, using srvany.exe (included in the resource kit) is OK
with the JDK 1.3.1 and the -Krs flag.

There was a typo, just to see if you read these lines ;-)

The precedent note should contain:
For us, using srvany.exe (included in the resource kit) is OK
with the JDK 1.3.1 and the -Xrs flag.

this works in 1.3.1-beta but not in 1.3.1-b24

This problem is not resolved with JDK 1.4 Beta.  I tried it 
with Jakarta 3.2 and it still shutsdown when i log off NT.  
Though the Sun documentation for 1.4 Beta states that this 
is a resolved bug.

It worked with -Xrs option even with 1.4 beta.

WindowsNT-Logoff kill my java.exe service
This problem is not resolved with JRE "1.3.1_01".  
I tried it with JRE "1.3.1-b24" with no problems.

I have tried the -Xrs with version jdk1.3.1_01 and the 
problem still exists.  Is this really fixed? 

It works! Thankyou!

Well, neither of the 1.3.0_04 nor 1.3.1_01 jre releases 
helped me to resolve this problem.  I'am also having the 
same problem with running rmiregistry as a service on NT 
systems' account which exits with code 3.

Correction to my previous comment: Passing -Xrs flag to 
java and rmiregistry solves the problem in jre 1.3.0_04 and 
1.3.1_01

It worked for me to use Java 1.3.1_01 and the -Xrs option so
that
the NT service would not exit on logout.  I have a new
problem.
The service I'm working with prompts for a password when
it's
restarted.  It uses Java Swing.  With the -Xrs option, the
password
prompt does not appear.  I have traced the code and see that
it
stops on a call to create a JFrame object, which is used to
create
the password dialog.  I tried replacing the JFrame call with
a call
to Frame with the same result, it blocks.  Any thoughts?

I see now that even a simple Swing application will not run when using the -Xrs option.
Is this expected?
I need to obtain a password to authenticate that the service should be started.

D:\test\swing>java -Xrs main
MAIN
java.lang.IllegalArgumentException: Signal already used by VM: SIGINT
        at sun.misc.Signal.handle(Signal.java:152)
        at java.lang.Terminator.setup(Terminator.java:42)
        at java.lang.Shutdown.add(Shutdown.java:88)
        at java.lang.Runtime.addShutdownHook(Runtime.java:193)
        at sun.awt.windows.WToolkit.run(WToolkit.java:174)
        at java.lang.Thread.run(Thread.java:484)
^CTerminate batch job (Y/N)? y

So what happens when the java app that dies on logout is 
rmid?

It doesn't take -Xrs as an option and so it exits as soon 
as you logout.  I'm sure that this is the same problem, but 
there doesn't look like there is any way of working around 
this one.

We are using Batik SVG Toolkit 
(http://xml.apache.org/batik/) to generate images for 
statistics in a Java servlet-engine on the server-side.

If using JRE 1.3.x and -Xrs the servlet-engine hangs when 
trying to load the Batik-classes. Meanwhile, if deleting 
the code refering to Batik, there is no problem using -Xrs 
(on the other hand we then don't get any cool images). This 
confirms "laseu" previous comment concerning Swing-
applications.

On Windows NT, we will keep on using JRE 1.2.2 until we 
have rewritten our service-launcher (thx for all the info 
on how here) or replaced it with another launcher (need to 
be able to call bat-files).

IMHO it seems that -Xrs wasn't such a great "bug fix". 
Would have prefered a flag meaning "treat signals as in old 
days". Using JRE 1.3.x with "-classic" does not help, still 
dies on log-out. So at the customers we really have to 
install JRE 1.2.2 (i.e. sad to not be able to use HotSpot 
for server application).

How can they close this bug?
It still happening...

I was working with Oracle Apps 11i (11.5.4 with iAS 1.0.2.2s), 
and this issue was resolved by adding -Xrs parameter when 
starting the JVM (jserv)...THANKS!!!

This is a general comment. Please include the commercial 
name on which this issue is fixed. Ladybird does not tell me 
anything and I had to read all comments to figure out which 
release it was

To get rmid to work as a service, try passing -J-Xrs as 
a command line parameter.  Under jdk1.4.2_03, this 
worked.  The -J will pass the remainder of the 
argument as an option to the underlying JVM.  
Therefore, -J-Xrs will pass -Xrs to the JVM which will 
then behave as a service and ignore the signals 
causing it to exit when a logout is performed.  

For other java apps, the -Xrs option seemed to work as 
well.  

Using these parameters, I have been able to log off the 
Windows 2000 Console, while my java apps including 
rmid continue running.  

It still works. Thanks 1.3.1_14-b03

Its struck again! Our service ran fine with our own wrapper using java 1.4 under 2000 advanced server but exits as soon as we log off now that we are using java 1.5.0_02 under 2003 server.

I've just tried this in 1.5 and it definitely doesn't work. Has there been any progress on this recently?