线索css加载失败

如何识别CiscoCallManager重新启动作为失败或服务关闭目录简介先决条件要求使用的组件规则在CiscoCallManager故障和关闭之间的区别故障关闭如何报告CiscoCallManager故障到思科技术支持相关信息简介本文描述在CiscoCallManager失败和服务关闭之间的区别.
本文也提供步骤报告CiscoCallManager失败和使思科技术支持排除故障问题.
先决条件要求本文档没有任何特定的要求.
使用的组件本文档中的信息基于以下软件版本:CiscoCallManager3.
x和4.
0q本文档中的信息都是基于特定实验室环境中的设备编写的.
本文档中使用的所有设备最初均采用原始(默认)配置.
如果您使用的是真实网络,请确保您已经了解所有命令的潜在影响.
规则有关文档规则的详细信息,请参阅Cisco技术提示规则.
在CiscoCallManager故障和关闭之间的区别故障在CiscoCallManager代码的一bug引起CallManager失败.
有失败三种主要类型:访问违例q除零q未知例外q故障生成Dr.
Watson条目,被添附对现有Dr.
Watson文件的末端.
故障也生成user.
dmp文件.
这些文件的位置是C:\DocumentsandSettings\All用户\文档\DrWatson.
Dr.
Watson文件的名称,是文本文件,是drwtsn32.
log.
从Run窗口选择drwtsn32配置设置.
如何读Dr.
Watson文件完成这些步骤读Dr.
Watson文件:搜索词"当",用小写,并且查找问题发生的日期和时间.
Dr.
Watson文件记录所有应用程序失败.
一些坠毁记录可能不是CiscoCallManager失败.
的坠毁记录示例不是CiscoCallManager失败包括RisDC.
exe和aupair.
exe.
1.
在您找出问题的日期和时间后,请找出进程标识符(PID)编号,并且搜索任务列表确定哪应用程序失败了.
任务列表在此步骤的示例发表.
在本例中,失败的应用程序有PID752和应用程序的名称是SCAN32.
exe:Applicationexceptionoccurred:App:(pid=752)When:9/1/2000@10:23:40.
836Exceptionnumber:c0000005(accessviolation)SystemInformationTaskList77fcb9b3894804mov[eax+0x4],ecxds:014cbdfe=ec810000!
---Thisistheassemblycodestatementthatresultedinthecrash.
77fcb9b6744djz77fd440577fcb9b88a4705moval,[edi+0x5]ds:34eb5aaa=8177fcb9bba804testal,0x477fcb9bd0f8521310000jneRtlZeroHeap+0x3e3(77fceae4)77fcb9c38a4605moval,[esi+0x5]ds:34eb5f42=d577fcb9c62410andal,0x1077fcb9c8a810testal,0x1077fcb9ca884705mov[edi+0x5],alds:34eb5aaa=8177fcb9cd0f8555030000jneRtlSizeHeap+0x3ef(77fcbd28)77fcb9d30fb70fmovzxecx,wordptr[edi]ds:346984d8=009377fcb9d68b4510moveax,[ebp+0x10]ss:0650c92a=StackBackTraceThisshows,inorder,theaddressesofthefunctionsthatexecuted!
---justbeforethecrash.
FramePtrReturnAdParam#1Param#2Param#3Param#4FunctionName05CEF35877FCB733020700003469897005CEF3D000000000ntdll!
RtlSizeHeap05CEF4007800115C02070000000000003469897805CEF454ntdll!
RtlFreeHeap05CEF44800C0304F3469897800545EC23469897834698978!
free05CEF46000B66F850000000100B6626C033B3D58025A6720!
05CEFF34018E736B025A672077E964CB033C6B20033C6B20!
05CEFF80780060CE033B3D5877E964CB00000018033C6B20!
ACE_OS_Thread_Adapter::invoke05CEFFEC0000000000000000000000000000000000000000kernel32!
TlsSetValue*---->RawStackDumpPrograms>AdministrativeTools>Component服务.
1.
展开组件服务>计算机>我的电脑>COM+应用程序.
2.
开始MSDTC(分布式处理协调员)服务,如果它显示终止.
3.
关闭其他种CiscoCallManager重新启动是关闭.
关闭是,当CiscoCallManager无法有效运行并且关闭自己时.
关闭归入两个类别:初始化超时qSDL计时器和SDL路由器线索死亡q如果CiscoCallManager关闭自己,您查找在Callmanager跟踪的最后几种跟踪线路的关闭.
示例如下:03/22/200314:32:16.
562CiscoCallManager|CallManagerFailure-IndicatessomefailureintheCiscoCallManagersystem.
Hostnameofhostingnode.
:NEROCM1IPaddressofhostingnode.
:172.
27.
27.
224Reasoncode.
:4AdditionalText[Optional]:AppID:CiscoCallManagerClusterID:NEROCM1-ClusterNodeID:172.
27.
27.
224|在本例中,原因代码是4此列表提供从CiscoCallManager代码的关闭原因代码:classCallManagerFailureAlarm:publicCallManagerAlarmCatalog{public:enumReason{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与初始化计时器火关连.
初始化超时当CiscoCallManager服务首先开始时,CallManager进程箴言报(CMProcMon)线索开始.
然后,MmmanInit线索开始,产生所有其他进程.
其次,SDL路由器线索开始.
此线索处理从一进程发送到另一个的信号.
全部三线索同时开始.
当MmmanInit线索开始其他进程时,CMProcMon线索和SDL路由器线索启用并且运行.
当MmmanInit开始多种进程时,CMProcmon和SDL需要是正在运行的.
MmmanInit线索开始这些进程,按此顺序:数据库(ProcessDb)注意:ProcessDb是CiscoCallManager接口对DatabaseLayer(DBL)代码.
同时,MmmanInit代码也启动内部一定数量的其他的CiscoCallManager,独立进程.
这些进程包括H225Handler、MGCPBhHandler和部门经理.
1.
地区2.
AARNeighborhood3.
位置4.
路由计划5.
数字分析6.
呼叫控制7.
附加服务功能包括呼叫暂留、转发、会议和转移.
8.
设备9.
目录10.
呼叫搜索空间管理器(CSSManager)11.
每日定时管理器(TODManager)12.
这些任务的成就发生系列.
每一个十二任务有与任务产生关联的一个计时器.
当任务开始,此计时器启动.
如果计时器火,在读的任务完成前,CiscoCallManager终止并且打印SDLtrace:Criticalthreaddeath:nameofthetimerwhichfired此列表显示其中每一个计时器,以及开始计时器和SDL信号终止计时器的SDL信号.
如果适当,设置跟踪级别"InitDone"信号在SDLtrace出现.
(您在0x8000CB15的集Sdltracetypeflag.
)这些默认计时器根据CiscoCallManager版本4.
1(2).
如果运行另外版本,也许是有些不同的.
数据库初始化时间(默认为900秒)-此时间的起动信号是"启动"信号被发送对MmmanInit进程.
您在SDLtrace看到此.
1.
地区初始化时间(默认为120秒).
2.
AARNeighborhoods初始化时间(默认为90秒).
3.
位置初始化时间(默认为90秒).
4.
路由计划初始化时间(默认为600秒).
5.
数字分析初始化时间(默认为900秒).
6.
呼叫控制初始化时间(默认为90秒).
7.
附加服务初始化时间(默认为900秒)-起动信号是CcInitDone,并且末端信号是SsInitDone.
8.
设备初始化时间(默认为360秒).
9.
目录初始化时间(默认为90秒)10.
CSSManager初始化时间(默认为900秒).
11.
定期TODManager的初始化(默认为900秒).
12.
在所有任务完成后,CiscoCallManager打开SDL链路对在网络的其他节点运作的CallManager服务.
CiscoCallManager也打开SDL链路对计算机电话集成(CTI)在同一节点或另外节点运作在网络的管理器服务.
然后,MmmanInit发送CMInitComplete信号回到CMProcMon线索.
当CMProcMon首先开始时,启动CiscoCallManager初始化的一个60分钟硬编码的计时器.
计时器有命名CMInitComplete_WaitTime.
(此计时器不是服务参数;计时器不可配置.
)如果CMProcMon线索在60分钟内不收到CMInitComplete信号,CiscoCallManager终止并且发表读的跟踪语句:TimedoutwaitingforCMInitCompletesignal如果任何一个十二项初始化任务发生故障,或者,如果这些任务的总时间超出60分钟,CiscoCallManager终止.
注意:CMInitComplete_WaitTime计时器曾经是硬编码对10分钟.
作为CiscoBugIDCSCdx31622(仅限注册用户)一部分,此hardcode更改对60分钟.
更改进入3.
1(3)EngineeringSpecial(ES)系列,有ES的38作为开始.
更改也在3.
2(2)ES系列,与ES11作为开始和在CiscoCallManager3.
3.
如果遇到与初始化计时器火的问题,您也许只需要增加计时器设置解决启动.
如果此更改不解决问题,问题可以是一个缓慢的数据库响应时间造成操作计时.
collect选派了DBL跟踪、以及SDL和CiscoCallManager跟踪,如果需要.
收集这些文件调试初始化问题:详细的CiscoCallManager跟踪qSDLtrace注意:设置Sdltracetypeflag为0x8000CB15.
q详细的DBLtraceqSDL计时器和SDL路由器线索死亡SDL路由器线索是执行最重要的线索在CiscoCallManager应用程序里面.
它控制呼叫处理信号发送.
CMProcMon线索一次检查SDL路由器线索的健康每两秒.
正如你在这些语句,看到CiscoCallManager跟踪显示此健康检查:02/05/200300:30:32.
790CiscoCallManager|CMProcMon-------EnteredRouterVerification|02/05/200300:30:32.
790CiscoCallManager|CMProcMon-----ExitedRouterVerification|如果CMProcMon线索输入并且退出路由器验证,SDL路由器线索响应对健康检查和优良是.
然而,如果SDL路由器线索不响应,您看到,在CiscoCallManager跟踪的,作为此显示时:CMProcMon-----EnteredWhileloop++++TimeAtWhileEntry:[somenumberhere],TimeBeforeSleep:[anothernumber],TimeAfterSleep:[athirdnumber],sleepTimeWas:[4thnumber"在此紧急,SDL路由器线索一次接收检查每秒钟期限20秒.
在20第二个期限,如果线索在任何时间响应,正常操作恢复,并且SDL路由器线索的健康再次接收验证每2秒.
如果,然而,SDL路由器线索不响应对检查在20秒期间,CiscoCallManager应用程序关闭了.
此语句在SDLtrace出现:000177508|01/12/3107:28:40.
389|001|AlarmErr||||||AlarmClass:CallManager,AlarmName:CallManagerFailure,AlarmSeverity:ErrorAlarmMessage:,AlarmDescription:IndicatessomefailureintheCiscoCallManagersystem.
,AlarmParameters:HostName:CCM-PUB,IPAddress:10.
5.
162.
180,Reason:3,Text:,AppID:CiscoCallManager,ClusterID:CCM-PUB-Cluster,NodeID:10.
5.
162.
180,注意在此跟踪语句文本的原因代码3.
代码意味着SDL路由器线索终止了答复,因此CiscoCallManager关闭了.
SDL路由器线索关闭的最可能原因是缺乏系统资源.
另一应用程序长期以来使用了多数或所有CPU时间,至少20秒.
此活动是性能监控程序为什么是重要调试此种关闭.
测试的其他种关闭是SDL计时器线索关闭.
当在内部CiscoCallManager时钟和外部操作系统的时钟之间的差别超出16秒,SDL计时器线索关闭发生.
当SDL计时器线索关闭发生时,此trace在CiscoCallManager跟踪出现:03/22/200314:32:16.
562CiscoCallManager|CallManagerFailure-IndicatessomefailureintheCiscoCallManagersystem.
Hostnameofhostingnode.
:NEROCM1IPaddressofhostingnode.
:172.
27.
27.
224Reasoncode.
:4AdditionalText[Optional]:AppID:CiscoCallManagerClusterID:NEROCM1-ClusterNodeID:172.
27.
27.
224|CiscoCallManager一次通常检查计时器线索每秒钟.
重视离开作为"期望时间的CiscoCallManager添加1秒到当前操作系统的时间和存储".
然后,1秒的CiscoCallManager睡眠.
在CiscoCallManager醒后,检查新的操作系统的时间并且减去期望时间.
如果这两时间之间的差异是超过1秒,此警告语句在CiscoCallManager跟踪出现:CMProcMon::star_sdlVerification-TestTimerexceededminimumtimerlatencythresholdof1000milliseconds,Actuallatency:1630milliseconds在此语句的显示内部CiscoCallManagerSDL计时器线索运行减慢.
这里,在CiscoCallManager期望时间和实际操作系统的时间之间的区别是1.
63秒.
如果此差异超出16秒,CiscoCallManager关闭并且提供关闭原因代码4SDL计时器线索关闭的最可能原因是缺乏CiscoCallManager的CPU时间.
另一应用程序,例如VirusScan或STI备份,使用了大多CPU资源至少16秒.
Perfmon日志是重要确定此种关闭的根本原因.
如果CiscoIP电话应用程序备份长期以来运行时间在高CPU利用率,系统崩溃能出现.
关于如何避免此系统崩溃的信息,参考:检查在备份工具的设置避免本文CiscoCallManager服务崩溃的高CPU部分q收集这些文件一旦SDL路由器线索或SDL计时器线索关闭了:详细的CiscoCallManager跟踪qSDLtrace注意:设置Sdltracetypeflag为0x8000CB15.
q若有,Perfmon跟踪显示所有进程CPU利用率百分比在方框运行注意:您能远程捕获这些跟踪减少在CiscoCallManager服务器的CPU的性能影响.
q如何报告CiscoCallManager故障到思科技术支持CiscoCallManager事故的实际原因的诊断是困难.
为了确定原因和加快解决方案,思科技术支持要求您收集跟踪和Dr.
Watson日志和上传信息到思科技术支持案例笔记.
您发送案例注释对attach@cisco.
com并且提供在电子邮件标题栏的案例编号.
步骤为:从30分钟和以前15分钟的收集的CiscoCallManager跟踪文件在失败以后.
跟踪的位置是C:\ProgramFiles\Cisco\Trace\CCM.
1.
从30分钟和以前15分钟的收集的SDL跟踪文件在失败以后.
跟踪的位置是C:\ProgramFiles\Cisco\Trace\SDL\CCM.
2.
收集user.
dmp和drwtsn32.
log文件.
文件的位置是C:\DocumentsandSettings\All用户\文档\DrWatson.
3.
选择Start>Programs>AdministrativeTools>EventViewer搜集从事件查看器的系统和应用事件日志日志文件.
如果事件日志数据不是必要的,您能跳到此步骤.
但是,请转存系统和应用程序事件并且在失败前过滤从大约30分钟的仅事件.
在您发送他们对思科技术支持前,请调查这些事件.
您能找到值得更多注意的事件.
警告:小心,如果使用事件查看器,一内置的Microsoft程序,转存这些事件到文本文件.
在有高CPU利用率的系统中,此使用事件查看器能容易地使从CPU的其他进程挨饿.
这些进程包括维护电话注册的CiscoCallManagerKeepalive进程.
您在各自的日志能以名称elogdmp.
exe使用共享件工具转存所有条目到文本文件.
当您使用elogdmp.
exe工具时,CPU暗示是微不足道的.
发出从DOS提示符的此命令:elogdmpCOMPUTER_NAMEApplication>AppEvents.
txtelogdmpCOMPUTER_NAMESystem>SysEvents.
txt4.
压缩所有文件作为压缩文件按此步骤显示,在您电子邮件并且复制文件前的顺序.
请使用Winzip版本8压缩文件.
(思科有此工具的一个站点许可证.
)一般来说,对一个本地设备的文件副本更加快速的评估的.
您压缩使用较少空间的文件和您比原始文件格式能快速移动这些文件.
一起压缩user.
dmp和drwtsn32.
log文件.
立即请发送并且复制此压缩文件.
提供一个说明性症状定义并且包括确切的CiscoCallManager版本、适当的设备加载和CiscoIOS软件版本.
如果任何特殊补丁程序是在使用中的,请保证您做此事实结算.
一起压缩Cisco5.
CallManager和SDL跟踪文件.
当您等待联系方式时,请发送并且复制此压缩文件.
一起压缩perfmon日志.
当您等待联系方式时,请发送并且复制此压缩文件.
一起压缩事件日志条目.
当您等待联系方式时,请发送并且复制此压缩文件.
在您采集了所有跟踪和日志后,请压缩文件并且发送压缩文件对attach@cisco.
com.
提供在电子邮件标题栏的案例编号.
6.
相关信息CiscoCallManager服务崩溃q排除CiscoCallManager崩溃故障q语音技术支持q语音和统一通信产品支持qCiscoIP电话故障排除q技术支持和文档-CiscoSystemsq