To do this, start your java program with the following jvm paramters:

-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=23334

The meaning of the parameters is as follows:

• server=y – this application will act as a TCP/IP server (“acceptor”) and wait for incoming connections rather than trying to connect to you
• suspend=n – the server will not suspend on startup (alternatively you can set it to “y” in which case it will pause and wait for the debugger to connect – useful if you need to debug issues occurring at startup)
• address=23334 – the port on which the debugger will listen. Keep in mind that only one program can listen on a given port on a machine and if the given port is not available, the given program will not start

After the program has started open your Eclipse, go to Debug configrations, Remote Java application, create a new entry and set “Host” to the machine name or IP and “Port” to 23334 (or whatever other port you’ve set up). Connect to it and off you go. The configuration steps for IntelliJ can be found here (I didn’t check it, but they seem right). A couple of final thoughts:

• If your sources are not in sync with the remote jars, you will see weird stuff (like breakpoints not triggering, triggering and the “wrong” line, etc), so you should make sure that you have the same sources as the jar does. If you still get into the situation where the sources are different from the classfiles, I found that setting breakpoints on “method entry” works as expected (ie. it breaks even if the method in the classfile is on a different line)
• You can “detach” from a certain process and it keeps running (and later on you can re-attach to it)
• This method is of low bandwidth / overhead, so it can be used to debug servers in remote locations
• Never, ever do this in production! unless you are absolutely, 100% certain that you know what you are doing.

• Create a textfile with the following content:

  set height 0
  thread apply all bt
  detach
  quit

• Run the following command:

  gdb $EXE -pid $PID -command $TEXTFILE > $OUTPUTFILE

  where:

  • $EXE is the path to the executable
  • $PID is the PID it is running under
  • $TEXTFILE is the file where your’ve saved the previous commands
  • $OUTPUTFILE is the file where you would like your stackdump to be saved.

The cool little crawling logo was taken from HiR, head over there for an explanation.

To get the bad stuff straight out of the way:

• The authors define a very wide scope for the book in the introduction (something along the lines of “everyone should read it” – of course I’m paraphrasing). There is stark contrast however between this statement and the level of knowledge required to be able to understand the book, knowledge mostly isn’t covered in the book
• A large part of the book is monospaced textual content. They don’t use a typeface however in which you can easily differentiate between the letter l and the digit 1 (like Monaco), which makes many of the examples ambiguous
• The chapters have a certain feel of disorganization to them in my opinion, and frequently they seem to be more of a “tips & tricks” collection than complete whole. I assume that a large reason for this is the fact that the WinDBG commands evolved over time, so there isn’t a simple logic which can “decode” all of them (similar to the MS-DOS/MS Windows batch language). Still, a summary of the commands (in cheat-sheet fashion) would have been nice.

One positive aspect of the book is its low error rate. In fact I’ve seen only one error in the whole book (there might have been more, but not many more): a drawing shows the end of the SEH chain as being 0x00000000, while in fact it is 0xFFFFFFFF (the correct value is used however in the text). An other positive aspect is the thoroughness: after reading trough all off ~750 pages, you will get a very good idea about the capabilities of WinDBG and other related tools.

So would I recommend reading this book? If you want to use WinDBG (or other debuggers from the Windows Debugging Tools) yes, but only after reading at least the Windows Internals and an assembly book (I’ve heard that Art of Assembly would be good, although I’ve didn’t read it myself). It should have a warning sticker: for hard-core enthusiast only.

Full disclosure: the links in the post contain my Amazon Affiliate ID.