この章では、バグレポートの提出方法に関する指針を提供します。これには、レポートを提出する前に試すこと、およびレポート用に収集するデータに関する提案が含まれています。
最新プラットフォームは Java SE 7 です。このリリースへの定期的にスケジュールされた更新には、そのプラットフォームの初期リリース以降に確認された一連のクリティカルなバグの修正が含まれています。更新リリースが利用可能になると、Java SE ダウンロードサイトにあるデフォルトのダウンロードになります。
このダウンロードサイトには、そのリリースにおけるバグ修正のリストを示すリリースノートが含まれています。リストにある各バグは、バグデータベース内のバグの説明にリンクされています。リリースノートには、以前の更新リリースにおける修正のリストも含まれています。問題が発生した場合やバグの疑いがある場合には、診断の初期段階として、最新の更新リリースで使用可能な修正のリストをチェックしてください。
ある問題が、すでに修正されたバグと同じものであるか明確でない場合があります。そのため、可能であれば、最新の更新リリースでテストして、その問題が引き続き発生するかどうかを確認してください。
バグレポートを提出する前に、次の推奨事項を検討してください。
できるだけ多くの関連データを収集します。たとえば、デッドロックが発生した場合はスレッドダンプを生成し、クラッシュが発生した場合はコアファイル (該当する場合) と hs_err ファイルを見つけます。いずれの場合も、環境と、問題が発生する直前に実行されていたアクションを文書化することが重要です。
適用可能な場合は、元の状態を復元し、文書化した手順を使って問題を再現してみます。これにより、その問題が再現可能なものであるか、間欠的なものであるかを判断できます。
問題が再現可能な場合は、問題を絞り込んでみてください。場合によっては、小規模なスタンドアロンのテストケースを使ってバグを再現できます。小規模なテストケースで再現されるバグは通常、大規模で複雑なアプリケーションで構成されているテストケースに比べて診断が容易です。
バグデータベースを検索して、このバグまたは同様のバグが報告されているかどうかを確認します。バグがすでに報告されている場合は、次のような詳細情報がバグレポートに記載されている可能性があります。
バグがすでに修正されている場合、それが修正されたリリース。
その問題の回避方法。
バグが発生する環境についてさらに詳しく説明する、評価内のコメント。
バグデータベースは http://bugs.sun.com/bugdatabase/index.jsp にあります。
バグがまだ報告されていないと判断した場合は、新しいバグを提出します。
バグを提出する前に、問題が発生した環境が、サポートされている構成であることを確認します。サポート対象のシステム構成のサイトを参照してください。
システム構成のほかに、サポート対象のロケールのリストも確認します。サポート対象のロケールの Web ページを参照してください。
Solaris オペレーティングシステムの場合は、そのオペレーティングシステム用の推奨パッチクラスタを調べて、推奨パッチがインストールされていることを確認します。
通常、バグレポートを作成したり、サポートコールを提出したりする場合は、できるだけ多くの関連データを収集することをお勧めします。このセクションでは、収集すべきデータを提案し、該当する場合は、データを取得するためのコマンドや一般的な手順に関する推奨事項を提供します。
バグレポートを提出する前に、次のデータを収集できます。
ハードウェアの詳細
オペレーティングシステムの詳細
Java SE のバージョン情報
コマンド行オプション
環境変数
致命的エラーログ (クラッシュの場合)
コアダンプまたはクラッシュダンプ (クラッシュや場合によってはハングアップの場合)
テストケース (可能な場合) を含む、問題の詳細な説明
ログまたはトレース情報 (該当する場合)
トラブルシューティング手順からの結果
以降のセクションでは、各データについて種類別にさらに詳しく説明します。
特定のハードウェア構成でのみバグが発生したり再現できたりすることがあります。致命的なエラーが発生した場合は、エラーログにハードウェアの詳細が含まれている可能性があります。エラーログを入手できない場合は、マシンのプロセッサの番号と種類、クロック速度、および該当する場合かつ既知の場合は、そのプロセッサの機能に関するいくつかの詳細をバグレポートにまとめます。たとえば Intel プロセッサの場合、ハイパースレッディングが使用可能であることがそれに該当します。
Solaris オペレーティングシステムでは、showrev -a コマンドはオペレーティングシステムのバージョンおよびパッチ情報を出力します。
Linux では、使用されているディストリビューションとバージョンを知ることが重要です。/etc/*release ファイルがリリース情報を示している場合がありますが、コンポーネントとパッケージは個別にアップグレードできるため、必ずしもそれが信頼できる構成を示しているとは限りません。そのため、*release ファイルからの情報に加えて、次の情報も収集してください。
カーネルのバージョン。これは uname -a コマンドを使って取得できます。
glibc のバージョン。rpm -q glibc コマンドは、glibc のパッチレベルを示します。
スレッドライブラリ。Linux には、LinuxThreads および NPTL という 2 つのスレッドライブラリがあります。LinuxThreads ライブラリは 2.4 より古いカーネルで使用され、「固定スタック」と「浮動スタック」のバリアントがあります。Native POSIX Thread Library (NPTL) は 2.6 カーネルで使用されます。一部の Linux リリース (RHEL3 など) には、NPTL の 2.4 カーネルへのバックポートが含まれています。使用されているスレッドライブラリを確認するには、コマンド getconf GNU_LIBPTHREAD_VERSION を使用します。getconf コマンドが、その変数が存在しないことを示すエラーを返す場合は、古いカーネルを LinuxThreads ライブラリとともに使用している可能性があります。
Java SE のバージョン文字列は、java -version コマンドを使用すると取得できます。
同じマシン上に Java SE のバージョンが複数インストールされている可能性があります。したがって、適切なバージョンの java コマンドが間違いなく使用されるように、そのインストールの bin ディレクトリが PATH 環境変数内でほかのインストールよりも前にあることを確認してください。
バグレポートに致命的エラーログが含まれていない場合は、コマンド行全体とそのすべてのオプションを文書化することが重要です。これには、ヒープ設定を指定するオプション (-mx オプションなど) や HotSpot 固有のオプションを指定する -XX オプションが含まれます。
Java SE の機能の 1 つに、ガベージコレクタエルゴノミクスがあります。サーバークラスマシンでは、java コマンドは HotSpot Server VM とパラレルガベージコレクタを起動します。マシンがサーバーマシンと見なされるのは、少なくとも 2 基のプロセッサと 2G バイト以上のメモリーを備えている場合です。
-XX:+PrintCommandLineFlags オプションを使用すると、コマンド行オプションを検証できます。このオプションは、コマンド行の VM に対するすべてのフラグを出力します。jmap ユーティリティーを使用すると、実行中の VM またはコアファイルのコマンド行オプションを取得することもできます。
環境変数の設定が原因で問題が発生する場合があります。バグレポートの作成時に、次の Java 環境変数の値 (設定されている場合) を記入してください。
JAVA_HOME
JRE_HOME
JAVA_TOOL_OPTIONS
_JAVA_OPTIONS
CLASSPATH
JAVA_COMPILER
PATH
USERNAME
また、次のオペレーティングシステム固有の環境変数も収集してください。
Solaris OS および Linux では、次の環境変数の値を収集します。
LD_LIBRARY_PATH
LD_PRELOAD
SHELL
DISPLAY
HOSTTYPE
OSTYPE
ARCH
MACHTYPE
Linux オペレーティングシステムでは、次の環境変数の値を収集します。
LD_ASSUME_KERNEL
_JAVA_SR_SIGNUM
Windows オペレーティングシステムでは、次の環境変数の値を収集します。
OS
PROCESSOR_IDENTIFIER
_ALT_JAVA_HOME_DIR
致命的エラーが発生すると、エラーログが作成されます。このファイルの詳細は、付録 B「致命的エラーログ」を参照してください。
このエラーログには、致命的エラーの発生時に得られた多くの情報 (バージョンや環境の情報、クラッシュを引き起こしたスレッドの詳細など) が含まれています。
致命的エラーログが生成される場合は、必ずそれをバグレポートやサポートコールに含めてください。
コアダンプやクラッシュダンプは、システムクラッシュまたはハングアッププロセスの診断を試みる際に非常に役立つ可能性があります。ダンプの生成手順は、「8.4 コアダンプの収集」で説明されています。
問題の説明を作成するときは、できるだけ多くの関連情報を含めるようにしてください。アプリケーション、環境、そして何よりも問題が発生した時間につながるイベントを記述します。
問題が再現可能な場合は、その問題を再現するために必要な手順の一覧を示します。
問題を小さなテストケースで再現できる場合は、そのテストケースと、そのテストケースをコンパイルして実行するためのコマンドを含めます。
テストケースまたは問題にサードパーティーのコード (商用またはオープンソースのライブラリやパッケージなど) が必要な場合は、そのライブラリの場所と入手方法についての詳細を提供します。
複雑なアプリケーション環境でしか問題を再現できない場合があります。その場合は、ログ、コアファイル、およびその他の関連情報を伴う説明が問題を診断する唯一の手段になる可能性があります。このような状況では、提出者が問題の発生しているシステムでさらなる診断を行なったり、テストバイナリを実行したりする意志があるかどうかをその説明で示すようにしてください。
場合によっては、ログまたはトレース出力が問題の原因を迅速に特定するのに役立つ可能性があります。
たとえば、パフォーマンスの問題の場合、-verbose:gc オプションの出力が問題の診断に役立つ可能性があります。(これは、ガベージコレクタからの出力を有効にするオプションです。)
別のケースでは、jstat コマンドからの出力を使用すると、問題の発生に至るまでの期間にわたる統計情報を取得できます。
VM のデッドロックまたはハングアップ (ループが原因など) の場合は、スレッドスタックが問題の診断に役立つ可能性があります。スレッドスタックを取得するには、Ctrl + \ (Solaris OS と Linux の場合) および Ctrl + Break (Windows オペレーティングシステムの場合) を使用します。
通常は、関連のあるすべてのログ、トレース、およびその他の出力をバグレポートまたはサポートコールに含めます。
バグレポートを提出する前に、必ず、実行したトラブルシューティング手順をすべて文書化してください。
たとえば、問題がクラッシュであり、アプリケーションにネイティブライブラリが含まれている場合は、バグがネイティブコード内にある可能性を減らすために、すでに -Xcheck:jni オプションを使ってアプリケーションを実行している場合があります。別のケースとして、HotSpot Server VM (-server オプション) で発生するクラッシュが考えられます。HotSpot Client VM (-client オプション) でもテストを行い、問題が発生しない場合は、バグが HotSpot Server VM に固有のものである可能性があることの目安になります。
一般に、すでに行われたトラブルシューティング手順と結果をすべてバグレポートに含めます。この種の情報によって、問題の診断に要する時間が短縮されることが頻繁にあります。
このセクションでは、コアダンプ (クラッシュダンプとも呼ばれる) の生成と収集の方法について説明します。コアダンプまたはクラッシュダンプとは、実行中のプロセスのメモリースナップショットのことです。コアダンプは、致命的エラーまたは処理できないエラー (シグナルまたはシステム例外など) の発生時にオペレーティングシステムによって自動的に作成されることがあります。あるいは、システム提供のコマンド行ユーティリティーを使って強制的にコアダンプを作成することもできます。ハングアップしているように見えるプロセスを診断する際にコアダンプが役立つ場合があります。つまり、そのコアダンプによってハングアップの原因に関する情報が明らかになる可能性があります。
コアダンプを収集する場合は、コアファイルを解析できるように、必ず環境に関するその他の情報 (OS バージョン、パッチ情報、致命的エラーログなど) も収集してください。
コアダンプには通常、クラッシュまたはハングアップしたプロセスのメモリーページがすべて含まれているとはかぎりません。ここで取り上げている各オペレーティングシステムでは、プロセスのテキスト (またはコード) ページはコアダンプに含まれません。ただし、便宜上、コアダンプは少なくともヒープとスタックのページで構成されている必要があります。クラッシュのポストモーテム解析には、切り詰められていない完全なコアダンプファイルの収集が不可欠です。
Solaris オペレーティングシステムでは、セグメンテーション違反や不正な命令などの処理できないシグナルによってコアダンプが作成されます。デフォルトでは、コアダンプはプロセスの現在の作業ディレクトリに作成され、コアダンプファイルの名前は core になります。ユーザーは、コアファイル管理ユーティリティー coreadm を使用すると、そのコアダンプの場所と名前を構成できます。この手順については、coreadm ユーティリティーのマニュアルページに詳しく説明されています。
ulimit ユーティリティーは、現在のシェルとその子孫が利用できるシステムリソースへの制限を取得または設定するために使用されます。コアファイルのサイズ制限をチェックまたは設定するには、ulimit -c コマンドを使用します。必ずこの制限を unlimited に設定してください。それ以外の場合、コアファイルが切り詰められる可能性があります。ulimit は Bash シェルの組み込みコマンドです。C シェルでは limit コマンドを使用します。
VM またはアプリケーションの起動に使用されるスクリプトがコアダンプの作成を無効にしないようにしてください。
gcore ユーティリティーを使用すると、実行中のプロセスのコアイメージを取得できます。このユーティリティーは、コアダンプを強制的に作成させるプロセスのプロセス ID (pid) を受け入れます。
マシン上で実行されている Java プロセスのリストを取得するには、次のいずれかのコマンドを使用できます。
ps -ef | grep java
pgrep java
jps コマンド。jps コマンド行ユーティリティーでは、名前の照合 (つまり、プロセスのコマンド名の中に「java」がないか検索する) を行わないため、Java プロセスだけでなく、Java VM の埋め込みプロセスも一覧表示できます。
Java プロセスは、-XX:+ShowMessageBoxOnError コマンド行オプションを使って起動できます。致命的エラーが発生すると、そのプロセスは標準エラーにメッセージを出力し、標準入力からの「yes」または「no」の応答を待ちます。予想外のシグナルが発生した場合の出力の例を次に示します。
======================================================================= Unexpected Error ----------------------------------------------------------------------- SIGSEGV (0xb) at pc=0xfeba31ac, pid=8677, tid=2 Do you want to debug the problem? To debug, run 'dbx - 8677'; then switch to thread 2 Enter 'yes' to launch dbx automatically (PATH must include dbx) Otherwise, press RETURN to abort... =======================================================================
「yes」と応答するか、Return キーを押す前に、gcore ユーティリティーを使用してコアダンプを強制します。その後、「yes」と入力して dbx デバッガを起動できます。
-XX:+ShowMessageBoxOnError オプションを指定できない場合は、truss ユーティリティーを使用できる可能性があります。この Solaris OS のユーティリティーは、システムコールおよびシグナルをトレースするために使用されます。このユーティリティーを使用すると、特定の関数またはシステムコールに達した時点でプロセスを中断できます。
次のコマンドは、truss ユーティリティーを使用して、exit システムコールが実行される (つまり、プロセスが終了しようとしている) ときにプロセスを中断する方法を示しています。
$ truss -t \!all -s \!all -T exit -p pid
プロセスが exit を呼び出すと、そのプロセスが中断されます。この時点で、デバッガをプロセスに接続することも、gcore を呼び出してコアダンプを強制することもできます。
Linux オペレーティングシステムでは、セグメンテーション違反や不正な命令などの処理できないシグナルによってコアダンプが作成されます。デフォルトでは、コアダンプはプロセスの現在の作業ディレクトリに作成され、コアダンプファイルの名前は core.pid になります。ここで、pid はクラッシュした Java プロセスのプロセス ID です。
ulimit ユーティリティーは、現在のシェルとその子孫が利用できるシステムリソースへの制限を取得または設定するために使用されます。コアファイルのサイズ制限をチェックまたは設定するには、ulimit -c コマンドを使用します。必ずこの制限を unlimited に設定してください。それ以外の場合、コアファイルが切り詰められる可能性があります。ulimit は Bash シェルの組み込みコマンドです。C シェルでは limit コマンドを使用します。
VM またはアプリケーションの起動に使用されるスクリプトがコアダンプの作成を無効にしないようにしてください。
gcore コマンドを gdb (GNU デバッガ) インタフェースで使用すると、実行中のプロセスのコアイメージを取得できます。このユーティリティーは、コアダンプを強制的に作成させるプロセスの pid を受け入れます。
マシン上で実行されている Java プロセスのリストを取得するには、次のいずれかのコマンドを使用できます。
ps -ef | grep java
pgrep java
jps コマンド。jps コマンド行ユーティリティーでは、名前の照合 (つまり、プロセスのコマンド名の中に「java」がないか検索する) を行わないため、Java プロセスだけでなく、Java VM の埋め込みプロセスも一覧表示できます。
Java プロセスは、-XX:+ShowMessageBoxOnError コマンド行オプションを使って起動できます。致命的エラーが発生すると、そのプロセスは標準エラーにメッセージを出力し、標準入力からの「yes」または「no」の応答を待ちます。予想外のシグナルが発生した場合の出力の例を次に示します。
======================================================================= Unexpected Error ----------------------------------------------------------------------- SIGSEGV (0xb) at pc=0x06232e5f, pid=11185, tid=8194 Do you want to debug the problem? To debug, run 'gdb /proc/11185/exe 11185'; then switch to thread 8194 Enter 'yes' to launch gdb automatically (PATH must include gdb) Otherwise, press RETURN to abort... =======================================================================
上記のエラーレポートで提案されているように、「yes」と入力して gdb (GNU デバッガ) インタフェースを起動します。gdb プロンプトで、gcore コマンドを指定できます。このコマンドは、デバッグ対象のプロセスのコアダンプを core.pid という名前で作成します。ここで、pid はクラッシュしたプロセスのプロセス ID です。必ず gdb gcore コマンドが、使用しているバージョンの gdb でサポートされていることを確認してください。gdb コマンドプロンプトで help gcore を検索します。
次のリストでは、コアファイルが生成されない可能性がある主な理由について説明します。特に断りがないかぎり、このリストは Solaris OS と Linux の両方に関連します。
現在のユーザーに、そのプロセスの現在の作業ディレクトリへの書き込み権がありません。
現在のユーザーには現在の作業ディレクトリへの書き込み権がありますが、読み取り専用の権限を持つ core という名前のファイルがすでに存在しています。
現在のディレクトリに十分な空き領域がないか、空き領域がまったく残っていません。
現在のディレクトリに、core という名前のサブディレクトリがあります。
現在の作業ディレクトリがリモートです。NFS (Network File System) によってマップされている可能性があり、ちょうどコアダンプが作成されようとしているときに NFS が失敗しました。
Solaris OS のみ:coreadm ツールを使用してコアファイルのディレクトリと名前が構成されましたが、構成されたディレクトリまたはファイル名に上記のいずれかの理由が当てはまります。
コアファイルのサイズ制限が低すぎます。ulimit -c コマンド (Bash シェル) または limit -c コマンド (C シェル) を使用して、コアファイルの制限をチェックしてください。このコマンドからの出力が unlimited でない場合、コアダンプのファイルサイズが十分な大きさでない可能性があります。その場合は、切り詰められたコアダンプを受け取るか、コアダンプをまったく受け取りません。また、VM またはアプリケーションの起動に使用されるスクリプトがコアダンプの作成を無効にしないようにしてください。
プロセスが setuid プログラムを実行しているため、オペレーティングシステムは、明示的に構成されないかぎり、コアをダンプしません。
Java 固有:プロセスが SIGSEGV または SIGILL を受信してもコアがダンプされなかった場合、プロセスがそれを処理した可能性があります。たとえば、HotSpot VM は SIGSEGV シグナルを、正当な目的 (NullPointerException のスローや最適化解除など) のために使用します。Java VM によってシグナルが処理されないのは、現在の命令 (PC) が Java VM 生成コードから外れる場合だけです。これらが、HotSpot でコアがダンプされる唯一の場合になります。
Java 固有:VM の作成に、JNI 呼び出し API が使用されました。標準の Java ランチャーは使用されませんでした。カスタム Java ランチャープログラムが、シグナルをただ消費するだけでその処理をすませ、ログエントリを暗黙のうちに生成しました。この状況は、特定のアプリケーションサーバーや Web サーバーで発生しました。これらの Java VM 埋め込みプログラムは、異常終了後にシステムの再起動 (フェイルオーバー) を透過的に試行します。この場合、コアダンプが生成されないという事実は、機能であってバグではありません。
Windows オペレーティングシステムでは、3 種類のクラッシュダンプがあります。
ワトソン博士のログファイル。これは、障害時のスタックトレースとその他のいくつかの詳細を含むテキストエラーログファイルです。
ユーザーミニダンプ。これは「部分的」なコアダンプと考えることができます。これは、プロセスの有用なメモリーページがすべて含まれているわけではないので、完全なコアダンプではありません。
ワトソン博士のフルダンプ。これは Unix コアダンプと同等です。このダンプには、プロセスのほとんどのメモリーページ (コードページを除く) が含まれています。
Windows で予想外の例外が発生した場合、実行されるアクションは次のレジストリキーの 2 つの値によって異なります。
\\HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug
それらの 2 つの値には、Debugger および Auto という名前が付いています。Auto 値は、アプリケーションエラーが発生したときに、Debugger エントリの値で指定されたデバッガが自動的に起動するかどうかを示します。
Auto 値が 0 の場合は、アプリケーションエラーが発生したときにシステムがメッセージボックスを表示してユーザーに知らせることを示します。
Auto 値が 1 の場合は、デバッガが自動的に起動することを示します。
Debugger の値は、プログラムエラーのデバッグに使用されるデバッガコマンドです。
Windows では、プログラムエラーが発生すると、Auto 値を調べて、その値が 0 の場合に、Debugger 値に含まれるコマンドを実行します。Debugger の値が有効なコマンドである場合は、「OK」と「キャンセル」の 2 つのボタンを含むメッセージボックスが作成されます。ユーザーが「OK」をクリックすると、プログラムが終了します。ユーザーが「キャンセル」をクリックすると、指定されたデバッガが開始されます。Auto エントリの値が 1 に設定され、Debugger エントリの値が有効なデバッガを表すコマンドを指定している場合、システムはそのデバッガを自動的に起動し、メッセージボックスを生成しません。
ワトソン博士のデバッガは、クラッシュダンプファイルの作成に使用されます。デフォルトでは、ワトソン博士のデバッガ (drwtsn32.exe) は Windows システムフォルダ (%SystemRoot%\System32) にインストールされます。
ワトソン博士をポストモーテムデバッガとしてインストールするには、次のコマンドを実行します。
drwtsn32 -i
クラッシュダンプファイルの名前と場所を構成するには、オプションを付けずに drwtsn32 を実行します。
drwtsn32
ワトソン博士の GUI ウィンドウで、「クラッシュダンプファイルの作成」チェックボックスにチェックマークが付いていること、およびクラッシュダンプファイルパスとログファイルパスがそれぞれのテキストフィールドに構成されていることを確認します。
レジストリを使用すると、フルダンプを作成するようにワトソン博士を構成できます。レジストリキーは次のとおりです。
System Key: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DrWatson] Entry Name: CreateCrashDump Value: (0 = disabled, 1 = enabled)
アプリケーションが例外を処理する場合は、レジストリで構成されたデバッガは呼び出されないので注意してください。その場合は、-XX:+ShowMessageBoxOnError コマンド行オプションを使用することで、致命的エラーの状態ではユーザーが介入するまで待つようにプロセスを強制するのが適切である可能性があります。
Windows オペレーティングシステムでは、userdump コマンド行ユーティリティーを使って実行中のプロセスの Dr. Watson ダンプを強制できます。userdump ユーティリティーは Windows には付属せず、代わりに OEM Support Tools パッケージのコンポーネントとしてリリースされています。
クラッシュダンプを強制する別の方法は、windbg デバッガを使用することです。windbg を使用することの主な利点は、非侵入的な方法 (つまり読み取り専用) でプロセスに接続できることです。通常、Windows はクラッシュダンプの取得後にプロセスを終了させますが、非侵入型の接続ではクラッシュダンプの取得後もプロセスを続行できます。デバッガを非侵入的に接続するには、「Attach to Process」オプションを選択し、「Noninvasive」チェックボックスにチェックマークを付けます。
デバッガが接続されたら、次のコマンドを使用してクラッシュダンプを取得できます。
.dump /f crash.dmp
windbg デバッガは、「Debugging Tools for Windows」のダウンロードに含まれています。
このダウンロードに含まれる追加の dumpchk.exe ユーティリティーは、メモリーダンプファイルが正しく作成されたことを検証できます。
userdump.exe と windbg のどちらにも、プロセスのプロセス ID (pid) が必要です。userdump -p コマンドは、すべてのプロセスのプロセスとプログラムを一覧表示します。これは、アプリケーションが java.exe ランチャーで起動されることがわかっている場合に役立ちます。ただし、カスタムランチャーが使用される場合 (埋め込み VM)、プロセスの認識が困難である可能性があります。その場合は、Java プロセスの pid のみを一覧表示する jps コマンド行ユーティリティーを使用できます。
Solaris OS や Linux と同様に、Windows でも -XX:+ShowMessageBoxOnError コマンド行オプションを使用できます。致命的エラーが発生すると、プロセスはメッセージボックスを表示し、ユーザーからの「はい」または「いいえ」の応答を待ちます。
「はい」または「いいえ」をクリックする前に、userdump.exe ユーティリティーを使用すると、その Java プロセスのワトソン博士のダンプを生成できます。このユーティリティーは、プロセスがハングアップしているように見える場合にも使用できます。