Introdução
Este documento descreve um problema encontrado quando o processo do windump está usado com o discador de partida do Cisco Unified Contact Center Enterprise (UCCE).
Pré-requisitos
Requisitos
A Cisco recomenda que você tenha conhecimento destes tópicos:
- Cisco UCCE
- Session Initiation Protocol (SIP) da liberação 8.x de Cisco UCCE ou discador do protocolo skinny client control (SCCP)
A informação neste documento é baseada no discador de partida do Cisco Unified Contact Center Enterprise (UCCE).
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.
Problema
Quando os logs de partida do processo do discador são vistos, você observa que o processo do windump causa um crash cada 15 segundos:
-------------
13:00:12:615 dialer-baDialer Trace: WinDump process has crashed, restarting...
13:00:12:617 dialer-baDialer Trace: CreateProcess succeeded with szCmdline = windump -I 1
-tt -C 20 -s 0 -W 20 -w DialerCapture udp port 58800
dwProcessId= 262600 hProcess = 256784
13:00:28:843 dialer-baDialer Trace: WinDump process has crashed, restarting...
13:00:28:844 dialer-baDialer Trace: CreateProcess succeeded with szCmdline = windump -I 1
-tt -C 20 -s 0 -W 20 -w DialerCapture udp port 58800
dwProcessId= 262412 hProcess = 256792
13:00:45:069 dialer-baDialer Trace: WinDump process has crashed, restarting...
-------------
Quando o windump causa um crash repetidamente, conduz a uma situação do escape de memória que resultados em um impacto de partida do serviço do discador.
Solução
Há um par encenações que puderam conduzir a este problema:
- A chave de registro de partida do discador das opções da captação não é ajustada corretamente. Navegue a \ HKEY_LOCAL_MACHINE \ SOFTWARE \ Cisco Systems, Inc. \ > exemplo ICM \ <Customer \ discador e certifique-se de que a chave de registro das opções da captação está ajustada - i 1 - ao tt - o C 20 - S0 - W 20 - w DialerCapture.
Em algumas situações, a chave de registro é ajustada - I1 - ao tt - o C 20 - S0 - W 20 - w DialerCapture, que conduz a um impacto. Isto é visto frequentemente quando o discador de partida é promovido de uma versão anterior. Para mais detalhes, refira a identificação de bug Cisco CSCuh16754 (o processo do windump causa um crash no discador).
- O software de Wireshark pôde afetar os arquivos de biblioteca dinamicamente ligados capturados (DLL). Se Wireshark é instalado no server a fim pesquisar defeitos, e desinstalado mais tarde, a remoção do WinPcap pelo desinstalar pode conduzir a este problema. O processo do desinstalar de Wireshark remove os DLL capturados wpcap.dll e packet.dll, que o windump exige.
A fim confirmar que os arquivos necessários estam presente e que o windump trabalha corretamente, termine estas etapas:
- Certifique-se que os wpcap.dll e os Packet.dllfiles estam presente nestes lugar:
- C:\Windows\SysWOW64
- C:\Windows\System32
Se os arquivos DLL não são encontrados, contacte o centro de assistência técnica da Cisco (TAC) a fim obter as versões apropriadas dos arquivos DLL.
- A fim confirmar que o processo do windump corretamente está instalado e captura dados corretamente, examine a saída destes comandos:
C:\>windump -V
windump version 3.9.5, based on tcpdump version 3.9.5
WinPcap version 4.1.2 (packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch
1_0_rel0b (20091008)
C:\>windump
windump: listening on \Device\NPF_{5A01EA28-AF57-4456-A653-DD785A20853F}
13:06:20.596189 IP PG2B.43005 > PG2A.domain.net.49220: .3075400616:3075400617(1) ack 1040704317 win
13:06:20.596222 IP PG2A.domain.net.49220 > PG2B.43005: .ack 1 win 255 <nop,nop,sack 1 {0:1}>
13:06:20.606477 IP PG2A.domain.net.49208 > PG2B.45005: .1242670277:1242670278(1) ack 357439054 win 2
13:06:20.607219 IP PG2B.45005 > PG2A.domain.net.49208: .0:1(1) ack 1 win 251
Feedback