問題の完全な説明を生成するには、次の質問に答えてください。
    - どのような状況でプロセスがクラッシュするか。この動作は一貫していますか?
    - 以前はもっとうまくいきましたか?
    - 発生時刻と観察された動作の傾向
- 問題は、バックアップ環境、バックアップ、または特定のタイプのバックアップ グループに負荷の高い場合にのみ発生しますか。
    - 問題が最初に発生したのはいつですか。その後、何が変わりましたか?
    - 問題の範囲(すべてのクライアント/一部のクライアント、すべてのバックアップターゲットまたは一部)
- これまでに修正を試みたことと、そこからどのような結論が導き出されたか。

     - 応答していないNetWorkerプロセスとマシン(サーバ、ストレージ ノード、クライアント)。
     - NetWorkerサーバーのバージョンとプラットフォーム
- バックアップデータゾーンのサイズと性質の概要
- これらのバックアップのターゲットメディア

      - オンラインの『NetWorker互換性ガイド』を使用して、すべてのコンポーネント(NetWorkerサーバー、ファイル システムのバージョン、プロキシ、ストレージ ノード、クライアント、ターゲット)がサポートされていることを確認します。
      - プロセスのクラッシュ (ディスク障害、ディスク不足、ネットワーク エラーなど) の原因となる基盤となるオペレーティング システムまたはハードウェアの欠陥がないことを確認します。

      『NetWorkerパフォーマンス最適化計画ガイド』には、最適にチューニングされたNetWorker環境を実現するために実装する必要があるいくつかの推奨されるソフトウェアおよびハードウェア要件と推奨事項が記載されています。これを確認して、このデータゾーンのベスト プラクティスに従っていることを確認する必要があります。これは、応答しないプロセスが最も負荷の高いときに発生する場合に関係します。

       プロセスが応答しない問題の根本原因を見つける方法は、ステップ1で定義された動作によって異なります。トリガーが不明な場合は、テストを実行して、クラッシュをトリガーしているものを確認できます。

    - 高負荷時のシステムパフォーマンスを監視します
- クラッシュ時のオペレーティングシステムのログファイルを調べて、動作の共通性を確認します
- NetWorkerスケジュールを読み、特定のNetWorkerスケジュールアクティビティの発生時刻の間に相関関係があるかどうかを判断します。
    - このマシンで実行されるNetWorker以外の操作のうち、その動作に影響を与える可能性があるものと、そのスケジュールがクラッシュの時刻と相関しているかどうかを確認します。
    - クラッシュが繰り返し発生する場合は、いくつかのパラメータを変更して原因を絞り込みます。  たとえば、異なるターゲット メディアへのバックアップや、同じNetWorkerクライアントからの異なるタイプのデータのバックアップなどです

コアダンプは、特定の時間 (通常はプログラムが異常終了したとき) のプロセスの作業メモリのダンプを表す特別なファイルです。  コア ダンプ ファイルは、クラッシュ時にプロセスのどの機能が実行されていたか、およびどのデータがアクセスされていたかを分析することで、応答しないプロセスの原因を診断するために使用できます

ほとんどのオペレーティング システムは、コア ダンプ ファイルを自動的に生成しません。  オペレーティング システムのパラメーターを変更して、プロセス クラッシュ時にコア ダンプ ファイルが生成されるようにする必要があります。  この変更は、クラッシュの前に行う必要があります。

1)/nsr/coresディレクトリでUNIXまたはLinuxのNetWorkerプロセスの最近のコア ダンプを確認するか、Windowsレジストリで定義されているクラッシュ ディレクトリを確認します(手順2を参照)

2)存在しない場合は、プロセス クラッシュが発生した場合にコア ダンプ ファイルを生成するようにオペレーティング システムが設定されていることを確認します。  詳細については、オペレーティング システムのドキュメントを参照してくださいが、簡単に言うと、これには、LinuxまたはUNIXでulimit -cおよび-fの値を変更し、Windowsでレジストリーを変更することが含まれる可能性があります

Windows 2008R2の場合:  
- http://msdn.microsoft.com/en-us/library/bb787181(VS.85).aspx.
で提供された新しいキーでレジストリを更新します。- 推奨値を使用して、ダンプ ファイルが C:\Users\Administrator\AppData\Local\CrashDumps
- Enable full crash dumps.

に作成されます。3)コアファイルは、ホストマシン自体で調べるか、別のマシンで分析するためにパッケージ化できます。  これらのコア ファイルのパッケージ化方法の詳細については、次の場所を参照してください。

UNIX および Linux コア ファイルのパッケージ化:
489272: コア/クラッシュ ダンプ情報と関連ログを収集する方法

4)使用可能なデータを分析します。

- オペレーティング システム ログ ファイル
- NetWorkerサーバーおよび関連するストレージ ノードからのNetWorkerデーモン ログ ファイル。  
- コア ファイルまたはクラッシュ ファイル

コア ファイルの詳細な分析には、NetWorkerの内部操作に関する高度な知識が必要であり、EMC NetWorkerサポートが行う必要があります。  ただし、コアファイルの最初の読み取りは、コアファイルの内容と既知の問題を比較するために実行できます

LinuxおよびHP-UX
gdb [プロセスへのフル パス][コア ファイル]
(gdb) where

AIX
dbx [プロセスへのフル パス] [コア ファイル]
(dbx) where

Solaris
pstack [コア ファイル]
dbx [プロセスへのフル パス] [コア ファイル]
(dbx) where

Windows
- windbg Windowsデバッガ プログラムを起動します
- [ファイル]をクリックして、windbgでダンプ ファイルを開きます。
- 下部のコマンドウィンドウに「analyze --v」と入力して、すべての情報を取得します。
    
5)上記の分析とシステムの動作に関する知識に基づいて、インシデントを最新バージョンのNetWorkerリリース ノートに記載されている既知の問題のリストと比較できます。

応答しないプロセスの原因となるNetWorkerソフトウェアの障害が疑われる場合は、クラッシュ ファイルをパッケージ化し(手順3を参照)、問題の詳細な分析のために、観察された動作の完全な説明とともにこれをDell Technologies NetWorkerサポートに提供する必要があります。