音声とユニファイド コミュニケーション : Cisco Unified Communications Manager(CallManager)

クラッシュまたはサービスのシャットダウンとして Cisco CallManager の再起動を識別する方法

2015 年 11 月 25 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2014 年 1 月 31 日) | 英語版 (2015 年 8 月 22 日) | フィードバック


目次


概要

このドキュメントでは、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 ファイルを読み込むためにこれらのステップを完了して下さい:

  1. “when”(小文字)という単語を検索し、問題が発生したときの日時を探します。

    Dr. Watson ファイルはすべてのアプリケーション クラッシュを記録します。 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 Unified CallManager クラッシュである場合、か。クラッシュ の タイプを判別するために例外数に注意して下さい。

    注: 適切な開発チームに Cisco Unified 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. クラッシュの「シグニチャ」を定義し始めるようにワード エラーをの下でファイルのセクション捜して下さい。か。

    注:  FAULT は大文字で表示されます。

    ファイルの FAULT セクションには、次の 6 つの重要な情報が含まれています。

    • 問題が生じたスレッドの番号

    • クラッシュ発生時のこのスレッドのレジスタの内容

    • クラッシュ発生時に実行されていた関数

    • クラッシュによって生成されたアセンブリ コード ステートメント

    • クラッシュの発生直前に実行されていた関数のアドレスを順に示すスタック バック トレース

    • クラッシュ発生時のランタイム スタックの内容に関する詳細情報を示す、ロウ スタック ダンプ

    このコードはアクセス違反クラッシュである Cisco Unified 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 Unified CallManager ファイルおよび Dr. Watson ファイル)大使館員は新しいクラッシュ DDTS を作成すると記録します。

    新しいクラッシュと既存の DDTS とが一致し、根本原因が同じであれば、次の情報は同じです。

    • 例外のタイプ

    • クラッシュ発生時に実行されていた関数の名前

    • スタック バック トレースの中の関数名

      注: これらの名前は Dr. Watson ファイルに常に現われません。

    • FAULT マーカーの横に表示されるアセンブリ コード ステートメント

    • 最後の SDL トレース行(きわめて類似しているはずです)

    登録、メモリアドレスおよび他の情報のコンテンツは別の DDTS の情報とクラッシュに同じ根本的な原因があっても存在 すること異なることができます。か。 アドレスは Cisco Unified 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 の再始動のもう一つのタイプは、シャットダウンです。 シャットダウンは Cisco Unified CallManager が効果的に操作することができない、それ自身を停止するときあります。か。 シャットダウンは次の 2 つのカテゴリに分かれます。

Cisco Unified CallManager がそれ自身を停止する場合、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>

この例では、理由コードは 4.?This リスト提供します Cisco Unified 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 ルータ スレッドから応答がなくなったことを示します。 ?SDL タイマー スレッドが応答を停止したことを原因 4 は示します。か。 理由 5 ~ 13 は、初期化タイマーのタイムアウトと関連しています。

初期化タイムアウト

Cisco CallManager サービスを初めて開始したときに CallManager Process Monitor(CMProcMon)スレッドが起動します。 その後、MmmanInit スレッドが起動し、これによって他のすべてのプロセスが生成されます。 次に SDL ルータ スレッドが起動します。 このスレッドは、あるプロセスから他のプロセスへ送信されたシグナルを処理します。 これら 3 つのスレッドはすべて同時に起動します。 MmmanInit スレッドが他のプロセスを起動させる際には、CMProcMon スレッドと SDL ルータ スレッドが起動して実行中である必要があります。

MmmanInit スレッドがさまざまなプロセスを起動している間、CMProcMon と SDL が起動して実行中である必要があります。 MmmanInit スレッドは、次のプロセスを次の順序で起動します。

  1. データベース(ProcessDb)

    注:  ProcessDb は Cisco CallManager のデータベース層(DBL)のコードに対するインターフェイスです。

    MmmanInit のコードは、同時に CallManager 内部の独立した他のプロセスを複数起動します。 起動されるプロセスには、H225Handler、MGCPBhHandler、LineManager などがあります。

  2. リージョン

  3. AARNeighborhood

  4. ロケーション

  5. ルート計画

  6. ディジット分析

  7. コール制御

  8. 補足サービス

    コール パーク、自動転送、会議、転送などの機能が含まれます。

  9. デバイス

  10. ディレクトリ

  11. Calling Search Space Manager(CSSManager)

  12. Time of Day Manager(TODManager)

これらのタスクの業積はシリーズに発生します。か。 この 12 のタスクにはそれぞれタイマーがあり、 タイマーはタスクの起動時に開始されます。 タスクが完了する前にタイマー適用が、読む Cisco Unified 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 は CMProcMon スレッドに CMInitComplete 場合を送り返します。か。 CMProcMon は最初に開始するとき、Cisco Unified CallManager 初期化のための 60 分によってハードコードされるタイマーを開始します。か。 タイマーの名前は CMInitComplete_WaitTime です (これはサービス パラメータではありません。 また、設定変更はできません)。 CMProcMon スレッドが CMInitComplete シグナルを 60 分以内に受信しなかった場合は CallManager が停止し、次のようなトレース ステートメントが出力されます。

Timed out waiting for CMInitComplete signal

12 の初期化タスクのいずれかが失敗するか、これらのタスクの合計処理時間が 60 分を超過すると、CallManager は停止します。

注: CMInitComplete_WaitTime タイマーはかつて 10 分にハードコードでした。 ?このハードなコードは Cisco バグ 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 トレース

    注: 0x8000CB15 に SdlTraceTypeFlags を設定 して下さい。

  • 詳細な 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 ルータ スレッドがシャットダウンする原因として最も可能性が高いのは、システムのリソース不足です。 別のアプリケーションは時間の長時間の間 CPU ほとんどまたはすべてを、少なくとも 20 秒使用しました。か。このようなタイプのシャットダウンのデバッグにはパフォーマンス モニタが必須となるのはそのためです。

探索するべきシャットダウンの他の型は SDL タイマー スレッド シャットダウンです。か。 SDL タイマー スレッド シャットダウンは内部 Cisco Unified 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 Unified CallManager は一般に各秒タイマー スレッドを一度チェックします。か。 「期待時間として評価するストア現在のオペレーティング システム時間におよび Cisco Unified CallManager は 1秒を追加します。? 1 秒間スリープ状態になります。 ?Cisco Unified CallManager は気づいた後、新しいオペレーティング システム時間をチェックし、期待時間を引きます。か。 この 2 つの時刻の差が 1 秒を超えると、Cisco CallManager のトレースに次の警告ステートメントが表示されます。

CMProcMon::star_sdlVerification - Test Timer exceeded minimum timer latency 
threshold of? 1000 milliseconds, Actual latency: 1630 milliseconds

この文の実際のレイテンシーは内部 Cisco Unified CallManager SDL タイマー スレッドが遅い実行することを示します。か。 ここでは、Cisco CallManager の予測時刻とオペレーティング システムの実際の時刻の差が 1.63 秒になっています。

この差が 16 秒を超えると、Cisco CallManager はシャットダウンし、シャットダウンの理由コード 4 が表示されます。

SDL タイマー スレッド シャットダウンの可能性が高い原因は Cisco Unified CallManager のための CPUタイムの欠如です。か。 別のアプリケーションは、VirusScan または STI バックアップのような少なくとも 16 秒の間、CPU リソースのほとんどを使用しました。か。 Perfmon ログは、このタイプのシャットダウンの原因を判別するために必須です。

Cisco IP テレフォニー アプリケーション バックアップが長時間にわたって CPU 使用率が高い状態で稼働していると、システム クラッシュが発生する可能性があります。 このシステム クラッシュを回避する方法についての詳細は、

SDL ルータ スレッドまたは SDL タイマー スレッドがシャットダウンした場合は、次のファイルを収集してください。

  • 詳細な Cisco CallManager トレース

  • SDL トレース

    注: 0x8000CB15 に SdlTraceTypeFlags を設定 して下さい。

  • システム上で実行されていたすべてのプロセスの CPU 使用率を示す perfmon トレース(取得してある場合)

    注: Cisco CallManager サーバの CPU のパフォーマンス影響を減らすためにこれらのトレースをリモートで キャプチャ することができます。

Cisco CallManager のクラッシュをシスコ テクニカル サポートに報告する方法

Cisco CallManager のクラッシュの真の原因を診断するのは困難です。 原因を判別し、ソリューションを促進するために、Cisco テクニカル サポートはトレースおよび Dr. Watson ログを集め、Cisco テクニカルサポートケース メモに情報をアップロードするように要求します。 ケース ノートは attach@cisco.com 宛てに送信してください。このとき、メールの件名にケース番号を添えてください。 手順は次のとおりです。

  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 はこのユーティリティのサイト ライセンスを所有しています)。 一般に、より速い評価のためのローカルマシンへのファイル コピー。か。圧縮されたファイルは容量が小さく、元のファイル形式よりも短い時間で移動できます。

    1. user.dmp ファイルと drwtsn32.log ファイルを一緒に圧縮します。

      すぐにこの zip ファイルを送信し、コピーします。 説明的な現象定義を提供し、正確な Cisco CallManagerバージョン、適切なデバイス ロードおよび Cisco IOS を含んで下さいか。 ソフトウェア バージョン。 特別なパッチを使用している場合は、そのことについても明確に伝えてください。

    2. Cisco CallManager のトレース ファイルと SDL のトレース ファイルを一緒に圧縮します。

      この zip ファイルを送信およびコピーし、連絡があるまで保存しておいてください。

    3. perfmon ログをまとめて圧縮します。

      この zip ファイルを送信およびコピーし、連絡があるまで保存しておいてください。

    4. イベント ログのエントリをまとめて圧縮します。

      この zip ファイルを送信およびコピーし、連絡があるまで保存しておいてください。

  6. すべてのトレースとログを収集したら、これらのファイルを圧縮し、その zip ファイルを attach@cisco.com 宛てに送信してください。 メールの件名にはケース番号を添えてください。

関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 46806