Cisco CallManager がクラッシュまたはサービス シャットダウ
ンのどちらによって再起動したかを判別する方法
目次
概要
前提条件
要件
使用するコンポーネント
表記法
Cisco CallManager のクラッシュとシャットダウンの違い
クラッシュ
シャットダウン
Cisco CallManager のクラッシュをシスコ テクニカル サポートに報告する方法
関連情報
概要
このドキュメントでは、Cisco CallManager のクラッシュとサービス シャットダウンとの違いについて説明します。また、Cisco
CallManager のクラッシュを シスコ テクニカル サポートに報告し、問題のトラブルシューティングができるようにする手順に
ついても説明します。
前提条件
要件
このドキュメントに関する固有の要件はありません。
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアのバージョンに基づくものです。
Cisco CallManager 3.x および 4.0
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべて
のデバイスは、クリアな（デフォルト）設定で作業を開始しています。対象のネットワークが実稼働中である場合には、どのよう
なコマンドについても、その潜在的な影響について確実に理解しておく必要があります。
表記法
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
Cisco CallManager のクラッシュとシャットダウンの違い
クラッシュ
Cisco CallManager のクラッシュは、CallManager のコードのバグが原因で発生します。クラッシュには、主に次の 3 つのタイ
プがあります。
アクセス違反
ゼロ除算
不明な例外
クラッシュが発生すると、 ワトソン博士のエントリが作成され、既存の ワトソン博士ファイルの末尾に追加されます。また、ク
ラッシュの際には user.dmp ファイルも作成されます。これらのファイルは、C:\Documents and Settings\All
Users\Documents\DrWatson に作成されます。
ワトソン博士ファイルは、drwtsn32.log という名前のテキスト ファイルです。
設定を行うには、[Run] ウィンドウから drwtsn32 を選択します。
ワトソン博士 ファイルの解読方法
ワトソン博士ファイルを解読するには、 次の手順を実行します。
1. "when"（小文字）という単語を検索し、問題が発生したときの日時を探します。
ワトソン博士ファイルには、すべてのアプリケーションのクラッシュが記録されるため、 Cisco CallManager のクラッシュ
ではないクラッシュが記録されている場合もあります。Cisco CallManager のクラッシュではないクラッシュの記録には、
RisDC.exe や aupair.exe などがあります。
2. 問題が発生した日時が見つかったら、プロセス識別子（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で、これは アクセス違反です。この アクセス違反 は、オペレーティング システムによ
って設定されたアプリケーション メモリの範囲外の領域にアプリケーションがアクセスしようとしたことを意味します。
他に考えられるクラッシュのタイプはゼロ除算です。次の例に示すように、ゼロ除算の例外番号は 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 がない場合は、何が発生したのかを特定する手がかりを開発エンジニアに問い合わ
せます。
4. ファイルの 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
77fcb998 807d1400
0650c92a=??
77fcb99c 0f8586300000
77fcb9a2 57
77fcb9a3 53
77fcb9a4 e8646cfbff
(77f8260d)
77fcb9a9 8b4f0c
34eb5aaa=00003781
jnbe
cmp
RtlFreeHeap+0x20f (77fcb842)
byte ptr [ebp+0x14],0x0
ss:
jne
RtlZeroHeap+0x327 (77fcea28)
push
edi
push
ebx
call RtlConsoleMultiByteToUnicodeN+0x348
mov
ecx,[edi+0xc]
ds:
77fcb9ac 8b4708
34eb5aaa=00003781
77fcb9af 3bc1
77fcb9b1 8901
00e95da0=00cae82c
FAULT ->77fcb9b3 894804
014cbdfe=ec810000
mov
eax,[edi+0x8]
ds:
cmp
mov
eax,ecx
[ecx],eax
ds:
mov
[eax+0x4],ecx
ds:
!--- This is the assembly code statement that resulted in the crash.
77fcb9b6 744d
77fcb9b8 8a4705
34eb5aaa=81
77fcb9bb a804
77fcb9bd 0f8521310000
77fcb9c3 8a4605
34eb5f42=d5
77fcb9c6 2410
77fcb9c8 a810
77fcb9ca 884705
34eb5aaa=81
77fcb9cd 0f8555030000
77fcb9d3 0fb70f
346984d8=0093
77fcb9d6 8b4510
0650c92a=????????
jz
mov
77fd4405
al,[edi+0x5]
test
jne
mov
al,0x4
RtlZeroHeap+0x3e3 (77fceae4)
al,[esi+0x5]
ds:
and
test
mov
al,0x10
al,0x10
[edi+0x5],al
jne
movzx
RtlSizeHeap+0x3ef (77fcbd28)
ecx,word ptr [edi]
ds:
mov
eax,[ebp+0x10]
ds:
ds:
ss:
*----> Stack Back Trace <----*
!--- This shows, in order, the addresses of the functions that executed
!--- just before the crash.
FramePtr
05CEF358
05CEF400
05CEF448
05CEF460
05CEFF34
05CEFF80
invoke
ReturnAd
77FCB733
7800115C
00C0304F
00B66F85
018E736B
780060CE
Param#1
02070000
02070000
34698978
00000001
025A6720
033B3D58
Param#2
34698970
00000000
00545EC2
00B6626C
77E964CB
77E964CB
Param#3
05CEF3D0
34698978
34698978
033B3D58
033C6B20
00000018
Param#4
00000000
05CEF454
34698978
025A6720
033C6B20
033C6B20
Function Name
ntdll!RtlSizeHeap
ntdll!RtlFreeHeap
!free
!<nosymbols>
!<nosymbols>
!ACE_OS_Thread_Adapter::
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
05cef35c
05cef36c
05cef37c
05cef38c
05cef39c
05cef3ac
05cef3bc
05cef3cc
05cef3dc
05cef3ec
05cef3fc
05cef40c
05cef41c
05cef42c
05cef43c
05cef44c
05cef45c
05cef46c
05cef47c
00
33
00
44
38
fc
39
e0
00
f8
98
01
00
20
fe
b8
4f
78
6c
98
00
b7
00
5b
29
f3
e2
f3
00
2b
ef
00
00
67
08
ff
30
89
62
f6
07
fc
00
e3
6a
ce
b5
ce
07
cf
ce
00
00
5a
00
00
c0
69
b6
e6
02
77
00
09
09
05
00
05
02
21
05
00
00
02
00
78
00
34
00
36
70
00
54
94
40
38
57
cc
19
01
38
48
78
02
00
50
78
34
58
00
89
00
f4
f3
5b
29
92
f3
00
f1
f4
f4
89
00
00
32
89
ff
3d
00
69
07
ce
ce
e3
6a
89
ce
00
ce
ce
ce
69
00
00
03
69
ce
3b
00
34
02
05
05
09
09
01
05
00
05
05
05
34
00
00
78
34
05
03
00
-
00
70
78
30
a8
40
30
0f
01
28
a7
5c
54
64
98
ff
c2
85
20
00
00
89
89
e6
f3
5b
db
4f
f4
ff
9d
11
f4
00
ef
ff
5e
6f
67
00
00
69
69
b5
ce
e3
55
5b
ce
ce
fb
00
ce
00
ce
ff
54
b6
5a
00
00
34
34
00
05
09
02
00
05
05
77
78
05
00
05
ff
00
00
02
00
00
d0
20
fc
65
c4
f5
e0
f8
70
90
00
04
5c
28
60
78
01
98
00
f4
f3
67
f3
e5
f3
50
f3
2b
f3
26
00
fa
00
ff
f4
89
00
f6
00
ce
ce
5a
ce
b5
ce
5b
ce
cf
ce
f8
07
ce
00
ce
ce
69
00
e6
00
05
05
02
05
00
05
00
05
21
05
77
02
05
00
05
05
34
00
36
00
....p.i4........
3..w....p.i4....
....T...x.i4 gZ.
D[......0.......
8)j.@[......e...
....8)j.@[......
9...W...0.U..P[.
.........O[.....
.............+.!
.+.!....(...p...
....8......w.&.w
....H...\..x....
....x.i4T.......
gZ.....d...\...
............(...
...xP2.x....`...
O0..x.i4.^T.x.i4
x.i44....o......
lb..X=;. gZ....6
...6............
これらの 6 つの情報は、クラッシュのシグニチャの一部（全部ではありません）を構成しています。シグニチャを定義する
残りの情報は次のとおりです。
クラッシュのタイプ（アクセス違反、ゼロ除算、または不明な例外）
クラッシュの直前に実行されていた最後の Signal Distribution Layer（SDL）トレース ステートメント
注：クラッシュの前に使用されていた最後の SDL ファイルには、 ワトソン博士ファイルと同様に、あらゆるクラッシ
ュ バグが追加されています。
このシグニチャ情報（直前の SDL ファイル、直前の Cisco CallManager ファイル、および ワトソン博士ファイル）は、新
しいクラッシュ Distributed Defect Tracking System（DDTS）ファイルを作成すると、DDTS レコードに追加されます。
新しいクラッシュと既存の DDTS とが一致し、根本原因が同じであれば、次の情報は同じです。
例外のタイプ
クラッシュ発生時に実行されていた関数の名前
スタック バック トレースの中の関数名
注：これらの名前は、 ワトソン博士ファイルには表示されない場合もあります。
FAULT マーカーの横に表示されるアセンブリ コード ステートメント
最後の SDL トレース行（きわめて類似しているはずです）
クラッシュの原因が既存の DDTS と同じ場合でも、レジスタの内容、メモリ アドレス、および他の情報は異なる場合があり
ます。実行している Cisco CallManager のバージョンが異なればアドレスも変わります。実行している Cisco
CallManager のバージョンが同じであれば、アセンブリ コード セクションおよびスタック トレース セクションに表示さ
れるアドレスは同じです。
5. クラッシュをデバッグするために、次のファイルを収集します。
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 サービスがクラッシュしたときにも発生します。この問題を解決するには、次の
手順を実行します。
1. [Start] > [Programs] > [Administrative Tools] > [Component Services] の順に選択します。
2. [Component Services] > [Computers] > [My Computer] > [COM+ Applications] の順に展開します。
3. MSDTC（分散トランザクション コーディネーター）サービスを起動します（停止している場合）。
シャットダウン
Cisco CallManager の再始動のもう一つのタイプは、シャットダウンです。これは、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::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 スレッドは、次のプロセスを次の順序で起動します。
1. データベース（ProcessDb）
注：ProcessDb は Cisco CallManager のデータベース層（DBL）のコードに対するインターフェイスです。
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
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) に基づいています。実行しているバージョンが異なる場
合は、値がわずかに異なる可能性があります。
1. データベースの初期化時間（デフォルトは 900 秒）：このタイマーを開始するシグナルは、MmmanInit プロセスに送られる
"start" シグナルです。このシグナルは SDL トレースに書き込まれます。
2. リージョンの初期化時間（デフォルトは 120 秒）
3. AARNeighborhoods の初期化時間（デフォルトは 90 秒）
4. ロケーションの初期化時間（デフォルトは 90 秒）
5. ルート計画の初期化時間（デフォルトは 600 秒）
6. ディジット分析の初期化時間（デフォルトは 900 秒）。
7. コール制御の初期化時間（デフォルトは 90 秒）
8. 補足サービスの初期化時間（デフォルトは 900 秒）：開始シグナルは CcInitDone で停止シグナルは SsInitDone です。
9. デバイスの初期化時間（デフォルトは 360 秒）
10. ディレクトリの初期化時間（デフォルトは 90 秒）
11. CSSManager の初期化時間（デフォルトは 900 秒）
12. 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 のクラッシュの真の原因を診断するのは困難です。原因を突き止めて迅速に解決するために、 シスコ テクニ
カル サポートでは、必ずトレースと ワトソン博士のログを収集して情報を シスコ テクニカル サポートのケース ノートへアッ
プロードしていただくことをお願いしています。ケース ノートは [email protected] 宛てに送信してください。このとき、メー
ルの件名にケース番号を添えてください。手順は次のとおりです。
1. クラッシュの 30 分前から 15 分後までの Cisco CallManager トレース ファイルを収集します。
このトレースは、C:\Program Files\Cisco\Trace\CCM にあります。
2. クラッシュの 30 分前から 15 分後までの SDL トレース ファイルを収集します。
このトレースは、C:\Program Files\Cisco\Trace\SDL\CCM にあります。
3. user.dmp ファイルと drwtsn32.log ファイルを収集します。
これらのファイルは、C:\Documents and Settings\All Users\Documents\DrWatson に作成されます。
4. [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
5. すべてのファイルを次に示す順序で zip ファイルに圧縮してから、メールで送信してコピーしてください。
ファイルの圧縮には、WinZip バージョン 8 を使用してください （Cisco はこのユーティリティのサイト ライセンスを所
有しています）。通常は、より迅速に評価できるように、ローカル マシンにファイルをコピーします。圧縮されたファイル
は容量が小さく、元のファイル形式よりも短い時間で移動できます。
a. user.dmp ファイルと drwtsn32.log ファイルを一緒に圧縮します。
すぐにこの zip ファイルを送信し、コピーします。症状の説明と、Cisco CallManager の正確なバージョン、当該デ
バイスの負荷、および Cisco IOSR ソフトウェア バージョンをお知らせください。特別なパッチを使用している場合
は、そのことについても明確に伝えてください。
b. Cisco CallManager のトレース ファイルと SDL のトレース ファイルを一緒に圧縮します。
この zip ファイルを送信およびコピーし、連絡があるまで保存しておいてください。
c. perfmon ログをまとめて圧縮します。
この zip ファイルを送信およびコピーし、連絡があるまで保存しておいてください。
d. イベント ログのエントリをまとめて圧縮します。
この zip ファイルを送信およびコピーし、連絡があるまで保存しておいてください。
6. すべてのトレースとログを収集したら、これらのファイルを圧縮し、その zip ファイルを [email protected] 宛てに送信し
てください。メールの件名にはケース番号を添えてください。
関連情報
Cisco CallManager サービスのクラッシュ（英語）
Cisco CallManager クラッシュのトラブルシューティング（英語）
音声に関する技術サポート（英語）
音声とユニファイド コミュニケーションに関する製品サポート（英語）
Troubleshooting Cisco IP Telephony
テクニカルサポートとドキュメント Cisco Systems
1992 - 2014 Cisco Systems, Inc. All rights reserved.
Updated: 2014 年 1 月 31 日
http://www.cisco.com/cisco/web/support/JP/100/1008/1008012_cm_crashes_and_shutdowns-j.html
Document ID: 46806