Risolvere i problemi relativi all'ID evento DNS 4013 (il server DNS non è stato in grado di caricare le zone DNS integrate con ACTIVE Directory)

Questo articolo risolve l'ID evento 4013 registrato nel registro eventi DNS dei controller di dominio che ospitano il ruolo del server DNS dopo l'avvio di Windows.

Si applica a: Windows Server 2012 R2
Numero KB originale: 2001093

Sintomi

  • In un computer basato su Windows che ospita controller di dominio Active Directory, i ruoli del server DNS smette di rispondere per 15-25 minuti. Questo problema si verifica dopo la visualizzazione del messaggio Preparazione delle connessioni di rete e prima della visualizzazione del prompt di accesso di Windows (CTRL+ALT+CANC).

  • L'ID evento DNS 4013 seguente viene registrato nel registro eventi DNS dei controller di dominio che ospitano il ruolo del server DNS dopo l'avvio di 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%>
    

    In questa voce di log i valori di <%Status code%> potrebbero non essere registrati. In alternativa, includono, ma non sono limitati ai valori seguenti:

    Hex Byte Decimale Simbolico Stringa di errore
    000025f5 f5 25 00 00 9717 DNS_ERROR_DS_UNAVAILABLE Il servizio directory non è disponibile
    0000232d 2d 23 00 00 9005 DNS_ERROR_RCODE_REFUSED Operazione DNS rifiutata.
    0000232a 2a 23 00 00 9002 DNS_ERROR_RCODE_SERVER_FAILURE Errore del server DNS.

Scenari di esempio per i clienti

  • Più controller di dominio in un sito di Active Directory che vengono riavviati contemporaneamente.

    • Nello stesso data center viene distribuito un dominio controller di due domini.
    • Il ruolo del server DNS viene installato in entrambi i controller di dominio e ospita copie integrate di AD del _msdcs.<dominio radice> della foresta e zone di dominio Active Directory.
    • DC1 è configurato per l'uso di DC2 per dns preferito e se stesso per DNS alternativo.
    • DC2 è configurato per l'uso di DC1 per dns preferito e se stesso per DNS alternativo.
    • Tutti i controller di dominio dispongono di alimentatori non ininterrutti (UPS) e di backup del generatore elettrico.
    • Il data center riscontra frequenti interruzioni dell'alimentazione da 2 a 10 ore. I dispositivi UPS mantengono operativi i controller di dominio fino a quando i generatori non forniscono energia, ma non possono eseguire il sistema HVAC. La protezione della temperatura integrata nei computer della classe server arresta i controller di dominio quando le temperature interne raggiungono i limiti del produttore.
    • Quando l'alimentazione viene ripristinata, i controller di dominio si bloccano per 20 minuti. Questo problema si verifica dopo la visualizzazione della preparazione delle connessioni di rete e prima della visualizzazione del prompt di accesso.
    • L'ID evento DNS 4013 viene registrato nel registro eventi DNS.

    Apertura della console di gestione DNS (DNSMGMT. MSC) ha esito negativo e genera il messaggio di errore seguente:

    Impossibile contattare il nome computer> del server<. Errore: il server non è disponibile. Vuoi aggiungerlo comunque?

    Apertura dello snap-in Utenti e computer di Active Directory (DSA. MSC) genera il messaggio di errore seguente:

    Impossibile individuare le informazioni di denominazione

  • Controller di dominio singolo in un sito di Active Directory

    • Un controller di dominio viene distribuito in un sito.

    • Il ruolo Server DNS viene installato e ospita copie integrate di AD del _msdcs.<dominio radice> della foresta e zone di dominio Active Directory.

    • Il controller di dominio punta a se stesso per il DNS preferito.

    • Il controller di dominio non ha un server DNS alternativo specificato o punta a un controller di dominio tramite un collegamento WAN (Wide Area Network).

    • Il controller di dominio viene riavviato a causa di un'interruzione dell'alimentazione.

    • Durante il riavvio, il collegamento WAN potrebbe non essere operativo.

    • Quando il controller di dominio viene avviato, può bloccarsi per 20 minuti. Questo problema si verifica dopo la visualizzazione della preparazione delle connessioni di rete e prima della visualizzazione del prompt di accesso.

    • L'ID evento DNS 4013 viene registrato nel registro eventi DNS.

    • Apertura della console di gestione DNS (DNSMGMT. MSC) ha esito negativo e genera il messaggio di errore seguente:

      Impossibile contattare il nome computer> del server<. Errore: il server non è disponibile. Vuoi aggiungerlo comunque?

    Apertura dello snap-in Utenti e computer di Active Directory (DSA. MSC) genera il messaggio di errore seguente:

    Impossibile individuare le informazioni di denominazione.

Causa

La copia di Active Directory in alcuni controller di dominio contiene riferimenti ad altri controller di dominio nella foresta. Questi controller di dominio provano a replicare in ingresso tutte le partizioni di directory in locale durante l'avvio di Windows, come parte di una sincronizzazione iniziale o di una sincronizzazione init.

Nel tentativo di avvio con il contenuto della zona DNS più recente, i server DNS Microsoft che ospitano copie integrate di AD delle zone DNS ritardano l'avvio del servizio DNS per alcuni minuti dopo l'avvio di Windows. Il ritardo non si verificherà se Active Directory ha completato la sincronizzazione iniziale durante l'avvio di Windows. Nel frattempo, Active Directory è in ritardo a causa della replica in ingresso delle partizioni di directory. La replica viene ritardata fino a quando non è in grado di risolvere il GUID CNAME del controller di dominio di origine in un indirizzo IP nei server DNS usati dal controller di dominio di destinazione per la risoluzione dei nomi. La durata del blocco durante la preparazione delle connessioni di rete dipende dal numero di partizioni di directory contenute in locale che si trovano nella copia di Active Directory di un controller di dominio. La maggior parte dei controller di dominio dispone di almeno le cinque partizioni seguenti:

  • Schema
  • Configurazione
  • dominio
  • Partizione dell'applicazione DNS a livello di foresta
  • Partizione dell'applicazione DNS a livello di dominio

E questi controller di dominio possono riscontrare un ritardo di avvio di 15-20 minuti. L'esistenza di partizioni aggiuntive aumenta il ritardo di avvio.

L'ID evento DNS 4013 nel registro eventi DNS indica che l'avvio del servizio DNS è stato ritardato. Perché la replica in ingresso delle partizioni di Active Directory non si era verificata.

Più condizioni possono esacerbare i problemi seguenti:

  • avvio lento di Windows
  • la registrazione dell'evento DNS 4013 nei server DNS configurati per ospitare le zone integrate di AD, che risiedono implicitamente nei computer che fungono da controller di dominio.

Queste condizioni includono:

  • Configurazione di un server DNS che ospita zone DNS integrate in ACTIVE Directory. La copia di Active Directory contiene informazioni su altri controller di dominio nella foresta per puntare a se stessa esclusivamente per la risoluzione dei nomi DNS.
  • Configurazione di un server DNS che ospita zone DNS integrate in ACTIVE Directory. La copia di Active Directory contiene informazioni su altri controller di dominio nella foresta in modo che puntino a server DNS che non esistono, sono attualmente offline, non sono accessibili in rete o che non ospitano le zone e i record necessari necessari per la replica in ingresso di Active Directory. Gli esempi includono il record GUID CNAME del controller di dominio e il record A o AAAA host corrispondente di potenziali controller di dominio di origine.
  • Avvio di un controller di dominio e di un server DNS che ospitano zone DNS integrate in Active Directory. La sua copia di Active Directory contiene la conoscenza di altri controller di dominio su ciò che è effettivamente una rete isolata perché:
    • La scheda di rete o lo stack di rete nel chiamante o nel computer di destinazione è disabilitato o non funzionale.
    • Il controller di dominio è stato avviato in una rete isolata.
    • La copia di Active Directory del controller di dominio locale contiene riferimenti a controller di dominio non aggiornati che non esistono più nella rete.
    • La copia di Active Directory del controller di dominio locale contiene riferimenti ad altri controller di dominio attualmente disattivati.
    • Si è verificato un problema nel controller di dominio di origine, nel controller di dominio di destinazione o nell'infrastruttura DNS o di rete. La copia di Active Directory del controller di dominio locale contiene quindi riferimenti ad altri controller di dominio online e accessibili da cui non è possibile eseguire correttamente la replica.

In Windows Server 2003 e Windows 2000 Server SP3 o versioni successive, i controller di dominio che ospitano i ruoli master operazioni devono anche replicare correttamente le modifiche in ingresso nella partizione di directory che mantiene lo stato del ruolo master operazioni. La replica deve essere eseguita correttamente prima di poter eseguire operazioni dipendenti da FSMO. Tali sincronizzazioni iniziali sono state aggiunte per garantire che i controller di dominio fossero d'accordo sulla proprietà del ruolo FSMO e sullo stato del ruolo. I requisiti di sincronizzazione iniziale necessari per rendere operativi i ruoli FSMO sono diversi dalla sincronizzazione iniziale illustrata in questo articolo, in cui Active Directory deve eseguire la replica in ingresso per avviare immediatamente il servizio server DNS.

Risoluzione

Alcuni contenuti microsoft ed esterni hanno consigliato di impostare il valore Repl Perform Initial Synchronizations del Registro di sistema su 0 per ignorare i requisiti di sincronizzazione iniziale in Active Directory. La sottochiave del Registro di sistema specifica e i valori per tale impostazione sono i seguenti:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Nome valore: Repl Esegue sincronizzazioni iniziali
Tipo di valore: REG_DWORD
Dati valore: 0

Questa modifica della configurazione non è consigliata per l'uso in ambienti di produzione o in qualsiasi ambiente in modo continuativo. L'uso di Repl Perform Initial Synchronizations deve essere usato solo in situazioni critiche per risolvere problemi temporanei e specifici. L'impostazione predefinita deve essere ripristinata dopo la risoluzione di tali problemi.

Altre opzioni possibili includono:

  • Rimuovere i riferimenti ai controller di dominio non aggiornati.

  • Rendere operativi i controller di dominio offline o non funzionati.

  • I controller di dominio che ospitano zone DNS integrate in ACTIVE Directory non devono puntare a un singolo controller di dominio e soprattutto a se stessi come DNS preferito per la risoluzione dei nomi.

    La registrazione dei nomi DNS e la risoluzione dei nomi per i controller di dominio è un'operazione relativamente leggera che è altamente memorizzata nella cache da client e server DNS.

    La configurazione dei controller di dominio in modo che puntino all'indirizzo IP di un singolo server DNS, incluso l'indirizzo di loopback 127.0.0.1, rappresenta un singolo punto di errore. Questa impostazione è tollerabile in una foresta con un solo controller di dominio, ma non nelle foreste con più controller di dominio.

    I controller di dominio del sito hub devono puntare ai server DNS nello stesso sito per il server DNS preferito e alternativo e infine a se stesso come altro server DNS alternativo.

    I controller di dominio del sito di succursale devono configurare l'indirizzo IP del server DNS preferito in modo che punti a un server DNS del sito hub, all'indirizzo IP del server DNS alternativo per puntare a un server DNS nel sito o a uno nel sito disponibile più vicino e infine a se stesso usando l'indirizzo di loopback 127.0.0.1 o l'indirizzo IP statico corrente.

    Il riferimento ai server DNS del sito hub riduce il numero di hop necessari per ottenere la registrazione completa dei record SRV e HOST del controller di dominio critici. I controller di dominio all'interno del sito hub tendono a ottenere l'attenzione più amministrativa, in genere hanno la più grande raccolta di controller di dominio nello stesso sito. Poiché si trovano nello stesso sito, si verificano le modifiche di replica tra loro:

    • ogni 15 secondi in Windows Server 2003 o versioni successive
    • ogni cinque minuti in Windows 2000 Server

    Questo comportamento rende noti tali record DNS.

    Le registrazioni dei record A e AAAA del controller di dominio dinamico SRV e host potrebbero non essere predefinite se il controller di dominio di registrazione in un sito di succursale non è in grado di eseguire la replica in uscita.

    I computer e i server membri devono continuare a puntare a server DNS ottimali per il sito come DNS preferito. E possono puntare a server DNS off-site per una tolleranza di errore aggiuntiva.

    L'obiettivo finale è impedire che tutto causi un denial of service, bilanciando i costi, i rischi e l'utilizzo della rete, ad esempio:

    • latenza di replica e errori di replica
    • errori hardware, errori software
    • procedure operative
    • interruzioni di alimentazione a breve e lungo termine
    • incendi, furti, inondazioni e terremoti
    • eventi terroristici
  • Assicurarsi che i controller di dominio di destinazione possano risolvere i controller di dominio di origine usando DNS (ad esempio, evitare il fallback).

    È necessario assicurarsi che i controller di dominio possano risolvere correttamente i record CNAME guidati per ospitare i record dei controller di dominio di origine correnti e potenziali. In questo modo è possibile evitare la latenza elevata introdotta dalla logica di fallback della risoluzione dei nomi.

    I controller di dominio devono puntare a server DNS che:

    • Sono disponibili all'avvio di Windows.
    • Ospitare, inoltrare o delegare il _msdcs.<zone di dominio> radice della foresta e suffisso DNS primario per controller di dominio di origine correnti e potenziali.
    • Può risolvere i record GUID CNAME correnti ,ad esempio , dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.come i record host dei controller di dominio di origine correnti e potenziali.

    Tutti i record CNAME e host mancanti, duplicati o non aggiornati contribuiscono a questo problema. Lo scavenging non è abilitato nei server DNS Microsoft per impostazione predefinita, aumentando la probabilità di record host non aggiornati. Allo stesso tempo, lo scavenging DNS può essere configurato in modo troppo aggressivo, causando l'eliminazione anticipata dei record validi dalle zone DNS.

  • Ottimizzare i controller di dominio per il fallback della risoluzione dei nomi.

    L'impossibilità di configurare correttamente il DNS in modo che i controller di dominio possano risolvere i record GUID CNAME del controller di dominio per ospitare i record in DNS era comune. Per garantire la replica end-to-end delle partizioni di Active Directory, i controller di dominio Windows Server 2003 SP1 e versioni successive sono stati modificati per eseguire il fallback della risoluzione dei nomi:

    • dal GUID CNAME del controller di dominio al nome host completo.
    • dal nome host completo al nome del computer NetBIOS.

    Gli ID evento di replica NTDS 2087 e 2088 nei log eventi del servizio directory indicano che:

    • Un controller di dominio di destinazione non è riuscito a risolvere il record GUID CNAME del controller di dominio in un record host.
    • si verifica il fallback della risoluzione dei nomi.

    È possibile configurare tutti i file WINS, HOST e LMHOST. I controller di dominio di destinazione possono quindi risolvere i nomi dei controller di dominio di origine correnti e potenziali. Delle tre soluzioni, l'uso di WINS è più scalabile, perché WINS supporta gli aggiornamenti dinamici.

    Gli indirizzi IP e i nomi dei computer diventano inevitabilmente obsoleti. Questo problema causa l'invalidità nel tempo delle voci statiche nei file HOST e LMHOST. Quando si verifica questo problema, le query per un controller di dominio potrebbero essere risolte in modo non corretto in un altro controller di dominio. In una traccia di rete non viene osservata alcuna query sul nome.

  • Modificare il valore di avvio per il servizio server DNS in manuale se si esegue l'avvio in una configurazione non valida nota.

    Se si avvia un controller di dominio in una configurazione non valida nota descritta in questo articolo, seguire questa procedura:

    1. Impostare il valore di avvio del servizio Server DNS su manuale.
    2. Riavviare, attendere che il controller di dominio annunci.
    3. Riavviare il servizio Server DNS.

    Se il valore di avvio del servizio server DNS è impostato su manuale, Active Directory non attende l'avvio del servizio server DNS.

Considerazioni aggiuntive

  • Evitare singoli punti di errore.

    Esempi di singoli punti di errore includono:

    • Configurazione di un controller di dominio in modo che punti a un indirizzo IP del server DNS singolo
    • Inserimento di tutti i server DNS nelle macchine virtuali guest nello stesso computer host fisico
    • Inserimento di tutti i server DNS nello stesso sito fisico
    • Limitazione della connettività di rete in modo che i controller di dominio di destinazione abbiano un solo percorso di rete per accedere a un server KDC o DNS

    Installare un numero sufficiente di server DNS per le prestazioni di ridondanza a livello locale, regionale e aziendale, ma non così tante che la gestione diventa un onere. DNS è in genere un'operazione leggera che viene memorizzata nella cache dai client DNS e dai server DNS.

    Ogni server DNS Microsoft in esecuzione su hardware moderno può soddisfare 10.000-20.000 client per server. L'installazione del ruolo DNS in ogni controller di dominio può comportare un numero eccessivo di server DNS nell'organizzazione. E così facendo aumenterà i costi.

  • Sfalsare i riavvii dei server DNS nell'organizzazione, quando possibile.

    • L'installazione di alcuni hotfix, Service Pack e applicazioni potrebbe richiedere un riavvio.
    • Alcuni clienti riavviano i controller di dominio su base pianificata (ogni sette giorni, ogni 30 giorni).
    • Pianificare i riavvii e l'installazione del software che richiede un riavvio, in modo intelligente. In questo modo, per evitare che l'unico server DNS o il potenziale partner di replica di origine a cui punta un controller di dominio di destinazione per la risoluzione dei nomi, venga riavviato contemporaneamente.

    Se Windows Update o il software di gestione sta installando software che richiede il riavvio, sfalsare le installazioni nei controller di dominio di destinazione in modo che la metà dei server DNS disponibili a cui puntano i controller di dominio per il riavvio della risoluzione dei nomi contemporaneamente.

  • Installare i dispositivi UPS in posizioni strategiche per garantire la disponibilità DNS durante le interruzioni dell'alimentazione a breve termine.

  • Aumentare i server DNS supportati da UPS con generatori in loco.

    Per gestire le interruzioni estese, alcuni clienti hanno distribuito generatori elettrici in loco per mantenere online i server chiave. Alcuni clienti hanno scoperto che i generatori possono alimentare i server nel data center, ma non il sistema HVAC in loco. La mancanza di aria condizionata può causare l'arresto dei server locali quando le temperature interne del computer raggiungono una determinata soglia.

Ulteriori informazioni

10 maggio 2010 test del team di sviluppo di Active Directory:

IL DNS attende NTDS e non può essere avviato fino al completamento della replica iniziale della directory. Perché i dati DNS aggiornati potrebbero non essere ancora replicati nel controller di dominio. D'altra parte, NTDS necessita di DNS per risolvere l'indirizzo IP del controller di dominio di origine per la replica. Si supponga che DC1 punti a DC2 come server DNS e DC2 punti a DC1 come server DNS. Quando dc1 e DC2 si riavvia contemporaneamente, l'avvio sarà lento a causa di questa dipendenza reciproca. La causa principale di questo avvio lento è DNSQueryTimeouts.

Se il servizio Server DNS viene eseguito correttamente all'avvio di NTDS, NTDS accetta solo due query DNS per risolvere l'indirizzo IP del controller di dominio di origine:

  • uno per IPv4
  • l'altro per IPv6

E queste query DNS restituiscono quasi istantaneamente.

Se il servizio Server DNS non è disponibile all'avvio di NTDS, NTDS dovrà inviare 10 query DNS per risolvere l'indirizzo IP:

  • quattro per il nome basato su GUID
  • quattro per il nome completo
  • due per il nome a etichetta singola

La latenza per ogni query DNS è controllata da DNSQueryTimeouts. Per impostazione predefinita, DNSQueryTimeouts è impostato su 1 1 2 4 4. Significa che il client DNS attenderà 12 (1 + 1 + 2 + 4 + 4) secondi per la risposta del server DNS. Ogni origine del contesto di denominazione richiede 120 secondi per risolvere l'indirizzo IP. Si supponga che siano presenti cinque contesti di denominazione (Configurazione, Schema, dominio, ForestDnsZones, DomainDnsZones) e un'unica origine di replica. In questo scenario saranno necessari 850 (170 X 5) secondi o più di 14 minuti per il completamento della replica iniziale di NTDS.

Sono stati eseguiti diversi test per convalidare il comportamento precedente.

  • Riavviare il controller di dominio quando il server DNS è un terzo controller di dominio online. Per ogni contesto di denominazione di ogni origine, sono disponibili due query DNS che sono state completate quasi istantaneamente:

    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
    
  • Riavviare DC1 e DC2 contemporaneamente. DC1 usa DC2 per DNS DC2 e DC1 per DNS. Per ogni contesto di denominazione di ogni origine, sono disponibili 10 query DNS e ogni query richiede circa 12 secondi:

    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
    
  • Per studiare ulteriormente la relazione tra DNSQueryTimeouts e l'avvio lento, DNSQueryTimeouts è stato impostato su 1 1 2 4 4 per fare in modo che il client DNS attenda 31 (1 + 1 + 2 + 4 + 4) secondi. In questo test sono stati trascorsi 31 secondi in attesa:

    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