Solucionar problemas da ID de Evento DNS 4013 (o servidor DNS não pôde carregar zonas DNS integradas ao AD)

Artigo
03/21/2024

Este artigo resolve a ID do evento 4013 registrada no log de eventos DNS de controladores de domínio que estão hospedando a função de servidor DNS após o início do Windows.

Aplica-se a: Windows Server 2012 R2
Número de KB original: 2001093

Sintomas

Em um computador baseado no Windows que está hospedando controladores de domínio do Active Directory, as funções do servidor DNS param de responder por 15 a 25 minutos. Esse problema ocorre depois que a mensagem Preparando conexões de rede é exibida e antes que o prompt de logon do Windows (Ctrl+Alt+Del) seja exibido.

A seguinte ID de Evento DNS 4013 é registrada no log de eventos DNS de controladores de domínio que estão hospedando a função de servidor DNS após o início do Windows:

Event Type: Warning  
Event Source: DNS  
Event Category: None  
Event ID: 4013  
Date: Date  
Time: Time  
User: N/A  
Computer: ComputerName  
Description:  
The DNS server was unable to open the Active Directory. This DNS server is configured to use directory service information and can not operate without access to the directory. The DNS server will wait for the directory to start. If the DNS server is started but the appropriate event has not been logged, then the DNS server is still waiting for the directory to start.

For more information, see Help and Support Center at https://go.microsoft.com/fwlink/events.asp.  
Data:  
0000: <%status code%>

Nesta entrada de log, os valores de <%Status code%> podem não ser registrados. Ou incluem, mas não se limitam aos seguintes valores:

Hex	Byte	Decimal	Simbólico	Cadeia de Erros
000025f5	f5 25 00 00	9717	DNS_ERROR_DS_UNAVAILABLE	O serviço de diretório não está disponível
0000232d	2d 23 00 00	9005	DNS_ERROR_RCODE_REFUSED	A operação DNS recusou.
0000232a	2a 23 00 00	9002	DNS_ERROR_RCODE_SERVER_FAILURE	Falha no servidor DNS.

Exemplo de cenários de cliente

Vários controladores de domínio em um site do Active Directory que são reinicializados simultaneamente.
- Um domínio de controlador de dois domínios é implantado no mesmo data center.
- A função de servidor DNS é instalada em ambos os controladores de domínio e hospeda cópias integradas ao AD do _msdcs.<domínio> raiz da floresta e zonas de domínio do Active Directory.
- O DC1 está configurado para usar o DC2 para DNS preferencial e a si mesmo para DNS alternativo.
- O DC2 está configurado para usar DC1 para DNS preferencial e para DNS alternativo.
- Todos os controladores de domínio têm UPS (fontes de alimentação ininterruptas) e backups de geradores elétricos.
- O data center enfrenta interrupções frequentes de energia de 2 a 10 horas. Os dispositivos UPS mantêm os controladores de domínio funcionando até que os geradores forneçam energia, mas não podem executar o sistema HVAC. A proteção de temperatura interna em computadores de classe de servidor desliga os controladores de domínio quando as temperaturas internas atingem os limites do fabricante.
- Quando a energia é eventualmente restaurada, os controladores de domínio ficam pendurados por 20 minutos. Esse problema ocorre depois que a preparação de conexões de rede é exibida e antes da exibição do prompt de logon.
- A ID de Evento DNS 4013 está registrada no log de eventos DNS.
Abrindo o DNS console de gerenciamento (DNSMGMT). O MSC) falha e gera a seguinte mensagem de erro:

O nome do> computador do servidor <não pôde ser contatado. O erro foi: o servidor não está disponível. Você gostaria de adicioná-lo de qualquer maneira?

Abrindo o Usuários e Computadores do Active Directory snap-in (DSA). MSC) gera a seguinte mensagem de erro:

As informações de nomenclatura não puderam ser localizadas
Controladores de domínio únicos em um site do Active Directory
- Um controlador de domínio é implantado em um site.
- A função DNS Server está instalada e hospeda cópias integradas ao AD do _msdcs.<domínio> raiz da floresta e zonas de domínio do Active Directory.
- O controlador de domínio aponta para si mesmo para DNS preferencial.
- O controlador de domínio não tem nenhum servidor DNS alternativo especificado ou aponta para um controlador de domínio por meio de um link WAN (rede de ampla área).
- O controlador de domínio é reiniciado devido a uma interrupção de energia.
- Durante a reinicialização, o link wan pode não estar operacional.
- Quando o controlador de domínio é iniciado, ele pode ficar pendurado por 20 minutos. Esse problema ocorre depois que a preparação de conexões de rede é exibida e antes da exibição do prompt de logon.
- A ID de Evento DNS 4013 está registrada no log de eventos DNS.
- Abrindo o DNS console de gerenciamento (DNSMGMT). O MSC) falha e gera a seguinte mensagem de erro:
  
  O nome do> computador do servidor <não pôde ser contatado. O erro foi: o servidor não está disponível. Você gostaria de adicioná-lo de qualquer maneira?
Abrindo o Usuários e Computadores do Active Directory snap-in (DSA). MSC) gera a seguinte mensagem de erro:

Não foi possível localizar informações de nomenclatura.

Motivo

A cópia do Active Directory em alguns controladores de domínio contém referências a outros controladores de domínio na floresta. Esses controladores de domínio tentam replicar todas as partições de diretório realizadas localmente durante a inicialização do Windows, como parte de uma sincronização inicial ou sincronização init.

Na tentativa de inicializar com o conteúdo mais recente da zona DNS, os servidores DNS da Microsoft que hospedam cópias integradas ao AD de zonas DNS atrasam a inicialização do serviço DNS por vários minutos após a inicialização do Windows. O atraso não ocorrerá se o Active Directory tiver concluído sua sincronização inicial durante a inicialização do Windows. Enquanto isso, o Active Directory está atrasado da replicação de partições de diretório de entrada. A replicação é atrasada até que possa resolve o GUID CNAME de seu controlador de domínio de origem para um endereço IP nos servidores DNS usados pelo controlador de domínio de destino para resolução de nomes. A duração da trava durante a preparação de conexões de rede depende do número de partições de diretório localmente mantidas que residem na cópia do Active Directory de um controlador de domínio. A maioria dos controladores de domínio tem pelo menos as cinco partições a seguir:

Esquema
configuração
domínio
Partição de aplicativo DNS em toda a floresta
Partição de aplicativo DNS em todo o domínio

E esses controladores de domínio podem ter um atraso de inicialização de 15 a 20 minutos. A existência de partições extras aumenta o atraso de inicialização.

A ID de Evento DNS 4013 no log de eventos DNS indica que a inicialização do serviço DNS foi atrasada. É porque a replicação de entrada de partições do Active Directory não havia ocorrido.

Várias condições podem exacerbar os seguintes problemas:

inicialização lenta do Windows
o log do evento DNS 4013 em servidores DNS configurados para hospedar zonas integradas ao AD, que residem implicitamente em computadores que atuam como controladores de domínio.

Essas condições incluem:

Configurando um servidor DNS que hospeda zonas DNS integradas ao AD. Sua cópia do Active Directory contém conhecimento de outros controladores de domínio na floresta para apontar exclusivamente para a resolução de nomes DNS.
Configurando um servidor DNS que hospeda zonas DNS integradas ao AD. Sua cópia do Active Directory contém conhecimento de outros controladores de domínio na floresta para apontar servidores DNS que não existem, atualmente estão offline, não estão acessíveis na rede ou que não hospedam as zonas e registros necessários para replicar o Active Directory de entrada. Exemplos incluem o registro GUID CNAME do controlador de domínio e seu registro A ou AAAA correspondente de potenciais controladores de domínio de origem.
Inicializando um controlador de domínio e um servidor DNS que hospeda zonas DNS integradas ao AD. Sua cópia do Active Directory contém conhecimento de outros controladores de domínio sobre o que é efetivamente uma rede isolada porque:
- O adaptador de rede ou a pilha de rede no computador de chamada ou de destino está desabilitado ou não funcional.
- O controlador de domínio foi inicializado em uma rede isolada.
- A cópia do Active Directory do controlador de domínio local contém referências a controladores de domínio obsoletos que não existem mais na rede.
- A cópia do Active Directory do controlador de domínio local contém referências a outros controladores de domínio que estão desativados no momento.
- Há um problema no controlador de domínio de origem, no controlador de domínio de destino ou no DNS ou na infraestrutura de rede. Portanto, a cópia do Active Directory do controlador de domínio local contém referências a outros controladores de domínio que estão online e acessíveis, mas não podem ser replicados com êxito.

No Windows Server 2003 e no Windows 2000 Server SP3 ou posterior, os controladores de domínio que hospedam operações master funções também devem replicar com êxito as alterações de entrada na partição de diretório que mantém as operações master estado da função. A replicação bem-sucedida deve ocorrer antes que as operações dependentes do FSMO possam ser executadas. Essas sincronizações iniciais foram adicionadas para garantir que os controladores de domínio estivessem de acordo com a propriedade da função FSMO e o estado da função. Os requisitos de sincronização iniciais necessários para que as funções FSMO se tornem operacionais é diferente da sincronização inicial discutida neste artigo, em que o Active Directory deve ser replicado para iniciar o serviço do DNS Server imediatamente.

Resolução

Alguns conteúdos da Microsoft e externos recomendaram definir o valor Repl Perform Initial Synchronizations do registro como 0 para ignorar os requisitos iniciais de sincronização no Active Directory. A subchave de registro específica e os valores dessa configuração são os seguintes:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Nome do valor: repl executar sincronizações iniciais
Tipo de valor: REG_DWORD
Dados de valor: 0

Essa alteração de configuração não é recomendada para uso em ambientes de produção ou em qualquer ambiente em uma base contínua. O uso de Repl Perform Initial Synchronizations deve ser usado apenas em situações críticas para resolve problemas temporários e específicos. A configuração padrão deve ser restaurada depois que esses problemas forem resolvidos.

Outras opções viáveis incluem:

Remova referências a controladores de domínio obsoletos.
Deixe os controladores de domínio offline ou não funcionando operacionais.
Os controladores de domínio que hospedam zonas DNS integradas ao AD não devem apontar para um único controlador de domínio e especialmente para si mesmos como DNS preferencial para resolução de nomes.

O registro de nome DNS e a resolução de nomes para controladores de domínio é uma operação relativamente leve que é altamente armazenada em cache por clientes e servidores DNS.

Configurar controladores de domínio para apontar para o endereço IP de um único servidor DNS, incluindo o endereço loopback 127.0.0.1, representa um único ponto de falha. Essa configuração é tolerável em uma floresta com apenas um controlador de domínio, mas não em florestas com vários controladores de domínio.

Os controladores de domínio do hub-site devem apontar para servidores DNS no mesmo site que eles para o servidor DNS preferencial e alternativo e, finalmente, para si mesmos como outro servidor DNS alternativo.

Os controladores de domínio do site do branch devem configurar o endereço IP do servidor DNS preferencial para apontar para um servidor DNS do site do hub, o endereço IP do servidor DNS alternativo para apontar para um servidor DNS no local ou um no site disponível mais próximo e, por fim, para si mesmo usando o endereço de loopback 127.0.0.1 ou o endereço IP estático atual.

Apontar para servidores DNS do site do hub reduz o número de saltos necessários para obter registros críticos do controlador de domínio SRV e HOST totalmente registrados. Os controladores de domínio dentro do site do hub tendem a receber a maior atenção administrativa, normalmente têm a maior coleção de controladores de domínio no mesmo site. Como eles estão no mesmo site, ocorrem alterações entre si:
- a cada 15 segundos no Windows Server 2003 ou posterior
- a cada cinco minutos no Windows 2000 Server
Esse comportamento torna esses registros DNS bem conhecidos.

O controlador de domínio dinâmico SRV e os registros de registro A e AAAA do host podem não sair da caixa se o controlador de domínio de registro em um site de branch não conseguir replicar a saída.

Os computadores e servidores membros devem continuar a apontar para servidores DNS ideais para o site como DNS preferencial. E eles podem apontar para servidores DNS fora do site para tolerância adicional a falhas.

Seu objetivo final é impedir que tudo cause uma negação de serviço ao equilibrar custos, riscos e utilização de rede, como:
- Falhas de latência e replicação de replicação
- falhas de hardware, falhas de software
- práticas operacionais
- interrupções de energia de curto e longo prazo
- incêndio, roubo, inundação e terremotos
- eventos terroristas
Verifique se os controladores de domínio de destino podem resolve controladores de domínio de origem usando DNS (por exemplo, evite fallback).

Você deve garantir que os controladores de domínio possam resolve com êxito os registros CNAME guiados para hospedar registros de controladores de domínio de origem atuais e potenciais. Isso pode evitar a alta latência introduzida pela lógica de fallback de resolução de nomes.

Os controladores de domínio devem apontar para servidores DNS que:
- Estão disponíveis na inicialização do Windows.
- Hospedar, encaminhar ou delegar o _msdcs.<domínio> raiz da floresta e zonas de sufixo DNS primárias para controladores de domínio de origem atuais e potenciais.
- Pode resolve os registros GUID CNAME atuais (por exemplo, dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.com) e registros de host de controladores de domínio de origem atuais e potenciais.
Registros CNAME e host ausentes, duplicados ou obsoletos contribuem para esse problema. A limpeza não está habilitada em servidores DNS da Microsoft por padrão, aumentando a probabilidade de registros de host obsoletos. Ao mesmo tempo, a limpeza de DNS pode ser configurada de forma muito agressiva, fazendo com que registros válidos sejam removidos prematuramente das zonas DNS.
Otimizar controladores de domínio para fallback de resolução de nomes.

A incapacidade de configurar o DNS corretamente para que os controladores de domínio pudessem resolve os registros GUID CNAME do controlador de domínio para hospedar registros no DNS era comum. Para garantir a replicação de ponta a ponta das partições do Active Directory, o Windows Server 2003 SP1 e os controladores de domínio posteriores foram modificados para executar o fallback de resolução de nomes:
- do controlador de domínio CNAME GUID para o nome de host totalmente qualificado.
- de nome de host totalmente qualificado para o nome do computador NetBIOS.
As IDs de evento de replicação do NTDS 2087 e 2088 nos logs de eventos do Serviço de Diretório indicam que:
- um controlador de domínio de destino não pôde resolve o registro GUID CNAME do controlador de domínio para um registro de host.
- o fallback de resolução de nomes está ocorrendo.
Arquivos WINS, HOST e LMHOST podem ser configurados. Portanto, os controladores de domínio de destino podem resolve os nomes dos controladores de domínio de origem atuais e potenciais. Das três soluções, o uso do WINS é mais escalonável, pois o WINS dá suporte a atualizações dinâmicas.

Os endereços e nomes IP para computadores inevitavelmente ficam obsoletos. Esse problema faz com que entradas estáticas nos arquivos HOST e LMHOST se tornem inválidas ao longo do tempo. Quando esse problema ocorre, as consultas para um controlador de domínio podem ser resolvidas incorretamente para outro controlador de domínio. E nenhuma consulta de nome é observada em um rastreamento de rede.
Altere o valor de inicialização do serviço de servidor DNS para manual se inicializar em uma configuração incorreta conhecida.

Se inicializar um controlador de domínio em uma configuração incorreta conhecida discutida neste artigo, siga estas etapas:
1. Defina o valor de inicialização do serviço DNS Server como manual.
2. Reinicialize, aguarde a divulgação do controlador de domínio.
3. Reinicie o serviço DNS Server.
Se o valor de inicialização de serviço do serviço DNS Server for definido como manual, o Active Directory não aguardará o início do serviço DNS Server.

Considerações adicionais

Evite pontos únicos de falha.

Exemplos de pontos únicos de falha incluem:
- Configurando um DC para apontar para um IP de servidor DNS único
- Colocar todos os servidores DNS em máquinas virtuais convidadas no mesmo computador host físico
- Colocar todos os servidores DNS no mesmo site físico
- Limitar a conectividade de rede de modo que os controladores de domínio de destino tenham apenas um único caminho de rede para acessar um servidor KDC ou DNS
Instale servidores DNS suficientes para o desempenho de redundância local, regional e empresarial, mas não tantos que o gerenciamento se torne um fardo. O DNS normalmente é uma operação leve que é altamente armazenada em cache por clientes DNS e servidores DNS.

Cada servidor DNS da Microsoft em execução em hardware moderno pode atender a 10.000 a 20.000 clientes por servidor. Instalar a função DNS em cada controlador de domínio pode levar a um número excessivo de servidores DNS em sua empresa. E fazer isso aumentará o custo.
Escalone as reinicializações de servidores DNS em sua empresa quando possível.
- A instalação de alguns hotfixes, service packs e aplicativos pode exigir uma reinicialização.
- Alguns clientes reinicializam os controladores de domínio em uma base agendada (a cada sete dias, a cada 30 dias).
- Agendar reinicializações e a instalação do software que requer uma reinicialização, de maneira inteligente. Fazer isso para impedir que o único servidor DNS ou potencial parceiro de replicação de origem que um controlador de domínio de destino aponte para a resolução de nomes, seja reiniciado ao mesmo tempo.
Se Windows Update ou software de gerenciamento estiver instalando um software que requer reinicialização, escalone as instalações em controladores de domínio direcionados para que metade dos servidores DNS disponíveis que os controladores de domínio apontem para a reinicialização da resolução de nomes ao mesmo tempo.
Instale dispositivos UPS em locais estratégicos para garantir a disponibilidade de DNS durante interrupções de energia de curto prazo.
Aumente seus servidores DNS com backup do UPS com geradores no local.

Para lidar com interrupções prolongadas, alguns clientes implantaram geradores elétricos no local para manter os principais servidores online. Alguns clientes descobriram que os geradores podem alimentar servidores no data center, mas não no HVAC no local. A falta de ar condicionado pode fazer com que os servidores locais sejam desligados quando as temperaturas internas do computador atingem um determinado limite.

Mais informações

Teste de 10 de maio de 2010 pela equipe de desenvolvimento do Active Directory:

O DNS aguarda o NTDS e não pode ser iniciado até que a replicação inicial do diretório seja concluída. Isso ocorre porque os dados DNS atualizados podem não ser replicados no controlador de domínio ainda. Por outro lado, o NTDS precisa de DNS para resolve o endereço IP do controlador de domínio de origem para a replicação. Suponha que o DC1 aponte para DC2 como seu servidor DNS e DC2 aponta para DC1 como seu servidor DNS. Quando DC1 e DC2 forem reiniciados simultaneamente, haverá uma inicialização lenta devido a essa dependência mútua. A causa raiz dessa inicialização lenta é DNSQueryTimeouts.

Se o serviço DNS Server for executado bem quando o NTDS for iniciado, o NTDS levará apenas duas consultas DNS para resolve o endereço IP do controlador de domínio de origem:

um para IPv4
o outro para IPv6

E essas consultas DNS retornam quase instantaneamente.

Se o serviço DNS Server não estiver disponível quando o NTDS for iniciado, o NTDS precisará enviar 10 consultas DNS para resolve o endereço IP:

quatro para nome baseado em GUID
quatro para nome totalmente qualificado
dois para nome de rótulo único

A latência para cada consulta DNS é controlada por DNSQueryTimeouts. Por padrão, DNSQueryTimeouts é definido como 1 1 2 4 4. Isso significa que o cliente DNS aguardará 12 (1 + 1 + 2 + 4 + 4) segundos para a resposta do servidor DNS. Cada fonte de contexto de nomenclatura leva 120 segundos para resolve o endereço IP. Suponha que haja cinco contextos de nomenclatura (Configuration, Schema, domain, ForestDnsZones, DomainDnsZones) e uma única fonte de replicação. Nesse cenário, levará 850 (170 X 5) segundos ou mais de 14 minutos para o NTDS concluir a replicação inicial.

Vários testes foram feitos para validar o comportamento acima.

Reinicialize o controlador de domínio quando o servidor DNS é um terceiro controlador de domínio que está online. Para cada contexto de nomenclatura de cada fonte, temos duas consultas DNS e elas terminaram quase instantaneamente:

in I_DRSGetNCChanges, NC = CN=Configuration,DC=contoso,DC=com
in getContextBindingHelper, pszAddress = dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.com  
in resolveDnsAddressWithFallback  
GUID based DNS name  
in GetIpVxAddrByDnsNameW  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 22:31:40.534  
end   GetAddrInfoW: 22:31:40.534  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 22:31:40.534  
end   GetAddrInfoW: 22:31:40.534

Reinicialize DC1 e DC2 simultaneamente. DC1 está usando DC2 para DNS DC2 está usando DC1 para DNS. Para cada contexto de nomenclatura de cada fonte, temos 10 consultas DNS e cada consulta leva cerca de 12 segundos:

in I_DRSGetNCChanges, NC = CN=Configuration,DC=contoso,DC=com  
in getContextBindingHelper, pszAddress = dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.microsoft.com  
in resolveDnsAddressWithFallback  
GUID based DNS name  
in GetIpVxAddrByDnsNameW  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 22:37:43.066  
end   GetAddrInfoW: 22:37:55.113  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 22:37:55.113  
end   GetAddrInfoW: 22:38:07.131  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 22:38:07.131  
end   GetAddrInfoW: 22:38:19.161  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 22:38:19.176  
 end   GetAddrInfoW: 22:38:31.185  
FQDN  
in GetIpVxAddrByDnsNameW  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 22:38:31.200  
end   GetAddrInfoW: 22:38:43.182  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 22:38:43.182  
end   GetAddrInfoW: 22:38:55.191  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 22:38:55.191  
end   GetAddrInfoW: 22:39:07.216  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 22:39:07.216  
end   GetAddrInfoW: 22:39:19.286  
NetBios  
in GetIpVxAddrByDnsNameW  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 22:39:19.286  
end   GetAddrInfoW: 22:39:31.308d  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 22:39:31.308  
end   GetAddrInfoW: 22:39:43.324

Para estudar ainda mais a relação entre dNSQueryTimeouts e a inicialização lenta, os DNSQueryTimeouts foram definidos como 1 1 2 4 4 para fazer o cliente DNS esperar por 31 (1 + 1 + 2 + 4 + 4) segundos. Neste teste, foram gastos 31 segundos esperando:

in I_DRSGetNCChanges, NC = CN=Configuration,DC=contoso,DC=com  
in getContextBindingHelper, pszAddress = dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.com  
in resolveDnsAddressWithFallback  
GUID based DNS name  
in GetIpVxAddrByDnsNameW  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 18:06:48.143  
end   GetAddrInfoW: 18:07:19.158  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 18:07:19.158  
end   GetAddrInfoW: 18:07:50.162  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 18:07:50.162  
end   GetAddrInfoW: 18:08:21.161  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 18:08:21.161  
end   GetAddrInfoW: 18:08:52.158  
FQDN  
in GetIpVxAddrByDnsNameW  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 18:08:52.221  
end   GetAddrInfoW: 18:09:23.231  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 18:09:23.231  
end   GetAddrInfoW: 18:09:54.243  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 18:09:54.243  
end   GetAddrInfoW: 18:10:25.239  
 in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 18:10:25.239  
end   GetAddrInfoW: 18:10:56.243  
NetBios  
in GetIpVxAddrByDnsNameW  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 18:10:56.243  
end   GetAddrInfoW: 18:11:27.244  
in GetIpAddrByDnsNameHelper  
start GetAddrInfoW: 18:11:27.244  
end   GetAddrInfoW: 18:11:58.265