Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
When a java based application starts to misbehave on a windows machine, you want to be able to kill the process in the task manager if you can't quit the application normally. Most of the time, there's more than one java based application running on my machine. Is there a better way than just randomly killing java.exe processes in hope that you'll hit the correct application eventually?
EDIT: Thank you to all the people who pointed me to Sysinternal's Process Explorer - Exactly what I'm looking for!
Run jps -lv which shows PIDs and command lines of all running Java processes.
Determine PID of the task you want to kill. Then use command:
taskkill /PID <pid>
to kill the misbehaving process.
Download Sysinternal's Process Explorer. It's a task manager much more powerfull than Windows's own manager.
One of it's features is that you can see all the resources that each process is using (like registry keys, hard disk directories, named pipes, etc). So, browsing the resources that each java.exe process holds might help you determine wich one you want to kill. I usually find out by looking for the one that's using a certain log file directory.
If you can't run a GUI application like ProcessExplorer and you're looking for the "Command Line" arguments of the processes then you can use "wmic" via the command line. For example:
wmic PROCESS get Processid,Caption,Commandline
If you want to look for a specific process you can do this:
wmic PROCESS where "name like '%java%'" get Processid,Caption,Commandline
The output from this will show you all of the command line arguments of processes like "java."
Using jps in the JDK will give you more information. More information is display with the -m, -l and -v options.
Have you tried using Process Explorer from SysInternals? It gives a much better idea of what is running within the process. Available free online here: http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
If you're using Java 6, try jvisualvm from the JDK bin directory.
You could try opening Windows Task Manager, going to the Applications tab, right clicking the application and then selecting "Go To Process". This will automatically highlight the appropriate process in the Processes tab.
In case you're developing software: use a java-launcher. I used for a few of my application [Exe4j][http://www.ej-technologies.com/products/exe4j/overview.html] and it worked very well. When the application is started, it's listed as for example "myserverapp.exe" or "myapp" in the windows tasks manager.
There are other lauchers too (don't known them by heart), few of them might be for free too.
I'd suggest downloading Process Explorer from Sysinternals and looking at the different java.exe processes more closesly, that way you can get a better idea of which one to kill.
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
It's very intuitive and you can find the java.exe processes and right click and goto their properties, from there you can see their command line, time of creation, etc which can help you find the process you want to kill.
Hope it helps.
Using ProcessExplorer and hovering over the Java process will show the command line.
If the application is not responding at all, then Process Explorer is a good option.
If it's sort of responding, but not dying, sometimes bringing up task manager, and then moving another dialog over the java process will give you a clue. The java process that's taking up cpu cycles to redraw is the one you're looking for.
Rather than using a third party tool, you can also make a pretty good guess by looking at all the columns in task manager if you know roughly what the various java processes on your system are. From the Processes tab, use View-> Select Columns and add PID, CPU Time, VM Size, and Thread count. Knowing roughly what the process is doing should help narrow it down.
For example, in a client-server app, the server will likely use more memory, have more threads, and have used more CPU time because it has been running longer. If you're killing a process because it's stuck, it might simply be using more CPU right now.
MAX java heap memory is usually directly reflected in VM Size. So if you're using -Xmx flags, the process with the larger setting will have a larger VM Size.
I try to run my JAVA application with JVM arguments in Eclipse.
I noticed that a "-noverify" String is appended each time at the end of the parameters, which makes them unusable because I need that as a patch to my config files. (And the program say: "/home/user/config.properties-noverify" isn't exists.)
The arguments are:
-Djava.security.egd=file:/dev/./urandom -Dspring.config.location="/home/sige/guezbin/application.properties" -DconfigPath="/home/sige/eclipse-workspace/ImgCompr/config-default.properties"
I develop under Ubuntu. With Eclipse version 4.8.
I Googled a lot but I didn't find any answers.
Can somebody explain to me what is this and how can I use it in a proper way?
The JVM checks the byte code of the compile classes it is about to load to see that it is well behaved. This is an essential step for executing untrusted code.
Unfortunately this takes time and for a very large application like Eclipse this may increase the startup time quite a bit. The "-noverify" flag turns this off.
It sounds like that you need a space after your own string so the "-noverify" flag is not concatenated. If you cannot do this, then make a work around like "-Dignore" which becomes -Dignore-noverify and then your code should work.
I have an obfuscated Java 8 program and I want to attach a Java agent to it. But when I start it with java -javaagent:intrace-agent.jar -jar program.jar it launches and disattaches from the console after a few seconds, my agent finishes. If I try to see program's command line args in Process Explorer, there's a -XX:+DisableAttachMechanism option (this program adds it during startup somehow). Are there any ways to bypass that?
Thanks in advance!
There's two approaches you can take to get around that:
Modify the program's bytecode to make it not relaunch itself like that.
Get the OpenJDK source, remove the check that makes that option do anything, and then run the program in that environment.
Note that with either of those approaches, the program might end up noticing that you did it and doing something else to foil you.
I've got a (fairly typical) setup at the moment of launching my Java application through a batch file calling the jar file with appropriate parameters, which most of the time works absolutely fine. However, I'd like to be able to deal with any errors that might occur nicely.
At the moment I've got something like
java -Xms1024m -Xmx1024m -jar Quelea.jar
IF NOT (%ERRORLEVEL% == 0) cscript MessageBox.vbs "Application failed to start."
The last line is basically the first answer on this question.
I'd like something a bit more fully featured though, even if it's a case of capturing the output from launching the process and then dumping it in the message box (ok, it's not pretty but it shouldn't appear to start with and when it does appear that then gives me some immediate debugging information without having to ask the user to grab out log files!) Or are there any other approaches that people use in similar situations?
I'm not talking about exceptions thrown in my code (which I deal with once the application starts) I'm talking about hard errors that prevent it starting such as using an old JRE version, not having enough memory to reserve for heap, that sort of thing.
I suggest using a Java executable wrapper. I like the following, but there are others.
http://launch4j.sourceforge.net/
anyone have any experience using this?
if so, is it worth while?
I just used jdb for the first time yesterday and am really pleased with the results. You see, I program in Eclipse on my laptop, then deploy to a VM to make sure the whole shebang still works. Very occasionaly, I'll have to work on something that gets executed standalone, as a commandline. These things sometimes need debugging.
This has always been a problem, because I don't want to go to the trouble of installing Eclipse on the VM (it's slow enough already!), yet I don't know of an easy way to get it to connect to my commandline-running class before it finishes running.
jdb to the rescue! It works a treat - small and functional, almost to the point where it is bare... this forces you to apply your mind more than you apply the tool (like I said here).
Make sure to print out the reference (solaris, windows, java 1.5 - I think they're all about the same, really) and have your source code open and browsable on your second screen. I hope you have a second screen, or you'll be alt-tabbing a lot.
Assume your program is started by the following command:
java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=<port> <class>
You can attach to this process by jdb:
jdb -attach <port>
In some cases you need to use the following command .
jdb -sourcepath \.src -connect com.sun.jdi.SocketAttach:hostname=localhost,port= <port>
JDB is incredibly difficult to use. Placing System.outs or using an IDE debugger will produce better results. And for the more interesting features (e.g. tracking threads, heap size, etc.), you can get the information graphically with the JConsole tool.