Cisco CallManager がクラッシュまたはサービス シャットダウンのどちら

Cisco CallManager がクラッシュまたはサービス シャットダウンのどちらによ
って再起動したかを判別する方法
目次
概要
前提条件
要件
使用するコンポーネント
表記法
Cisco CallManager のクラッシュとシャットダウンの違い
クラッシュ
シャットダウン
Cisco CallManager のクラッシュを Cisco TAC に報告する方法
関連情報
概要
この文書では、Cisco CallManager のクラッシュとサービス シャットダウンとの違いに
ついて説明します。 また、問題のトラブルシューティングのために、Cisco
CallManager のクラッシュを報告する手順と、Cisco Technical Assistance Center
(TAC) に連絡する方法についても説明します。
前提条件
要件
この文書に関する特別な要件はありません。
使用するコンポーネント
この文書の情報は、次のソフトウェアのバージョンに基づいています。
•
Cisco CallManager 3.1、3.2、3.3
この文書の情報は、特定のラボ環境にあるデバイスに基づいて作成されています。こ
の文書で使用するすべてのデバイスは、クリアな状態（デフォルト）から設定作業を始
めています。対象のネットワークが実稼動中である場合には、すべてのコマンドによ
る潜在的な影響について確実に理解しておく必要があります。
表記法
文書表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
Cisco CallManager のクラッシュとシャットダウンの違い
クラッシュ
Cisco CallManager のクラッシュは、CallManager のコードのバグが原因で発生します。
クラッシュには、主に次の 3 つのタイプがあります。
•
•
•
アクセス違反
ゼロによる除算
不明の例外
クラッシュが発生すると、ワトソン博士のエントリが作成され、既存のワトソン博士ファ
イルの末尾に追加されます。 また、クラッシュの際には user.dmp ファイルも作成され
ます。 これらのファイルは、C:\Documents and Settings\All
Users\Documents\DrWatson に作成されます。
ワトソン博士ファイルは、drwtsn32.log という名前のテキスト ファイルです。
設定を行うには、Run ウィンドウから drwtsn32 を選択します。
ワトソン博士ファイルの読み方
ワトソン博士ファイルを読むには、次の手順に従ってください。
1. 「when」（小文字）という単語を検索し、問題が発生したときの日時を探します。
ワトソン博士ファイルには、すべてのアプリケーションのクラッシュが記録され
るため、Cisco CallManager のクラッシュではないクラッシュが記録されている
場合もあります（たとえば、RisDC.exe や aupair.exe など）。
2. 問題が発生した日時の場所が分かったら、process identifier（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
3. クラッシュしたアプリケーションが Cisco CallManager の場合は、例外番号をメ
モして、クラッシュのタイプを判別します。
注： Cisco CallManager 以外のアプリケーションのクラッシュの場合は、当該の
開発チームへの問い合せが必要になる場合があります。
Application exception occurred:
App: (pid=752)
When: 9/1/2000 @ 10:23:40.836
Exception number: c0000005 (access
violation)
この例では、例外番号は「c0000005」で、「access violation」（アクセス違
反）であると示されています。 これは、このアプリケーションが、オペレーティン
グ システムから割り当てられたアプリケーション メモリの範囲外の領域にアク
セスしようとしたことを意味しています。
他に可能性のあるクラッシュ タイプは、ゼロによる除算です。 次の例に示すよ
うに、ゼロによる除算の例外番号は「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 Distributed Defect Tracking
System（DDTS）と照合できます。適合するものがない場合は、開発エンジニア
にその原因を特定する手がかりを問い合せることになります。
4. ファイルの when セクションの下で「FAULT」（大文字）という単語を探し、クラッ
シュの「シグニチャ」を定義します。
このファイルの「FAULT」セクションには、次の 6 つの重要な情報が含まれてい
ます。
o
o
o
o
o
o
問題が生じたスレッドの番号
クラッシュ発生時のこのスレッドのレジスタの内容
クラッシュ発生時に実行されていた関数
クラッシュによって生成されたアセンブリ コード文
クラッシュの発生直前に実行されていた関数のアドレスを順に示すスタ
ック バック トレース
クラッシュ発生時のランタイム スタックの内容に関する詳細情報を示す、
ロウ スタック ダンプ
次に示すコードは、Cisco CallManager のアクセス違反によるクラッシュの例を
示しています。上記の 6 つの重要な要素は「FAULT」という単語と一緒に強調
表示されており、ファイル内のセクションをあらわしています。
State Dump for Thread Id 0x998
!--- 問題が生じたスレッドの番号
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
efl=00000283
es=0023
fs=003b
gs=0000
!--- クラッシュ発生時のレジスタの内容
function: RtlSizeHeap
!--- クラッシュ発生時に実行されていた関数
77fcb992
0f87aafeffff
jnbe
RtlFreeHeap+0x20f
(77fcb842)
77fcb998 807d1400
cmp
byte ptr
[ebp+0x14],0x0
ss:0650c92a=
??
!--- 注： 上記の値は、スペースの制限上 2 行で表示さ
れています。
77fcb99c
0f8586300000
jne
RtlZeroHeap+0x327
(77fcea28)
77fcb9a2 57
push
edi
77fcb9a3 53
push
ebx
77fcb9a4 e8646cfbff
call
RtlConsoleMultiByteToUnicodeN+0x348
(77f8260d)
!--- 注： 上記の値は、スペースの制限上 2 行で表示さ
れています。
77fcb9a9
8b4f0c
4eb5aaa=
mov
ecx,[edi+0xc]
ds:3
00003781
!--- 注： 上記の値は、スペースの制限上 2 行で表示さ
れています。
77fcb9ac
8b4708
4eb5aaa=
mov
eax,[edi+0x8]
ds:3
00003781
!--- 注： 上記の値は、スペースの制限上 2 行で表示さ
れています。
77fcb9af 3bc1
cmp
eax,ecx
77fcb9b1
8901
0e95da0=
mov
[ecx],eax
ds:0
00cae82c
!--- 注： 上記の値は、スペースの制限上 2 行で表示さ
れています。
FAULT ->77fcb9b3
894804
mov
14cbdfe=
ec810000
[eax+0x4],ecx
ds:0
!--- クラッシュによって生成されたアセンブリ コード
文
!--- 注： 上記の値は、スペースの制限上 2 行で表示さ
れています。
77fcb9b6 744d
77fcb9b8
8a4705
mov
ds:34eb5aaa=
81
jz
77fd4405
al,[edi+0x5]
!--- 注： 上記の値は、スペースの制限上 2 行で表示さ
れています。
77fcb9bb a804
77fcb9bd
0f8521310000
jne
(77fceae4)
77fcb9c3
8a4605
mov
ds:34eb5f42=
d5
test
al,0x4
RtlZeroHeap+0x3e3
al,[esi+0x5]
!--- 注： 上記の値は、スペースの制限上 2 行で表示さ
れています。
77fcb9c6 2410
77fcb9c8 a810
and
test
al,0x10
al,0x10
77fcb9ca
884705
ds:34eb5aaa=
81
mov
[edi+0x5],al
!--- 注： 上記の値は、スペースの制限上 2 行で表示さ
れています。
77fcb9cd
0f8555030000
jne
RtlSizeHeap+0x3ef
(77fcbd28)
77fcb9d3 0fb70f
movzx
ecx,word
ptr [edi]
ds:346984d8=
0093
!--- 注： 上記の値は、スペースの制限上 2 行で表示さ
れています。
77fcb9d6
8b4510
650c92a=
mov
eax,[ebp+0x10]
ss:0
????????
!--- 注： 上記の値は、スペースの制限上 2 行で表示さ
れています。
*----> Stack Back Trace <----*
!--- ここでは、クラッシュの直前に実行されていた関数
のアドレスを
!--- 順番に表示しています。
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
!--- 注： 上記の値は、スペースの制限上 2 行で表示さ
れています。
05CEFFB4 77E96523 033C6B20 77E964CB 00000018
033C6B20 !beginthreadex
05CEFFEC 00000000 00000000 00000000 00000000
00000000 kernel32!TlsSetValue
*----> Raw Stack Dump <----*
!--- ここでは、クラッシュの発生時のランタイム スタ
ックの詳細な
!--- 情報を示しています。
05cef34c
f4 ce 05
05cef35c
f3 ce 05
05cef36c
67 5a 02
05cef37c
f3 ce 05
05cef38c
e5 b5 00
05cef39c
f3 ce 05
05cef3ac
50 5b 00
05cef3bc
f3 ce 05
05cef3cc
2b cf 21
05cef3dc
f3 ce 05
05cef3ec
26 f8 77
05cef3fc
00 07 02
00 00 07 02 70 89
....p.i4........
33 b7 fc 77 00 00
3..w....p.i4....
00 00 00 00 54 f4
....T...x.i4 gZ.
44 5b e3 09 94 f3
D[......0.......
38 29 6a 09 40 5b
8)j.@[......e...
fc f3 ce 05 38 29
....8)j.@[......
39 e2 b5 00 57 92
9...W...0.U..P[.
e0 f3 ce 05 cc f3
.........O[.....
00 00 07 02 19 00
.............+.!
f8 2b cf 21 01 f1
.+.!....(...p...
98 ef ce 05 38 f4
....8......w.&.w
01 00 00 00 48 f4
....H...\..x....
69 34 - 00 00 00 00 00
07 02 - 70 89 69 34 d0
ce 05 - 78 89 69 34 20
ce 05 - 30 e6 b5 00 fc
e3 09 - a8 f3 ce 05 65
6a 09 - 40 5b e3 09 c4
89 01 - 30 db 55 02 f5
ce 05 - 0f 4f 5b 00 e0
00 00 - 01 f4 ce 05 f8
ce 05 - 28 ff ce 05 70
ce 05 - a7 9d fb 77 90
ce 05 - 5c 11 00 78 00
05cef40c
fa ce 05
05cef41c
00 00 00
05cef42c
ff ce 05
05cef43c
f4 ce 05
05cef44c
89 69 34
05cef45c
00 00 00
05cef46c
f6 e6 36
05cef47c
00 00 00
00 00 00 00 78 89
....x.i4T.......
20 67 5a 02 02 00
gZ.....d...\...
fe 08 00 00 00 00
............(...
b8 ff 00 78 50 32
...xP2.x....`...
4f 30 c0 00 78 89
O0..x.i4.^T.x.i4
78 89 69 34 34 ff
x.i44....o......
6c 62 b6 00 58 3d
lb..X=;. gZ....6
98 f6 e6 36 00 00
...6............
69 34 - 54 f4 ce 05 04
00 00 - 64 00 00 00 5c
00 00 - 98 ef ce 05 28
03 78 - ff ff ff ff 60
69 34 - c2 5e 54 00 78
ce 05 - 85 6f b6 00 01
3b 03 - 20 67 5a 02 98
00 00 - 00 00 00 00 00
これらの 6 つの箇所の情報は、クラッシュのシグニチャの一部（全部ではな
い）を表しています。シグニチャを決める残りの情報は、次のものです。
クラッシュのタイプ（アクセス違反、ゼロによる除算、不明の例外）
o クラッシュの直前に実行されていた Signal Distribution Layer（SDL）の
トレース文
o
注： クラッシュの前に使用されていた直前の SDL ファイルは、ワトソン
博士ファイルと同様に、あらゆるクラッシュのバグに対応付けられてい
ます。
新しいクラッシュ DDTS ファイルを作成したときには、このシグニチャ情報（直
前の SDL ファイル、直前の Cisco CallManager ファイル、およびワトソン博士
ファイル）を、DDTS レコードに対応付けます。
この新たなクラッシュが同じ原因を持つ既存の DDTS と一致する場合は、次
の情報が同じになります。
o
o
o
o
o
例外のタイプ
クラッシュ発生時に実行されていた関数の名前
スタック バック トレースの中の関数名（これらの名前は、ワトソン博士
ファイルには表示されない場合もあります）
FAULT マーカーの次に表示されるアセンブリ コード文
直前の SDL トレース行（非常に類似）
クラッシュの原因が既存の DDTS と同じ場合でも、レジスタの内容、メモリ アド
レス、および他の情報は異なる場合があります。実行している Cisco
CallManager のバージョンが異なると、アドレスも変わります。実行している
Cisco CallManager のバージョンが同じ場合は、アセンブリ コード セクションや
スタック トレース セクションのアドレスは同じになります。
5. クラッシュをデバッグするために、次のファイルを収集します。
o drwtsn32.log
o user.dmp
o 直前の SDL ファイルと Cisco CallManager のトレース ファイル（クラッ
シュの前の約 5 分間と、再始動の後の約 5 分間）
o proglog ファイル（Cisco CallManager バージョン 3.2 と 3.3 を使用してい
る場合のみ）
o イベント ログ（システムとアプリケーション）（存在する場合）
o パフォーマンス モニタ（perfmon）のログ（存在する場合）
シャットダウン
Cisco CallManager の再始動のもう 1 つのタイプは、シャットダウンです。これは、
CallManager が効果的に動作できなくなり、自身をシャットダウンするものです。シャッ
トダウンは次の 2 つのカテゴリに分かれます。
•
•
初期化タイムアウト
SDL タイマーと SDL ルータ スレッドの停止
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::NEROCM1Cluster><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
};
Reason 1 と Reason 2 は、内部シャットダウンの珍しいケースですが、他は一般的な
ものです。 Reason 3 は、SDL ルータ スレッドから応答がなくなったことを示していま
す。Reason 4 は、SDL タイマー スレッドから応答がなくなったことを示しています。ま
た、Reasons 5 から 13 は、初期化タイマーが切れたこと示しています。
初期化タイムアウト
Cisco CallManager のサービスが最初に開始されるときには、CallManager Process
Monitor（CMProcMon）スレッドが起動します。また、MmmanInit スレッドが起動し、こ
れによって他のすべてのプロセスが生成されます。さらに SDL ルータ スレッドが起動
し、このスレッドはあるプロセスから他のプロセスへ送られたシグナルを処理します。
これらの 3 つスレッドは、基本的には同時に起動します。 MmmanInit スレッドが他の
プロセスを起動させる際には、CMProcMon スレッドと SDL ルータ スレッドが起動して
実行中である必要があります。
MmmanInit スレッドは、次のプロセスを、この順番に起動します。
1. データベース（ProcessDb。Cisco CallManager の DBL コードに対するインター
フェイス）
MmmanInit は、これと同時に、H225Handler、MGCPBhHandler、LineManager
など、他の CallManager 内部の別個のプロセスを複数起動します。
2. リージョン
3. ロケーション
4. リンク サービス
5. ディジット解析
6. ルート計画
7. コール制御
8. 補足サービス（コール パーク、自動転送、会議、転送などの機能）
9. メッセージ変換（ゲートウェイから来る H.323 シグナルのデコードに使用）
10. ディレクトリ
11. デバイス
これらのタスクは連続して実行されます。これらの 11 のタスクには、それぞれタイマ
ーがあり、タスクの起動時に開始されます。 タスクが完了する前にタイマーが切れる
と、Cisco CallManager によって実行が停止され、次のような SDL トレースが出力され
ます。
Critical thread death: name of the timer which fired
各タイマーと、そのタイマーを開始する SDL シグナル、および、停止する SDL シグナ
ルを次に示します。 「InitDone」シグナルは、トレース レベルが適切に設定
（SdlTraceTypeFlags を 0x8000CB15 に設定）されていると、SDL トレースに書き込ま
れます。 次の情報により、CallManager の初期化プロセスが明らかになります。
タイマー
SDL 開始シグナル
SDL 停止シグナル
MmmanInit プロセス
データベースの
に送られる「開始」シ
初期化時間（デ
DbInitDone（タイマー
グナル。SDL トレー
フォルトは 180
をオフにします）
スに書き込まれま
秒）
す。
リージョンの初
期化時間（デフ DbInitDone
ォルトは 90 秒）
RegionsInitDone
ロケーションの
初期化時間（デ
RegionsInitDone
フォルトは 30
秒）
LocationsInitDone
ロケーションの
初期化時間（デ
LocationsInitDone
フォルトは 60
秒）
LinkInitDone
ディジット解析
の初期化時間
（デフォルトは
30 秒）
DaInitDone
LocationsInitDone
ルート計画の初
期化時間（デフ DaInitDone
ォルトは 30 秒）
RoutePlanInitDone
コール制御の初
期化時間（デフ RoutePlanInitDone
ォルトは 30 秒）
CcInitDone
補足サービスの
初期化時間（デ
CcInitDone
フォルトは 180
秒）
SsInitDone
メディアの初期
化時間(1)（デフォ SsInitDone
ルトは 30 秒）
MtInitDone
ディレクトリの初
期化時間（デフ MtInitDone
ォルトは 30 秒）
DirectoryInitDone
デバイスの初期
化時間（デフォ DirectoryInitDone
ルトは 180 秒）
DeviceInitDone
•
(1)
メディアの初期化時間という名称は、誤解を招きやすいものです。 これはメ
ディアとは関係がなく、実際にはメッセージ変換の初期化タイマーのことです。
すべてのタスクが完了すると、Cisco CallManager によって、ネットワーク上の他のノ
ードで実行されている CallManager サービスや、ネットワーク上の同じノードや別のノ
ードで実行されている Computer Telephony Integration（CTI）Manager サービスへの
SDL リンクが開かれます。
次に、MmmanInit から CMInitComplete シグナルが CMProcMon スレッドへ返されま
す。CMProcMon を最初に開始したときには、Cisco CallManager の初期化のために、
60 分のハードコードされたタイマー（CMInitComplete_WaitTime）が開始されます（これ
はサービス パラメータではありません。また、設定変更はできませ
ん）。 CMInitComplete シグナルを MmmanInit から 60 分以内に受信できなかった
場合は、CallManager が停止し、次のようなトレース文が出力されます。
Timed out waiting for CMInitComplete signal
11 の初期化タスクのいずれかが失敗するか、これらのタスクすべてを含めた処理時
間が 60 分を超過した場合は、CallManager が停止します。
注： CMInitComplete_WaitTime タイマーは、かつては 10 分にハードコードされていま
したが、Cisco bug ID CSCdx31622（登録ユーザのみ）の一環で 60 分に変更されました。
この変更は、3.1(3) Extended Services（ES; 拡張サービス）トレインの ES 38 から、そ
して、3.2(2) ES トレインでは ES 11 から適用されています。また、Seaview 3.3 でも適
用されています。
一部ツールについては、ゲスト登録のお客様にはアクセスできない場合がありますこ
とを、ご了承ください。
初期化のタイマーが切れるという問題がある場合には、単にそのタイマー設定の数
値を増やすだけで、起動の問題は解決します。解決しない場合は、データベースの応
答時間が長すぎて、それによって処理がタイムアウトになっている可能性がありま
す。 この場合は、SDL トレースおよび Cisco CallManager トレースの他に、詳細な
DBL トレースの収集も必要になることがあります。
初期化の問題をデバッグするためには、次のファイルを収集します。
•
•
•
詳細な Cisco CallManager のトレース
SdlTraceTypeFlags を 0x8000CB15 に設定した状態での SDL トレース
詳細な 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::USNYTSVOIPPB01Cluster><NID::10.2.40.11>
02/05/2003 00:30:32.790 Cisco CallManager|CMProcMon - ---Exited Router
Verification|<CLID::USNYTSVOIPPB01Cluster><NID::10.2.40.11>
CMProcMon スレッドは、ルータの検証を開始（enter）および終了（exit）し、SDL ルー
タ スレッドはこの確認に対して正常であると応答します。
しかし、SDL ルータ スレッドから応答がない場合は、Cisco CallManager のトレースに、
次のように While loop と出力されます。
CMProcMon - ----Entered While loop ++++ TimeAtWhileEntry:
[some number here],
TimeBeforeSleep: [another number], TimeAfterSleep: [a
third number], sleepTimeWas : [4th
number"
この「緊急事態」の際には、SDL ルータ スレッドは 20 秒間にわたって 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::NEROCM1Cluster><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 タイマー スレッドの実
行が遅いことを意味しています。ここでは、CallManager の予測時間と実際のオペレ
ーティング システムの時間の差が 1.63 秒になっています。
この差が 16 秒を超えると、Cisco CallManager が自身をシャットダウンします。シャッ
トダウンの理由コードが 4 になります。
SDL タイマー スレッドのシャットダウンが起きる可能性が最も高い原因は、
CallManager に対する CPU タイムの不足です。VirusScan または STI Backup などの
他のアプリケーションが、直前の 16 秒間に CPU リソースのほとんどを使用していた
ことによります。Perfmon ログは、このタイプのシャットダウンの原因を識別するため
に必須です。
SDL ルータ スレッドまたは SDL タイマー スレッドのシャットダウンが起きた場合には、
次のファイルを収集してください。
•
•
•
詳細な Cisco CallManager のトレース
SdlTraceTypeFlags を 0x8000CB15 に設定した状態での SDL トレース
可能であれば、そのボックス上で実行されていたすべてのプロセスの CPU 使
用率を示す perfmon トレース（これは、Cisco CallManager の CPU のパフォー
マンスへの影響を減らすために、リモートから取得することもできます）
Cisco CallManager のクラッシュを Cisco TAC に報告する方法
Cisco CallManager のクラッシュの真の原因を診断するのは、難しいことです。 Cisco
TAC では、原因を突き止めて迅速に解決するために、トレースとワトソン博士のログ
を収集して、Cisco TAC のサービス リクエスト ノートへアップロードしていただくことを
必要とします。 サービス リクエスト ノートは、メールの件名にサービス リクエスト番号
を添えて、[email protected] に送ります。 手順は次のとおりです。
1. Cisco CallManager のトレース ファイルを、クラッシュの 30 前から 15 分後ま
で収集します。
このトレースは、C:\Program Files\Cisco\Trace\CCM にあります。
2. SDL のトレース ファイルを、クラッシュの 30 前から 15 分後まで収集します。
このトレースは、C:\Program Files\Cisco\Trace\SDL\CCM にあります。
3. user.dmp ファイルと drwtsn32.log ファイルを収集します。
これらのファイルは、C:\Documents and Settings\All
Users\Documents\DrWatson にあります。
4. システムとアプリケーションのイベント ログ ファイルを収集します。
このイベント ログ データは、場合によっては必要ではありません。ただし、シ
ステムとアプリケーションのイベントをダンプし、クラッシュの直前約 30 分間の
イベントだけを抽出しておく必要があります。 Cisco TAC に送る前に、これら
のイベントを詳しく調べてください。より重要なイベントが見つかる可能性があ
ります。
注意： 利用率の高いシステムでは、Event Viewer（組み込みの
Microsoft のユーティリティ）を使用して、これらのイベントをテキスト ファイル
にダンプして、他のすべてのプロセス（電話の登録を管理するために使用され
ている CallManager KeepAlive プロセスなど）を CPU から容易に排除できます。
elogdmp.exe という名前のシェアウェア ユーティリティを使用すると、個々のロ
グファイルのすべてのエントリをテキスト ファイルにダンプできます。
elogdmp.exe ツールを使用する際の CPU への影響は、無視できる程度のも
のです。 DOS プロンプトから、次のように実行します。
elogdmp COMPUTER_NAME Application > AppEvents.txt
elogdmp COMPUTER_NAME System > SysEvents.txt
5. すべてのファイルを次に示す順に zip ファイルに圧縮した後に、メールに添付
およびコピーしてください。
ファイルの圧縮には、WinZip バージョン 8 を使用してください（Cisco はこのユ
ーティリティのサイト ライセンスを所有しています）。通常は、より迅速に評価
するために、ファイルはローカルのマシンにコピーされます。圧縮されたファイ
ルは容量が小さく、元のファイル形式よりも短い時間で移動できます。
a. user.dmp ファイルと drwtsn32.log ファイルを一緒に圧縮します。
すぐにこの zip ファイルを送信し、コピーします。 症状の説明と、Cisco
CallManager の正確なバージョン、当該デバイスの負荷、および Cisco
IOS(R) ソフトウェア バージョンをお知らせください 特別なパッチを使用し
ている場合は、そのことについても明確に伝えてください。
b. Cisco CallManager のトレースと SDL トレースのファイルを一緒に圧縮
します。
この zip ファイルを送信およびコピーし、連絡があるまで保存しておい
てください。
c. perfmon ログをすべて一緒に圧縮します。
この zip ファイルを送信およびコピーし、連絡があるまで保存しておい
てください。
d. イベント ログのエントリをすべて一緒に圧縮します。
この zip ファイルを送信およびコピーし、連絡があるまで保存しておい
てください。
6. すべてのトレースとログを収集したら、これらのファイルを圧縮し、その zip ファ
イルを [email protected] 宛てに、メールの件名にサービス リクエスト番号を
付けて送信してください。
関連情報
•
•
•
•
•
•
•
製品サポート：Cisco CallManager
Cisco CallManager サービスのクラッシュ
ボイス テクノロジー
ボイス、テレフォニー、およびメッセージング デバイス
ボイス ソフトウェア
ボイス、テレフォニー、およびメッセージングに関する TAC eLearning
Solutions
*推奨文献：「Troubleshooting Cisco IP Telephony」 , Cisco Press 発行、
ISBN 1587050757
テクニカルサポートトップへ
All contents copyright (C) 1992--2003 Cisco Systems K.K.
Updated: Oct 21, 2004
Document ID: 46806