Hoe u een Cisco CallManager-herstart kunt identificeren als een crasher of servicesstop
Inhoud
Inleiding Voorwaarden Vereisten
Gebruikte componenten Conventies
Verschil tussen crashes en shutdown van Cisco CallManager crashes
Shutdowns
Hoe Cisco CallManager crashes aan Cisco Technical Support te melden Gerelateerde informatie
Inleiding
Dit document beschrijft het verschil tussen een crash van Cisco CallManager en een sluiting van de service. Het document biedt ook de procedure om een crash van Cisco CallManager te melden en Cisco Technical Support in staat te stellen voor de probleemoplossing.
Voorwaarden
Vereisten
Er zijn geen specifieke vereisten van toepassing op dit document.
Gebruikte componenten
De informatie in dit document is gebaseerd op deze softwareversies:
Cisco CallManager 3.x en 4.0
●
De informatie in dit document is gebaseerd op de apparaten in een specifieke
laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.
Conventies
Raadpleeg de Cisco Technical Tips Convention voor meer informatie over documentconventies.
Verschil tussen crashes en shutdown van Cisco CallManager
crashes
Een bug in de code van Cisco CallManager veroorzaakt crashes in CallManager. Er zijn drie soorten crashes:
Toegangsschendingen
●
Op nul splitsen
●
Onbekende uitzonderingen
●
Crashes genereren Dr. Watson inzendingen, die worden toegevoegd aan het eind van het
bestaande Dr. Watson-bestand. Crashes genereert ook user.dmp-bestanden. De locatie van deze bestanden is C:\Documents and Settings\All Users\Documents\DrWatson.
De naam van het Dr. Watson-bestand, een tekstbestand, is drwtsn32.log.
Kies Design32 uit het venster Start om de instellingen te configureren.
Zo leest u een Dr. Watson-bestand
Voltooi deze stappen om het Dr. Watson-bestand te lezen:
Zoek het woord "wanneer" in kleine letters en ontdek de datum en het tijdstip waarop het probleem zich heeft voorgedaan.De Dr. Watson-bestand registreert alle applicaties crashes.
Sommige crashrecords zijn mogelijk geen crashes van Cisco CallManager. Voorbeelden van crashrecords die geen Cisco CallManager-crashes zijn, zijn onder meer RisDC.exe en
aupair.exe.
1.
Nadat u de datum en het tijdstip van het probleem hebt gevonden, stelt u het PID-nummer (procesidentificatie) in en vervolgens selecteert u de taaklijst om te bepalen welke toepassing is crasht.De taaklijst verschijnt in het voorbeeld in deze stap.In dit voorbeeld heeft de
applicatie die is neergestort een PID van 752 en is de naam van de applicatie 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
2.
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
Als de crash een Cisco CallManager-crash is, noteer dan het uitzondering nummer om het type crash te bepalen.Opmerking: Route naar het juiste ontwikkelingsteam of een
toepassingscrash die, indien nodig, geen Cisco CallManager-crash is.
Application exception occurred:
App: (pid=752)
When: 9/1/2000 @ 10:23:40.836
Exception number: c0000005 (access violation)
In dit voorbeeld is het uitzonderingsnummer c0000005, wat een schending van de toegang is.
Deze toegangsschending betekent dat de toepassing heeft geprobeerd toegang te krijgen tot het geheugen buiten de geheugenlimiet die het besturingssysteem is ingesteld.Een ander mogelijk crashtype is door nul verdeeld. Zoals uit dit voorbeeld blijkt, is het
uitzonderingsnummer voor verdeling door nul c000094:
Application exception occurred:
App: (pid=1564)
When: 1/7/2003 @ 13:16:15.051
Exception number: c0000094 (divide by zero)
Het crashtype kan ook een onbekende uitzondering zijn. Zoals uit dit voorbeeld blijkt, is
e06d7363 het uitzondernummer voor onbekende uitzondering:
Application exception occurred:
App: (pid=2784)
3.
When: 12/10/2002 @ 09:02:58.202
Exception number: e06d7363
Wanneer u bepaalt als een ongeluk een schending van de toegang is, verdeel door nul, of onbekende uitzondering, kunt u een krach met een bestaand Cisco bug aanpassen. Als je geen overeenkomsten vindt, heeft de ontwikkelingsingenieur een goede start om te bepalen wat er gebeurd is.
Zoeken onder het wanneer paragraaf van het bestand voor het woord FAULT begint met het definiëren van de "handtekening" van het ongeluk. Opmerking: FAULT verschijnt in
hoofdletters.Dit FAULT-gedeelte van het bestand bevat zes belangrijke informatie, te
weten:Het aantal thread dat het probleem heeft ervarenDe inhoud van de registers voor deze draad ten tijde van de crashDe functie die uitgevoerd werd op het moment van de crashDe assemblagecode verklaring die tot de crash leiddeHet stapel terug spoor dat de adressen van de functies toont die, in orde, vlak vóór de crash werden uitgevoerdHet ruwe stort, dat meer informatie geeft over wat op de aanloopstapel was op het moment van de crashDeze code verstrekt een voorbeeld van een crash van Cisco CallManager die een crash van de toegangsschending is. De tekst op de onderzijde benadrukt de zes cruciale elementen en ook het woord FAULT, dat dit gedeelte van het bestand markeert:
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 µµ
4.
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...
Deze zes stukjes informatie maken deel uit van, maar niet alle, de crashhandtekening. De rest van de informatie die de handtekening definieert, is:Het type crash (toegangsschending, verdeling door nul, of onbekende uitzondering)De laatste Signal Distribution Layer (SDL) overzichten die voor de crash werden uitgevoerdOpmerking: het laatste SDL-bestand dat gebruikt werd voor de crash, en het Dr. Watson-bestand, heten aan elke crash bug.Deze signatuurinformatie (het laatste SDL-bestand, het laatste Cisco CallManager-bestand en het Dr. Watson-bestand) hecht aan het DDTS-record (Distributed Defect Tracking System) wanneer u een nieuwe crashDDTS maakt.Als je de nieuwe crash aanpast met een DDTS die al bestaat en dezelfde oorzaak heeft, is deze informatie hetzelfde:Het type uitzonderingDe naam van de functie die uitgevoerd werd op het moment van de crashDe namen van de functies in het stapelbackspoorOpmerking: Deze namen verschijnen niet altijd in een Dr.
Watson-bestand.De assemblagecode verklaring die naast de FAULT-markering verschijntDe laatste SDL-spoorlijnen, die sterk op elkaar zouden moeten lijkenDe inhoud van de registers, de geheugenadressen en andere informatie kan afwijken van de informatie in een ander DDTS dat bestaat, zelfs als het ongeluk dezelfde diepere oorzaak heeft. De adressen
variëren als u een andere versie van Cisco CallManager gebruikt. Als u de zelfde versie van Cisco CallManager in werking stelt, zijn de adressen in de sectie van de assemblagecode en in de sectie van het stapelspoor het zelfde.
Verzamel deze bestanden om de crash te debug:drwtsn32.loggebruiker.dmpDe laatste SDL- en Cisco CallManager-spoorbestanden, van ongeveer 5 minuten voor de crash en 5 minuten na de herstart.progamma-bestandenOpmerking: Verzamel deze bestanden alleen in Cisco CallManager versies 3.2 en hoger.Event logs, zowel systeem als toepassing, indien
beschikbaar.Performance Monitor (perfmon) logt, indien beschikbaar.
5.
DBLExceptiefout
U ziet deze foutmelding in het toepassingslogbestand van zowel Cisco CallManager als Subscriber:
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..
Of:
A COM error occurred during processing. (6)
Details:
Error No. -2147219962 (0x80040606):
CDBLException Dump: [COM Error] COM Error Description = []
Dit type fout doet zich voor wanneer een IP-telefoon van registratie wordt geweigerd of vanwege een defect abonnement tussen de uitgever en de databases van abonnees. Dit probleem kan worden opgelost door het DBLHelper-gereedschap te gebruiken. Raadpleeg voor meer informatie over DBLHelper het gebruik van DBLHelper om een verbroken Cisco CallManager Cluster SQL- abonnement weer op te zetten.
Deze fout kan ook optreden door de servicekrisis van de Cisco Database Layer Monitor. Voer de volgende stappen uit om het probleem op te lossen:
Ga naar Start > Programma's > Beheertools > Component-services.
1.
Component-services uitvouwen > computers > Mijn computer > COM+ toepassingen.
2.
Start de MSDTC-service (gedistribueerde transactiecoördinator) als deze wordt gestopt.
3.
Shutdowns
Het andere type van het opnieuw opstarten van Cisco CallManager is een sluiting. Een shutdown is wanneer Cisco CallManager niet effectief kan werken en zichzelf sluit. Sluiting valt in twee categorieën:
Time-out bij initialisatie
●
Dood van SDL-timer en SDL-routerservices
●
Als Cisco CallManager zichzelf afsluit, vindt u een code van de sluitingsreden in de laatste paar spoorlijnen van de spoorlijn van CallManager. Hierna volgt een voorbeeld:
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>
In dit voorbeeld is de redencode 4. Deze lijst verstrekt de codes van de sluitingsreden van de code van 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 };
Reden 1 en reden 2 zijn zeldzame gevallen van interne annuleringen, terwijl de andere redenen algemener zijn. Reden 3 geeft aan dat de SDL router thread is gestopt met reageren. Reden 4 geeft aan dat de SDL-timer niet meer reageert. De redenen 5-13 hebben betrekking op het vuur van de starttimer.
Time-out bij initialisatie
Wanneer de dienst van Cisco CallManager eerst begint, begint de thread van het Proces van CallManager (CMProcMon). Dan begint de MmanInit-draad, die alle andere processen
voortbrengt. Daarna begint de SDL router draad. Deze thread verwerkt signalen die van het ene proces naar het andere worden verzonden. Alle drie de draden beginnen tegelijkertijd. De draad van CMProcMonon en de router van SDL zijn in gebruik en lopen terwijl de draad van de
MummanInit andere processen begint.
CMProcmon en SDL moeten actief zijn terwijl MmanInit diverse processen op gang brengt. De MmanInit-thread start deze processen in deze volgorde:
Databaseverslag (ProcessingDB)Opmerking: Procesbalk is een Cisco CallManager-
interface naar DBL-code (Database Layer).Tegelijkertijd start de MummanInit-code ook een aantal andere interne, onafhankelijke processen van Cisco CallManager. Deze processen omvatten H225Handler, MGCPBHandler en LineManager.
1.
Regio's 2.
AARNeighborhood 3.
Locaties 4.
Routeplan 5.
Digitale analyse 6.
Gespreksbeheer 7.
Aanvullende servicesDe eigenschappen omvatten vraagpark, vooruit, conferentie, en overdracht.
8.
Apparaat 9.
Map 10.
Zoekfunctie bellen (CSSManager) 11.
Tijd van dagbeheer (TODManager) 12.
De vervulling van deze taken gebeurt in een reeks. Elk van de twaalf taken heeft een timer die bij de taak is betrokken. Deze timer start wanneer de taak wordt gestart. Als de timer vuurt voordat de taak wordt voltooid, stopt Cisco CallManager en drukt u een SDL-overtrek af die wordt gelezen:
Critical thread death: name of the timer which fired
Deze lijst toont elk van de timers, zowel als het SDL signaal dat de timer start en het SDL signaal dat de timer stopt. De "InitReady" signalen verschijnen in het SDL-spoor als u de juiste instellingen voor overtrekken hebt ingesteld. (U stelt DSLTraceTypeVlaggen in op 0x8000CB15.)
Deze standaard timers zijn gebaseerd op Cisco CallManager versie 4.1(2). Als u een andere versie draait, is het mogelijk dat de tekst iets anders is.
Database Initialization Time (standaard ingesteld op 900 seconden) - Het start signaal voor deze keer is het "start" signaal dat wordt verzonden naar het MmanInit proces. Je ziet dit in het SDL spoor.
1.
Begintijd regio's (standaard 120 seconden).
2.
Initialisatietijd AARNeighbords (standaard 90 seconden).
3.
Initialisatietijd voor locaties (standaard 90 seconden).
4.
Begintijd routeplan (standaard 600 seconden).
5.
Initialisatietijd voor digitale analyse (standaard 900 seconden).
6.
Initialisatietijd voor Call Control (standaard 90 seconden).
7.
Aanvullende services initialisatietijd (standaard 900 seconden) - Het startsignaal is CCnitReady en het eindsignaal is SsInitReady.
8.
Apparaatinitialisatietijd (standaard 360 seconden).
9.
Initialisatietijd map (standaard 90 seconden) 10.
Initialisatietijd van CSSManager (standaard 900 seconden).
11.
TODManager Initialization Time - (standaard ingesteld op 900 seconden).
12.
Nadat alle taken zijn voltooid, opent Cisco CallManager SDL links naar de CallManager services die op andere knooppunten in het netwerk worden uitgevoerd. Cisco CallManager opent ook SDL- koppelingen naar de diensten van de Manager van de Computer Telephony Integration (CTI) die op hetzelfde knooppunt of op verschillende knooppunten in het netwerk worden uitgevoerd.
Vervolgens stuurt MmanInit een CMInitComplete signaal terug naar de CMProcMon draad.
Wanneer CMProcMon eerst begint, begint het een 60 minuten hard-gecodeerde timer voor Cisco CallManager initialisatie. Op de timer staat de naam CMInitComplete_HoldTime. (Deze timer is geen serviceparameter; de timer is niet configureerbaar.) Als de CMProcMinon-thread niet het CMInitComplete-signaal binnen 60 minuten ontvangt, stopt Cisco CallManager en geeft een sporenverklaring af die luidt:
Timed out waiting for CMInitComplete signal
Als een van de twaalf initialisatietaken mislukt, of als de totale tijd voor deze taken 60 minuten overschrijdt, stopt Cisco CallManager.
Opmerking: de CMInitComplete_WachtenTime-timer was ooit hard gecodeerd tot 10 minuten.
Deze harde code is veranderd in 60 minuten als deel van Cisco bug-ID CSCdx31622 (alleen geregistreerde klanten). De verandering kwam in de 3.1(3) Engineering Special (ES)-trein, met ES 38 als begin. De verandering is ook in de 3.2(2) ES trein, met ES 11 als het begin, en in Cisco CallManager 3.3.
Als u problemen ondervindt met een vuur op de initialisatietimer, hoeft u de instelling van de timer alleen te verhogen om het opstartbeeld op te lossen. Als deze verandering het probleem niet oplost, kan het probleem een langzame tijd van de gegevensbestand zijn die de verrichting om uit te lopen veroorzaakt. Verzamel indien nodig gedetailleerde DBL-sporen, SDL- en Cisco
CallManager-sporen.
Verzamel deze bestanden om een initialisatieprobleem op te lossen:
Gedetailleerde Cisco CallManager-tracering
●
SDL-spoorOpmerking: Stel de SdlTraceTypeFlags in op 0x8000CB15.
●
Gedetailleerde DBL-sporen
●
Dood van SDL-timer en SDL-routerservices
De routerdraad van SDL is de belangrijkste draad van uitvoering binnen de toepassing van Cisco CallManager. Het controleert het verzenden van vraag verwerkingssignalen. De draad
CMProcMont controleert de gezondheid van de router van SDL eens in de twee seconden. De sporen van Cisco CallManager tonen deze gezondheidscontrole, zoals u in deze verklaringen kunt zien:
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>
Als de draad CMProcMonon router verificatie in en uit gaat, antwoordde de router SDL op de gezondheidscontrole en is fijn.
Als de SDL-routerdraad echter niet reageert, ziet u tegelijkertijd een lus in de Cisco CallManager-spoorlijn, zoals dit wordt weergegeven:
CMProcMon - ----Entered While loop ++++ TimeAtWhileEntry: [some number here], TimeBeforeSleep: [another number], TimeAfterSleep: [a third number], sleepTimeWas : [4th number"
In deze noodsituatie krijgt de SDL-routerdraad controles eenmaal per seconde voor een periode van 20 seconden. Als de draad op elk moment tijdens de 20-tweede periode reageert, wordt de normale handeling hervat en wordt de gezondheid van de SDL-routerdraad opnieuw elke 2 seconden gecontroleerd. Als echter de SDL-routerdraad niet op de controles gedurende de 20 seconden reageert, wordt de Cisco CallManager-toepassing uitgeschakeld. Deze verklaring verschijnt in het SDL spoor:
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,
Let op de reden code 3 in de tekst van deze overtrek-verklaring. De code betekent dat de SDL router draad een respons heeft gestopt, dus heeft Cisco CallManager afgesloten.
De meest waarschijnlijke oorzaak van de sluiting van een router van SDL is een gebrek aan systeemmiddelen. Een andere toepassing heeft de meeste of alle CPU’s gedurende een lange periode, ten minste 20 seconden, gebruikt. Deze activiteit is de reden dat prestatiemonitoren van vitaal belang zijn om dit soort shutdown te debug.
Een ander type shutdown dat we moeten onderzoeken is de SDL timer shutdown. Een sluiting van een timer voor SDL doet zich voor wanneer het verschil tussen de interne klok van Cisco CallManager en de externe systeemklok meer dan 16 seconden bedraagt. Wanneer de sluiting van SDL-timer plaatsvindt, verschijnt deze overtrek in het Cisco CallManager-spoor:
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 controleert over het algemeen de timer draden eens per seconde. Cisco CallManager voegt 1 seconde toe aan de huidige besturingssysteemtijd en slaat die waarde op als
"verwachte tijd". Vervolgens slaapt Cisco CallManager 1 seconde lang. Nadat Cisco CallManager is gestart, controleert u de nieuwe tijd voor het besturingssysteem en trekt u de verwachte tijd in.
Als het verschil tussen deze twee keer meer dan 1 seconde is, verschijnt deze waarschuwingsverklaring in de sporen van Cisco CallManager:
CMProcMon::star_sdlVerification - Test Timer exceeded minimum timer latency threshold of 1000 milliseconds, Actual latency: 1630 milliseconds
Feitelijke vertraging in deze verklaring toont aan dat de interne de tijdopdraad van Cisco CallManager SDL langzaam loopt. Hier is het verschil tussen de verwachte tijd van Cisco CallManager en de werkelijke tijd voor het besturingssysteem 1,63 seconden.
Als dit verschil meer dan 16 seconden bedraagt, sluit Cisco CallManager af en verstrekt Cisco CallManager de code met de sluitingsreden van 4.
De meest waarschijnlijke oorzaak van een sluiting van een timer van SDL is een gebrek aan CPU- tijd voor Cisco CallManager. Een andere toepassing, zoals VirusScan of STI Backup, heeft de meeste CPU-bronnen gedurende ten minste 16 seconden gebruikt. Perfmon logs zijn essentieel om de diepere oorzaak van dit type van sluiting te bepalen.
Als de back-up van Cisco IP-telefonie toepassingen gedurende een lange tijd bij gebruik met hoge CPU’s wordt uitgevoerd, kan een systeemstoring optreden. Raadpleeg voor informatie over het voorkomen van dit systeemongeval:
Controleer instellingen op het hulpprogramma voor back-up om een hoog CPU-gedeelte van het document te voorkomen, Cisco CallManager-servicecentrum
●
Verzamel deze bestanden in het geval van een SDL router-thread of SDL-timer:
Gedetailleerde Cisco CallManager-tracering
●
SDL-spoorOpmerking: Stel de SdlTraceTypeFlags in op 0x8000CB15.
●
Eventuele sporen die het procent CPU-gebruik van alle processen die in het vak lopen, weergevenN.B.: U kunt deze sporen op afstand opnemen om het effect op de CPU van de Cisco CallManager-server te beperken.
●
Hoe Cisco CallManager crashes aan Cisco Technical Support te melden
De diagnose van de werkelijke oorzaak van een crash van Cisco CallManager is moeilijk. Om de
oorzaak te bepalen en een oplossing te versnellen, is Cisco Technical Support vereist dat u sporen en Dr. Watson verzamelt en de informatie naar Cisco Technical Support Case Notes uploadt. U stuurt de casenummer naar attach@cisco.com en geeft het casenummer in de onderwerpregel voor e-mail op. De procedure is:
Verzamel Cisco CallManager spoorbestanden van 30 minuten voor en 15 minuten na de crash.De locatie van de sporen is C:\Program Files\Cisco\Trace\CCM.
1.
Verzamel SDL spoorbestanden van 30 minuten voor en 15 minuten na de crash.De locatie van de sporen is C:\Program Files\Cisco\Trace\SDL\CCM.
2.
Verzamel de bestanden van user.dmp en drwtsn32.log.De locatie van de bestanden is C:\Documents and Settings\All Users\Documents\DrWatson.
3.
Selecteer Start > Programma's > Beheertools > Event Viewer om de logbestanden van systeemgebeurtenissen en toepassingsgebeurtenissen uit het Event Viewer te verzamelen.U kunt deze stap overslaan als de loggegevens van de gebeurtenis niet nodig zijn. Maar stop het systeem en de toepassingsgebeurtenissen en filter alleen de gebeurtenissen van
ongeveer 30 minuten voor de crash. Onderzoek deze gebeurtenissen voordat u ze naar Cisco Technical Support stuurt. U kunt een gebeurtenis vinden die meer aandacht rechtvaardigt.Voorzichtig: Wees voorzichtig als u het Event Viewer, een ingebouwde
Microsoft voorziening, gebruikt om deze gebeurtenissen in een tekstbestand te dumpen. In een systeem met een hoog CPU-gebruik kan dit gebruik van het eventvenster eenvoudig alle andere processen van de CPU wegslaan. Deze processen omvatten het proces van het Houd van Cisco CallManager dat telefoonregistraties handhaaft.U kunt een hulpprogramma met de naam elogdmp.exe gebruiken om alle items in de afzonderlijke logbestanden naar een tekstbestand te dumpen. De CPU-implicaties zijn verwaarloosbaar wanneer u het gereedschap elogdmp.exe gebruikt. Geef deze opdracht uit een DOS-prompt:
elogdmp COMPUTER_NAME Application > AppEvents.txt elogdmp COMPUTER_NAME System > SysEvents.txt
4.
Comprimeer alle bestanden als zip-bestanden in de volgorde waarin deze stap wordt weergegeven voordat u de bestanden e-mailt en kopieert.Gebruik WinZip versie 8 om de bestanden te comprimeren. (Cisco heeft een sitelicentie voor deze voorziening.) In het algemeen, kopieert bestanden naar een lokale machine voor een snellere evaluatie.
Bestanden die u comprimeert gebruiken minder ruimte, en u kunt deze bestanden veel sneller verplaatsen dan ruwe bestandsindelingen.Comprimeer de bestanden user.dmp en drwtsn32.log.Dit zip-bestand onmiddellijk verzenden en kopiëren. Geef een beschrijvende symptoomdefinitie op en neem de exacte versie van Cisco CallManager, de juiste apparaten en de softwareversies van Cisco IOS® op. Indien u een speciale pleister gebruikt, zorg er dan voor dat u dit duidelijk maakt.Comprimeer de het spoorbestanden van Cisco
CallManager en SDL samen.Verzend en kopieer dit zip-bestand terwijl u op contact wacht.Comprimeer de perfmon.Verzend en kopieer dit zip-bestand terwijl u op contact wacht.Comprimeer de logingangen voor de gebeurtenis samen.Verzend en kopieer dit zip- bestand terwijl u op contact wacht.
5.
Nadat u alle sporen en logbestanden hebt verzameld, comprimeert u de bestanden en stuurt u het zip-bestand naar attach@cisco.com. Geef het casenummer op in de onderwerpregel e- mail.
6.
Gerelateerde informatie
Cisco CallManager-servicecrisis
●
crashes voor probleemoplossing met Cisco CallManager
●
Ondersteuning voor spraaktechnologie
●
Productondersteuning voor spraak en Unified Communications
●
Probleemoplossing voor Cisco IP-telefonie
●
Technische ondersteuning en documentatie – Cisco Systems
●
