クラッシュまたはサービスのシャットダウンとして Cisco CallManager の再起動を識別する方法
目次
概要
このドキュメントでは、Cisco CallManager クラッシュとサービス シャットダウンの違いについて説明します。 また、Cisco CallManager のクラッシュを シスコ テクニカル サポートに報告し、問題のトラブルシューティングができるようにする手順についても説明します。
前提条件
要件
このドキュメントに関する固有の要件はありません。
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアのバージョンに基づくものです。
-
Cisco CallManager 3.x および 4.0
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。 ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。
表記法
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
Cisco CallManager のクラッシュとシャットダウンの違い
クラッシュ
Cisco CallManager のクラッシュは、CallManager のコードのバグが原因で発生します。 クラッシュには、主に次の 3 つのタイプがあります。
-
アクセス違反
-
ゼロ除算
-
不明な例外
クラッシュが発生すると、Dr. Watson のエントリが生成されて既存の Dr. Watson ファイルの末尾に追加されます。 また、クラッシュの際には user.dmp ファイルも作成されます。 これらのファイルは、C:\Documents and Settings\All Users\Documents\DrWatson に作成されます。
Dr. Watson ファイル（テキスト ファイル）の名前は drwtsn32.log です。
設定を行うには、[Run] ウィンドウから drwtsn32 を選択します。
Dr. Watson ファイルを判読する方法
Dr. Watson ファイルの判読は、次の手順で行います。
-
“when”（小文字）という単語を検索し、問題が発生したときの日時を探します。
Dr. Watson には、すべてのアプリケーション クラッシュが記録されます。 Cisco CallManager のクラッシュではないクラッシュが記録されている場合もあります。 Cisco CallManager のクラッシュではないクラッシュの記録には、RisDC.exe や aupair.exe などがあります。
-
問題が発生した日時が見つかったら、プロセス識別子（PID）番号を調べ、タスク リストを検索して、クラッシュしたアプリケーションを判別します。
タスク リストは、この手順の例に表示されています。
下の例では、クラッシュしたアプリケーションの PID は 752 で、アプリケーション名は SCAN32.exe です。
Application exception occurred: App: (pid=752) When: 9/1/2000 @ 10:23:40.836 Exception number: c0000005 (access violation) *----> System Information <----* Computer Name: CISCO-8VCUWBLUJ User Name: SYSTEM Number of Processors: 1 Processor Type: x86 Family 6 Model 8 Stepping 3 Windows 2000 Version: 5.0 Current Build: 2195 Service Pack: None Current Type: Uniprocessor Free Registered Organization: Cisco Systems Inc. Registered Owner: Cisco User *----> Task List <----* 0 Idle.exe 8 System.exe 144 smss.exe 168 csrss.exe 164 winlogon.exe 216 services.exe 228 lsass.exe 336 ibmpmsvc.exe 380 svchost.exe 424 svchost.exe 576 regsvc.exe 592 MSTask.exe 924 Explorer.exe 992 cmd.exe 972 msiexec.exe 928 tp4mon.exe 856 ibmpmsvc.exe 852 ltmsg.exe 408 RunDll32.exe 428 RunDll32.exe 328 PDirect.exe 620 TP98.exe 968 tphkmgr.exe 948 PRPCUI.exe 668 AUTOCHK.exe 744 tponscr.exe 868 KIX32.exe 520 spoolsv.exe 1164 Avsynmgr.exe 1136 VsStat.exe 1192 Vshwin32.exe 1224 Mcshield.exe 1024 MCUPDATE.exe 752 SCAN32.exe 1292 drwtsn32.exe 0 _Total.exe
-
クラッシュしたアプリケーションが Cisco CallManager の場合は、例外番号からクラッシュのタイプを判別します。
注: Cisco CallManager のクラッシュではないアプリケーションのクラッシュは、必要に応じて該当する開発チームに通知してください。
Application exception occurred: App: (pid=752) When: 9/1/2000 @ 10:23:40.836 Exception number: c0000005 (access violation)
この例では、例外番号は c0000005 で、これはアクセス違反です。 このアクセス違反は、オペレーティング システムによって設定されたアプリケーション メモリの範囲外の領域にアプリケーションがアクセスしようとしたことを意味します。
他に考えられるクラッシュのタイプはゼロ除算です。 次の例に示すように、ゼロ除算の例外番号は c0000094 です。
Application exception occurred: App: (pid=1564) When: 1/7/2003 @ 13:16:15.051 Exception number: c0000094 (divide by zero)
クラッシュ タイプには不明な例外もあります。 次の例に示すように、不明な例外の例外番号は e06d7363 です。
Application exception occurred: App: (pid=2784) When: 12/10/2002 @ 09:02:58.202 Exception number: e06d7363
クラッシュの原因がアクセス違反なのか、ゼロ除算、または不明な例外なのかを判別したら、既存の Cisco bug とクラッシュを照合できます。 適合する Cisco bug がない場合は、何が発生したのかを特定する手がかりを開発エンジニアに問い合わせます。
-
ファイルの when セクションの下で FAULT という単語を探し、クラッシュの「シグニチャ」を定義します。
注: FAULT は大文字で表示されます。
ファイルの FAULT セクションには、次の 6 つの重要な情報が含まれています。
-
問題が生じたスレッドの番号
-
クラッシュ発生時のこのスレッドのレジスタの内容
-
クラッシュ発生時に実行されていた関数
-
クラッシュによって生成されたアセンブリ コード ステートメント
-
クラッシュの発生直前に実行されていた関数のアドレスを順に示すスタック バック トレース
-
クラッシュ発生時のランタイム スタックの内容に関する詳細情報を示す、ロウ スタック ダンプ
次に示すコードは、アクセス違反による Cisco CallManager のクラッシュの例を示しています。 太字で強調表示しているのは、上記の 6 つの重要な要素と FAULT という単語です。この単語がファイル内のこのセクションのマーカーです。
State Dump for Thread Id 0x998 !--- This number is the number of the thread that experienced the problem. eax=00cae82c ebx=02070000 ecx=00e95da0 edx=346984d8 esi=34698970 edi=346984d8 eip=77fcb9b3 esp=05cef34c ebp=05cef358 iopl=0 nv up ei ng nz na pe cy cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000283 !--- This provides the contents of the registers at the time of the crash. function: RtlSizeHeap !--- This function executed at the time of the crash. 77fcb992 0f87aafeffff jnbe RtlFreeHeap+0x20f (77fcb842) 77fcb998 807d1400 cmp byte ptr [ebp+0x14],0x0 ss: 0650c92a=?? 77fcb99c 0f8586300000 jne RtlZeroHeap+0x327 (77fcea28) 77fcb9a2 57 push edi 77fcb9a3 53 push ebx 77fcb9a4 e8646cfbff call RtlConsoleMultiByteToUnicodeN+0x348 (77f8260d) 77fcb9a9 8b4f0c mov ecx,[edi+0xc] ds: 34eb5aaa=00003781 77fcb9ac 8b4708 mov eax,[edi+0x8] ds: 34eb5aaa=00003781 77fcb9af 3bc1 cmp eax,ecx 77fcb9b1 8901 mov [ecx],eax ds: 00e95da0=00cae82c FAULT ->77fcb9b3 894804 mov [eax+0x4],ecx ds: 014cbdfe=ec810000 !--- This is the assembly code statement that resulted in the crash. 77fcb9b6 744d jz 77fd4405 77fcb9b8 8a4705 mov al,[edi+0x5] ds: 34eb5aaa=81 77fcb9bb a804 test al,0x4 77fcb9bd 0f8521310000 jne RtlZeroHeap+0x3e3 (77fceae4) 77fcb9c3 8a4605 mov al,[esi+0x5] ds: 34eb5f42=d5 77fcb9c6 2410 and al,0x10 77fcb9c8 a810 test al,0x10 77fcb9ca 884705 mov [edi+0x5],al ds: 34eb5aaa=81 77fcb9cd 0f8555030000 jne RtlSizeHeap+0x3ef (77fcbd28) 77fcb9d3 0fb70f movzx ecx,word ptr [edi] ds: 346984d8=0093 77fcb9d6 8b4510 mov eax,[ebp+0x10] ss: 0650c92a=???????? *----> Stack Back Trace <----* !--- This shows, in order, the addresses of the functions that executed !--- just before the crash. FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name 05CEF358 77FCB733 02070000 34698970 05CEF3D0 00000000 ntdll!RtlSizeHeap 05CEF400 7800115C 02070000 00000000 34698978 05CEF454 ntdll!RtlFreeHeap 05CEF448 00C0304F 34698978 00545EC2 34698978 34698978 !free 05CEF460 00B66F85 00000001 00B6626C 033B3D58 025A6720 !<nosymbols> 05CEFF34 018E736B 025A6720 77E964CB 033C6B20 033C6B20 !<nosymbols> 05CEFF80 780060CE 033B3D58 77E964CB 00000018 033C6B20 !ACE_OS_Thread_Adapter:: invoke µµ 05CEFFEC 00000000 00000000 00000000 00000000 00000000 kernel32!TlsSetValue *----> Raw Stack Dump <----* !--- This provides more information about what was on the run-time stack !--- at the time of the crash. 05cef34c 00 00 07 02 70 89 69 34 - 00 00 00 00 00 f4 ce 05 ....p.i4........ 05cef35c 33 b7 fc 77 00 00 07 02 - 70 89 69 34 d0 f3 ce 05 3..w....p.i4.... 05cef36c 00 00 00 00 54 f4 ce 05 - 78 89 69 34 20 67 5a 02 ....T...x.i4 gZ. 05cef37c 44 5b e3 09 94 f3 ce 05 - 30 e6 b5 00 fc f3 ce 05 D[......0....... 05cef38c 38 29 6a 09 40 5b e3 09 - a8 f3 ce 05 65 e5 b5 00 8)j.@[......e... 05cef39c fc f3 ce 05 38 29 6a 09 - 40 5b e3 09 c4 f3 ce 05 ....8)j.@[...... 05cef3ac 39 e2 b5 00 57 92 89 01 - 30 db 55 02 f5 50 5b 00 9...W...0.U..P[. 05cef3bc e0 f3 ce 05 cc f3 ce 05 - 0f 4f 5b 00 e0 f3 ce 05 .........O[..... 05cef3cc 00 00 07 02 19 00 00 00 - 01 f4 ce 05 f8 2b cf 21 .............+.! 05cef3dc f8 2b cf 21 01 f1 ce 05 - 28 ff ce 05 70 f3 ce 05 .+.!....(...p... 05cef3ec 98 ef ce 05 38 f4 ce 05 - a7 9d fb 77 90 26 f8 77 ....8......w.&.w 05cef3fc 01 00 00 00 48 f4 ce 05 - 5c 11 00 78 00 00 07 02 ....H...\..x.... 05cef40c 00 00 00 00 78 89 69 34 - 54 f4 ce 05 04 fa ce 05 ....x.i4T....... 05cef41c 20 67 5a 02 02 00 00 00 - 64 00 00 00 5c 00 00 00 gZ.....d...\... 05cef42c fe 08 00 00 00 00 00 00 - 98 ef ce 05 28 ff ce 05 ............(... 05cef43c b8 ff 00 78 50 32 03 78 - ff ff ff ff 60 f4 ce 05 ...xP2.x....`... 05cef44c 4f 30 c0 00 78 89 69 34 - c2 5e 54 00 78 89 69 34 O0..x.i4.^T.x.i4 05cef45c 78 89 69 34 34 ff ce 05 - 85 6f b6 00 01 00 00 00 x.i44....o...... 05cef46c 6c 62 b6 00 58 3d 3b 03 - 20 67 5a 02 98 f6 e6 36 lb..X=;. gZ....6 05cef47c 98 f6 e6 36 00 00 00 00 - 00 00 00 00 00 00 00 00 ...6............これらの 6 つの情報は、クラッシュのシグニチャの一部（全部ではありません）を構成しています。 シグニチャを定義する残りの情報は次のとおりです。
-
クラッシュのタイプ（アクセス違反、ゼロ除算、または不明な例外）
-
クラッシュの直前に実行されていた最後の Signal Distribution Layer（SDL）トレース ステートメント
注: クラッシュの前に使用があった最後の SDL ファイル、また Dr. Watson ファイルは、あらゆるクラッシュへの大使館員煩わせます。
新しい Distributed Defect Tracking System（DDTS）の作成時には、このシグニチャ情報（最終 SDL ファイル、最終 Cisco CallManager ファイル、および Dr. Watson ファイル）が DDTS レコードに添付されます。
新しいクラッシュと既存の DDTS とが一致し、根本原因が同じであれば、次の情報は同じです。
-
例外のタイプ
-
クラッシュ発生時に実行されていた関数の名前
-
スタック バック トレースの中の関数名
注: 関数の名前は Dr. Watson ファイルに記録されないこともあります。
-
FAULT マーカーの横に表示されるアセンブリ コード ステートメント
-
最後の SDL トレース行（きわめて類似しているはずです）
クラッシュの原因が既存の DDTS と同じ場合でも、レジスタの内容、メモリ アドレス、および他の情報は異なる場合があります。 実行している Cisco CallManager のバージョンが異なればアドレスも変わります。 実行している Cisco CallManager のバージョンが同じであれば、アセンブリ コード セクションおよびスタック トレース セクションに表示されるアドレスは同じです。
-
-
クラッシュをデバッグするために、次のファイルを収集します。
-
drwtsn32.log
-
user.dmp
-
直前の SDL トレース ファイルと Cisco CallManager トレース ファイル（クラッシュの前の約 5 分間と、再始動後の約 5 分間）
-
proglog ファイル
注: Cisco CallManager バージョン 3.2 以降でのみ、以下のファイルを収集します。
-
システムとアプリケーションの両方のイベント ログ（存在する場合）
-
パフォーマンス モニタ（perfmon）のログ（存在する場合）
-
DBLException エラー
このエラー メッセージは、Cisco CallManager パブリッシャとサブスクライバの両方のアプリケーション ログに表示されます。
Error: DBLException - DBL Exception. ErrorCode: 8 ExceptionString: Invalid parameter UNKNOWN_PARAMNAME:Text: addDevice App ID: Cisco CallManager Cluster ID: XXXX-Cluster Node ID: 192.168.0.2 Explanation: Severe database layer interface error occurred. Recommended Action: Contact TAC..
または
A COM error occurred during processing. (6) Details: Error No. -2147219962 (0x80040606): CDBLException Dump: [COM Error] COM Error Description = []
このタイプのエラーが発生するのは、IP フォンが登録拒否された場合か、パブリッシャ データベースとサブスクライバ データベースの間のサブスクリプションが壊れている場合です。 この問題は DBLHelper ツールを使用して解決できます。 DBLHelper の詳細は、『Cisco CallManager クラスタでの切断された SQL サブスクリプションの DBLHelper を使用した再構築』を参照してください。
このエラーは、Cisco Database Layer Monitor サービスがクラッシュしたときにも発生します。 この問題を解決するには、次の手順を実行します。
-
[Start] > [Programs] > [Administrative Tools] > [Component Services] の順に選択します。
-
[Component Services] > [Computers] > [My Computer] > [COM+ Applications] の順に展開します。
-
MSDTC（分散トランザクション コーディネーター）サービスを起動します（停止している場合）。
シャットダウン
Cisco CallManager の再始動のもう一つのタイプは、シャットダウンです。 これは、CallManager が実質的に動作できなくなり、自身をシャットダウンするものです。 シャットダウンは次の 2 つのカテゴリに分かれます。
Cisco CallManager が自身をシャットダウンすると、CallManager のトレースの最後の数行にシャットダウンの Reason code が表示されます。 次に例を示します。
03/22/2003 14:32:16.562 Cisco CallManager|CallManagerFailure - Indicates some failure in the Cisco CallManager system. Host name of hosting node.:NEROCM1 IP address of hosting node.:172.27.27.224 Reason code.:4 Additional Text [Optional]: App ID:Cisco CallManager Cluster ID:NEROCM1-Cluster Node ID:172.27.27.224|<CLID::NEROCM1-Cluster><NID::172.27.27.224><CT::Alarm>
次の例では、理由コードが 4 になっています。 次に示しているのは、Cisco CallManager のコードに含まれるシャットダウンの理由コードです。
class CallManagerFailureAlarm : public CallManagerAlarmCatalog {
public:
enum Reason {
Unknown = 1,
HeartBeatStopped = 2,
RouterThreadDied =3 ,
TimerThreadDied = 4,
CriticalThreadDied = 5,
DeviceMgrInitFailed = 6,
DigitAnalysisInitFailed = 7,
CallControlInitFailed = 8,
LinkMgrInitFailed = 9,
DbMgrInitFailed = 10,
MsgTranslationInitFailed = 11,
SupServiceInitFailed = 12,
DirectoryInitFailed = 13
};
理由 1 と理由 2 は内部シャットダウンの珍しいケースですが、他の理由は一般的なものです。 理由 3 は、SDL ルータ スレッドから応答がなくなったことを示します。 理由 4 は、SDL タイマー スレッドから応答がなくなったことを示します。 理由 5 ～ 13 は、初期化タイマーのタイムアウトと関連しています。
初期化タイムアウト
Cisco CallManager サービスを初めて開始したときに CallManager Process Monitor（CMProcMon）スレッドが起動します。 その後、MmmanInit スレッドが起動し、これによって他のすべてのプロセスが生成されます。 次に SDL ルータ スレッドが起動します。 このスレッドは、あるプロセスから他のプロセスへ送信されたシグナルを処理します。 これら 3 つのスレッドはすべて同時に起動します。 MmmanInit スレッドが他のプロセスを起動させる際には、CMProcMon スレッドと SDL ルータ スレッドが起動して実行中である必要があります。
MmmanInit スレッドがさまざまなプロセスを起動している間、CMProcMon と SDL が起動して実行中である必要があります。 MmmanInit スレッドは、次のプロセスを次の順序で起動します。
-
データベース（ProcessDb）
注: ProcessDb は Cisco CallManager のデータベース層（DBL）のコードに対するインターフェイスです。
MmmanInit のコードは、同時に CallManager 内部の独立した他のプロセスを複数起動します。 起動されるプロセスには、H225Handler、MGCPBhHandler、LineManager などがあります。
-
リージョン
-
AARNeighborhood
-
ロケーション
-
ルート計画
-
ディジット分析
-
コール制御
-
補足サービス
コール パーク、自動転送、会議、転送などの機能が含まれます。
-
デバイス
-
ディレクトリ
-
Calling Search Space Manager（CSSManager）
-
Time of Day Manager（TODManager）
これらのタスクは連続して実行されます。 この 12 のタスクにはそれぞれタイマーがあり、 タイマーはタスクの起動時に開始されます。 タスクが完了する前にタイマーが切れると、Cisco CallManager は停止し、次のような SDL トレースが出力されます。
Critical thread death: name of the timer which fired
このリストには、各タイマーと、そのタイマーを開始する SDL シグナル、およびタイマーを停止する SDL シグナルが表示されます。 SDL トレースに “InitDone” シグナルが表示されるようにするには、トレース レベルを適切に設定する必要があります （SdlTraceTypeFlags を 0x8000CB15 に設定します）。
次に示すデフォルト タイマーは Cisco CallManager バージョン 4.1(2) に基づいています。 実行しているバージョンが異なる場合は、値がわずかに異なる可能性があります。
-
データベースの初期化時間（デフォルトは 900 秒）：このタイマーを開始するシグナルは、MmmanInit プロセスに送られる "start" シグナルです。 このシグナルは SDL トレースに書き込まれます。
-
リージョンの初期化時間（デフォルトは 120 秒）
-
AARNeighborhoods の初期化時間（デフォルトは 90 秒）
-
ロケーションの初期化時間（デフォルトは 90 秒）
-
ルート計画の初期化時間（デフォルトは 600 秒）
-
ディジット分析の初期化時間（デフォルトは 900 秒）。
-
コール制御の初期化時間（デフォルトは 90 秒）
-
補足サービスの初期化時間（デフォルトは 900 秒）：開始シグナルは CcInitDone で停止シグナルは SsInitDone です。
-
デバイスの初期化時間（デフォルトは 360 秒）
-
ディレクトリの初期化時間（デフォルトは 90 秒）
-
CSSManager の初期化時間（デフォルトは 900 秒）
-
TODManager 初期化タイマー（デフォルトでは 900 秒）
すべてのタスクが完了すると、Cisco CallManager はネットワーク上の他のノードで実行されている CallManager サービスへの SDL リンクを開きます。 ネットワーク上の同じノードや別のノードで稼働しているコンピュータテレフォニーインテグレーション（CTI）マネージャ サービスへの SDL リンクも開きます。
次に、MmmanInit が CMInitComplete シグナルを CMProcMon スレッドへ返信します。 CMProcMon を初めて起動すると、Cisco CallManager を初期化するために、60 分にハードコードされたタイマーが開始されます。 タイマーの名前は CMInitComplete_WaitTime です （これはサービス パラメータではありません。 また、設定変更はできません）。 CMProcMon スレッドが CMInitComplete シグナルを 60 分以内に受信しなかった場合は CallManager が停止し、次のようなトレース ステートメントが出力されます。
Timed out waiting for CMInitComplete signal
12 の初期化タスクのいずれかが失敗するか、これらのタスクの合計処理時間が 60 分を超過すると、CallManager は停止します。
注: CMInitComplete_WaitTime タイマーは、以前は 10 分にハードコードされていました。 Cisco bug ID CSCdx31622（登録ユーザ専用）への対応の一環で 60 分に変更されました。 この変更は、3.1(3) Engineering Special（ES）トレインの ES 38 から、 そして、3.2(2) ES トレインでは ES 11 から適用されています。また、Cisco CallManager 3.3 にも適用されています。
初期化タイマーが切れるという問題がある場合は、タイマーの設定値を増やすだけで起動の問題が解決することもあります。 変更しても解決しない場合は、データベースの応答所要時間が長いために処理がタイムアウトしている可能性があります。 その場合は、SDL トレースおよび Cisco CallManager トレースの他に、必要に応じて詳細な DBL トレースを収集してください。
初期化の問題をデバッグするには、次のファイルを収集します。
-
詳細な Cisco CallManager トレース
-
SDL トレース
注: SdlTraceTypeFlags を 0x8000CB15 に設定します。
-
詳細な DBL トレース
SDL タイマーおよび SDL ルータ スレッドの停止
SDL ルータ スレッドは、Cisco CallManager アプリケーション内で実行されるスレッドの中で最も重要なスレッドです。 呼処理シグナルの送信を制御しているのがこのスレッドです。 CMProcMon スレッドは、SDL ルータ スレッドの状態を 2 秒ごとに確認します。 これは Cisco CallManager のトレースに次のように表示されます。
02/05/2003 00:30:32.790 Cisco CallManager|CMProcMon - ------Entered Router Verification|<CLID::USNYTSVOIPPB01-Cluster><NID::10.2.40.11> 02/05/2003 00:30:32.790 Cisco CallManager|CMProcMon - ----Exited Router Verification|<CLID::USNYTSVOIPPB01-Cluster><NID::10.2.40.11>
CMProcMon スレッドがルータの検証を開始して終了すれば、SDL ルータ スレッドがヘルス チェックに応答したことになり、正常であると判断されます。
しかし、SDL ルータ スレッドが応答しない場合は、次に示すように、Cisco CallManager のトレースに While loop と出力されます。
CMProcMon - ----Entered While loop ++++ TimeAtWhileEntry: [some number here], TimeBeforeSleep: [another number], TimeAfterSleep: [a third number], sleepTimeWas : [4th number"
このような緊急事態には、20 秒間にわたって SDL ルータ スレッドの状態が 1 秒ごとに確認されます。 この 20 秒の間に何らかの応答があった場合は、通常の処理が再開され、SDL ルータ スレッドの状態は再度 2 秒ごとに確認されるようになります。 ただし、この 20 秒間に SDL ルータ スレッドから応答がなかった場合は、Cisco CallManager アプリケーションはシャットダウンし、 SDL トレースに次のようなステートメントが出力されます。
000177508| 01/12/31 07:28:40.389| 001| AlarmErr | | | | | | AlarmClass: CallManager, AlarmName: CallManagerFailure, AlarmSeverity: Error AlarmMessage: , AlarmDescription: Indicates some failure in the Cisco CallManager system., AlarmParameters: HostName:CCM-PUB, IPAddress:10.5.162.180, Reason:3, Text:, AppID:Cisco CallManager, ClusterID:CCM-PUB-Cluster, NodeID:10.5.162.180,
このトレース ステートメントのテキストには、理由コードとして 3 が表示されています。 このコードは、SDL ルータ スレッドが応答を停止したために Cisco CallManager がシャットダウンしたことを意味しています。
SDL ルータ スレッドがシャットダウンする原因として最も可能性が高いのは、システムのリソース不足です。 他のアプリケーションが長時間（20 秒以上）にわたって CPU のほとんど、またはすべてを使用していました。 このようなタイプのシャットダウンのデバッグにはパフォーマンス モニタが必須となるのはそのためです。
調査が必要な他のタイプのシャットダウンとしては、SDL タイマー スレッドのシャットダウンがあります。 SDL タイマー スレッドのシャットダウンが発生するのは、Cisco CallManager の内部クロックと外部のオペレーティング システム クロックとの差が 16 秒を超えたときです。 この現象が発生すると、Cisco CallManager のトレースに次のトレース情報が表示されます。
03/22/2003 14:32:16.562 Cisco CallManager|CallManagerFailure - Indicates some failure in the Cisco CallManager system. Host name of hosting node.:NEROCM1 IP address of hosting node.:172.27.27.224 Reason code.:4 Additional Text [Optional]: App ID:Cisco CallManager Cluster ID:NEROCM1-Cluster Node ID:172.27.27.224|<CLID::NEROCM1-Cluster><NID::172.27.27.224><CT::Alarm>
Cisco CallManager は通常、タイマー スレッドを 1 秒ごとに確認します。 オペレーティング システムの現在の時刻に 1 秒を加え、その値を「予測時刻」として保存した後、” 1 秒間スリープ状態になります。 スリープ状態が終わった後、オペレーティング システムの新しい時刻を確認し、予測時刻を差し引きます。 この 2 つの時刻の差が 1 秒を超えると、Cisco CallManager のトレースに次の警告ステートメントが表示されます。
CMProcMon::star_sdlVerification - Test Timer exceeded minimum timer latency threshold of 1000 milliseconds, Actual latency: 1630 milliseconds
このステートメントに含まれる Actual latency は、Cisco CallManager 内部の SDL タイマー スレッドの実行が遅いことを意味します。 ここでは、Cisco CallManager の予測時刻とオペレーティング システムの実際の時刻の差が 1.63 秒になっています。
この差が 16 秒を超えると、Cisco CallManager はシャットダウンし、シャットダウンの理由コード 4 が表示されます。
SDL タイマー スレッドがシャットダウンする原因として最も可能性が高いのは、Cisco CallManager が使用できる CPU 時間の不足です。 VirusScan や STI Backup などの他のアプリケーションが、16 秒以上にわたって CPU リソースのほとんどを使用していました。 Perfmon ログは、このタイプのシャットダウンの原因を判別するために必須です。
Cisco IP テレフォニー アプリケーション バックアップが長時間にわたって CPU 使用率が高い状態で稼働していると、システム クラッシュが発生する可能性があります。 このシステム クラッシュを回避する方法についての詳細は、
-
「CPU の使用率が高くなることを防ぐためのバックアップ ユーティリティの設定確認」の項（ドキュメント『Cisco CallManager サービスのクラッシュ』）を参照してください。
SDL ルータ スレッドまたは SDL タイマー スレッドがシャットダウンした場合は、次のファイルを収集してください。
-
詳細な Cisco CallManager トレース
-
SDL トレース
注: SdlTraceTypeFlags を 0x8000CB15 に設定します。
-
システム上で実行されていたすべてのプロセスの CPU 使用率を示す perfmon トレース（取得してある場合）
注: これらのトレースをリモートから取り込むことで、Cisco CallManager サーバの CPU パフォーマンスへの影響を軽減できます。
シスコ テクニカル サポートへの Cisco CallManager のクラッシュの報告方法
Cisco CallManager のクラッシュの真の原因を診断するのは困難です。 シスコ テクニカル サポート では、原因を判別して問題を迅速に解決するために、トレースおよび Dr. Watson ログを収集して、その情報をシスコ テクニカル サポート ケース ノートにアップロードするようお願いしています。 ケース ノートは attach@cisco.com 宛てに送信してください。このとき、メールの件名にケース番号を添えてください。 手順は次のとおりです。
-
クラッシュの 30 分前から 15 分後までの Cisco CallManager トレース ファイルを収集します。
このトレースは、C:\Program Files\Cisco\Trace\CCM にあります。
-
クラッシュの 30 分前から 15 分後までの SDL トレース ファイルを収集します。
このトレースは、C:\Program Files\Cisco\Trace\SDL\CCM にあります。
-
user.dmp ファイルと drwtsn32.log ファイルを収集します。
これらのファイルは、C:\Documents and Settings\All Users\Documents\DrWatson に作成されます。
-
[Start] > [Programs] > [Administrative Tools] > [Event Viewer] の順に選択して、イベント ビューアからシステムとアプリケーションのイベント ログ ファイルを収集します。
イベント ログ データが不要な場合は、この手順を省略できます。 ただし、システムとアプリケーションのイベントをダンプし、クラッシュの前の約 30 分間のイベントだけを抽出します。 これらのイベントを調査してから シスコ テクニカル サポートに送信してください。 より重要なイベントが見つかる可能性があります。
注意： 組み込み Microsoft ユーティリティであるイベント ビューアを使用してイベントをテキスト ファイルにダンプする場合には、注意が必要です。 CPU 使用率の高いシステムでは、このようにイベント ビューアを使用すると、他のすべてのプロセスがすぐに CPU 不足になる可能性があります。 対象となるプロセスには、電話の登録を管理する CallManager KeepAlive プロセスも含まれます。個々のログに含まれるすべてのエントリは、elogdmp.exe という名前のシェアウェア ユーティリティを使用してテキスト ファイルにダンプすることができます。 elogdmp.exe ツールを使用する際の CPU への影響は、ほとんどありません。 DOS プロンプトから、次のコマンドを発行します。
elogdmp COMPUTER_NAME Application > AppEvents.txt elogdmp COMPUTER_NAME System > SysEvents.txt
-
すべてのファイルを次に示す順序で zip ファイルに圧縮してから、メールで送信してコピーしてください。
ファイルの圧縮には、WinZip バージョン 8 を使用してください （Cisco はこのユーティリティのサイト ライセンスを所有しています）。 通常は、より迅速に評価できるように、ローカル マシンにファイルをコピーします。 圧縮されたファイルは容量が小さく、元のファイル形式よりも短い時間で移動できます。
-
user.dmp ファイルと drwtsn32.log ファイルを一緒に圧縮します。
すぐにこの zip ファイルを送信し、コピーします。 説明的な現象定義を提供し、正確な Cisco CallManagerバージョン、適切なデバイス ロードおよび Cisco IOS ® ソフトウェア バージョン含んで下さい。 特別なパッチを使用している場合は、そのことについても明確に伝えてください。
-
Cisco CallManager のトレース ファイルと SDL のトレース ファイルを一緒に圧縮します。
この zip ファイルを送信およびコピーし、連絡があるまで保存しておいてください。
-
perfmon ログをまとめて圧縮します。
この zip ファイルを送信およびコピーし、連絡があるまで保存しておいてください。
-
イベント ログのエントリをまとめて圧縮します。
この zip ファイルを送信およびコピーし、連絡があるまで保存しておいてください。
-
-
すべてのトレースとログを収集したら、これらのファイルを圧縮し、その zip ファイルを attach@cisco.com 宛てに送信してください。 メールの件名にはケース番号を添えてください。
注意： 組み込み Microsoft ユーティリティであるイベント ビューアを使用してイベントをテキスト ファイルにダンプする場合には、注意が必要です。 CPU 使用率の高いシステムでは、このようにイベント ビューアを使用すると、他のすべてのプロセスがすぐに CPU 不足になる可能性があります。 対象となるプロセスには、電話の登録を管理する CallManager KeepAlive プロセスも含まれます。
フィードバック