- Artikkel
Denne artikkelen løser hendelses-ID 4013 som er logget i DNS-hendelsesloggen til domenekontrollere som er vert for DNS-serverrollen etter at Windows starter.
Gjelder:Windows Server 2012 R2
Originalt KB-nummer:2001093
Symptomer
På en Windows-basert datamaskin som er vert for Active Directory-domenekontrollere, slutter DNS-serverrollene å svare i 15 til 25 minutter. Dette problemet oppstår etterForberede nettverkstilkoblingermeldingen vises, og før Windows-påloggingsforespørselen (Ctrl+Alt+Del) vises.
Følgende DNS-hendelses-ID 4013 logges i DNS-hendelsesloggen til domenekontrollere som er vert for DNS-serverrollen etter at Windows starter:
Hendelsestype: Advarsel Hendelseskilde: DNS-hendelseskategori: Ingen Hendelses-ID: 4013 Dato: Dato Tid: Tid Bruker: N/A Datamaskin: Datamaskinnavn Beskrivelse: DNS-serveren kunne ikke åpne Active Directory. Denne DNS-serveren er konfigurert til å bruke katalogtjenesteinformasjon og kan ikke fungere uten tilgang til katalogen. DNS-serveren vil vente på at katalogen starter. Hvis DNS-serveren er startet, men den aktuelle hendelsen ikke er logget, venter DNS-serveren fortsatt på at katalogen skal starte. For mer informasjon, se Hjelp og støttesenter på https://go.microsoft.com/fwlink/ events.asp. Data: 0000: <%statuskode%>I denne loggoppføringen kan det hende at verdiene <%Statuskode%> ikke logges. Eller de inkluderer, men er ikke begrenset til, følgende verdier:
Hex Byte Desimal Symbolsk Feilstreng 000025f5 f5 25 00 00 9717 DNS_ERROR_DS_UNAVAILABLE Katalogtjenesten er utilgjengelig 0000232d 2d 23 00 00 9005 DNS_ERROR_RCODE_REFUSED DNS-operasjon nektet. 0000232a 2a 23 00 00 9002 DNS_ERROR_RCODE_SERVER_FAILURE DNS-serverfeil.
Eksempel på kundescenarier
Flere domenekontrollere på et Active Directory-nettsted som startes på nytt samtidig.
- Et kontrollerdomene med to domene er distribuert i samme datasenter.
- DNS-serverrollen er installert på begge domenekontrollerne, og den er vert for AD-integrerte kopier av domenesonene _msdcs.
og Active Directory. - DC1 er konfigurert til å bruke DC2 for foretrukket DNS og seg selv for alternativ DNS.
- DC2 er konfigurert til å bruke DC1 for foretrukket DNS og seg selv for alternativ DNS.
- Alle domenekontrollere har avbruddsfri strømforsyning (UPS) og backup av elektriske generatorer.
- Datasenteret opplever hyppige strømbrudd på 2 til 10 timer. UPS-enheter holder domenekontrollerne i drift til generatorene leverer strøm, men de kan ikke kjøre HVAC-systemet. Temperaturbeskyttelse innebygd i serverklassedatamaskiner slår av domenekontrollerne når interne temperaturer når produsentens grenser.
- Når strømmen til slutt kommer tilbake, henger domenekontrollerne i 20 minutter. Dette problemet oppstår etterForberede nettverkstilkoblingervises, og før påloggingsforespørselen vises.
- DNS-hendelses-ID 4013 logges i DNS-hendelsesloggen.
Å åpne DNS-administrasjonskonsollen (DNSMGMT.MSC) mislykkes og genererer følgende feilmelding:
Serveren
kunne ikke kontaktes. Feilen var: Serveren er utilgjengelig. Vil du legge det til likevel? Når du åpner snapin-modulen Active Directory Users and Computers (DSA.MSC) genereres følgende feilmelding:
Kunne ikke finne navneinformasjon
Enkeltdomenekontrollere på et Active Directory-nettsted
Én domenekontroller er distribuert på et nettsted.
DNS-serverrollen er installert, og den er vert for AD-integrerte kopier av domenesonene _msdcs.
og Active Directory. Domenekontrolleren peker på seg selv for foretrukket DNS.
Domenekontrolleren har ingen alternativ DNS-server spesifisert eller peker til en domenekontroller over en WAN-kobling (wide-area network).
Domenekontrolleren startes på nytt på grunn av strømbrudd.
Under omstart kan det hende at WAN-koblingen ikke fungerer.
Når domenekontrolleren startes, kan den henge i 20 minutter. Dette problemet oppstår etterForberede nettverkstilkoblingervises, og før påloggingsforespørselen vises.
See AlsoAnti-spam meldingshoderDNS-hendelses-ID 4013 logges i DNS-hendelsesloggen.
Å åpne DNS-administrasjonskonsollen (DNSMGMT.MSC) mislykkes og genererer følgende feilmelding:
Serveren
kunne ikke kontaktes. Feilen var: Serveren er utilgjengelig. Vil du legge det til likevel?
Når du åpner snapin-modulen Active Directory Users and Computers (DSA.MSC) genereres følgende feilmelding:
Kunne ikke finne navneinformasjon.
Årsaken
Kopien av Active Directory i noen domenekontrollere inneholder referanser til andre domenekontrollere i skogen. Disse domenekontrollerne prøver å replikere alle lokalt holdte katalogpartisjoner under oppstart av Windows, som en del av en innledende synkronisering ellerstarte synkronisering.
I et forsøk på å starte opp med det nyeste DNS-soneinnholdet, forsinker Microsoft DNS-servere som er vert for AD-integrerte kopier av DNS-soner oppstarten av DNS-tjenesten i flere minutter etter oppstart av Windows. Forsinkelsen vil ikke oppstå hvis Active Directory har fullført sin første synkronisering under oppstart av Windows. I mellomtiden er Active Directory forsinket fra innkommende replikerende katalogpartisjoner. Replikering er forsinket til den kan løse CNAME GUID-en til kildedomenekontrolleren til en IP-adresse på DNS-serverne som brukes av måldomenekontrolleren for navneoppløsning. Varigheten av hengingen mens du forbereder nettverkstilkoblinger avhenger av antallet lokalt holdte katalogpartisjoner som ligger i en domenekontrollers kopi av Active Directory. De fleste domenekontrollere har minst følgende fem partisjoner:
- skjema
- konfigurasjon
- domene
- skogdekkende DNS-applikasjonspartisjon
- DNS-applikasjonspartisjon for hele domenet
Og disse domenekontrollerne kan oppleve en 15-20 minutters oppstartsforsinkelse. Eksistensen av ekstra partisjoner øker oppstartsforsinkelsen.
DNS Event ID 4013 i DNS-hendelsesloggen indikerer at oppstarten av DNS-tjenesten ble forsinket. Det er fordi innkommende replikering av Active Directory-partisjoner ikke hadde skjedd.
Flere forhold kan forverre følgende problemer:
- treg oppstart av Windows
- loggingen av DNS-hendelse 4013 på DNS-servere som er konfigurert til å være vert for AD-integrerte soner, som implisitt ligger på datamaskiner som fungerer som domenekontrollere.
Disse forholdene inkluderer:
- Konfigurere en DNS-server som er vert for AD-integrerte DNS-soner. Dens kopi av Active Directory inneholder kunnskap om andre domenekontrollere i skogen for å peke på seg selv utelukkende for DNS-navneoppløsning.
- Konfigurere en DNS-server som er vert for AD-integrerte DNS-soner. Dens kopi av Active Directory inneholder kunnskap om andre domenekontrollere i skogen for å peke DNS-servere som enten ikke eksisterer, for øyeblikket er frakoblet, ikke er tilgjengelige på nettverket, eller som ikke er vert for de nødvendige sonene og postene som er nødvendig for å inngående replikere Active Directory. Eksempler inkluderer domenekontrolleren CNAME GUID-posten og dens tilsvarende vert A- eller AAAA-post over potensielle kildedomenekontrollere.
- Oppstart av en domenekontroller og DNS-server som er vert for AD-integrerte DNS-soner. Dens kopi av Active Directory inneholder kunnskap om andre domenekontrollere på det som faktisk er et isolert nettverk fordi:
- Nettverksadapteren eller nettverksstabelen på den som ringer eller måldatamaskinen er enten deaktivert eller ikke-funksjonell.
- Domenekontrolleren har blitt startet opp på et isolert nettverk.
- Den lokale domenekontrollerens kopi av Active Directory inneholder referanser til foreldede domenekontrollere som ikke lenger eksisterer på nettverket.
- Den lokale domenekontrollerens kopi av Active Directory inneholder referanser til andre domenekontrollere som for øyeblikket er slått av.
- Det er et problem på enten kildedomenekontrolleren, måldomenekontrolleren eller DNS- eller nettverksinfrastrukturen. Så den lokale domenekontrollerens kopi av Active Directory inneholder referanser til andre domenekontrollere som er online og tilgjengelige, men som ikke kan replikeres fra.
I Windows Server 2003 og Windows 2000 Server SP3 eller nyere må domenekontrollerne som er vertskapsoperasjonsmasterroller også replikere innkommende endringer på katalogpartisjonen som opprettholder driftshovedrollens status. Vellykket replikering må skje før FSMO-avhengige operasjoner kan utføres. Slike innledende synkroniseringer ble lagt til for å sikre at domenekontrollere var enige om FSMO-rolleeierskap og rolletilstand. De innledende synkroniseringskravene som kreves for at FSMO-roller skal bli operative, er forskjellige fra den første synkroniseringen som er omtalt i denne artikkelen, der Active Directory må replikere innkommende for å starte DNS-servertjenesten umiddelbart.
Vedtak
Noe Microsoft og eksternt innhold har anbefalt å angi registerverdienRepl Utfør innledende synkroniseringertil0for å omgå innledende synkroniseringskrav i Active Directory. Den spesifikke registerundernøkkelen og verdiene for den innstillingen er som følger:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Verdinavn: Repl Utfør innledende synkroniseringer
Verditype: REG_DWORD
Verdidata: 0
Denne konfigurasjonsendringen anbefales ikke for bruk i produksjonsmiljøer, eller i noe miljø på løpende basis. Bruken avRepl Utfør innledende synkroniseringerbør kun brukes i kritiske situasjoner for å løse midlertidige og spesifikke problemer. Standardinnstillingen bør gjenopprettes etter at slike problemer er løst.
Andre mulige alternativer inkluderer:
Fjern referanser til foreldede domenekontrollere.
Gjør frakoblede eller ikke-fungerende domenekontrollere operative.
Domenekontrollere som er vert for AD-integrerte DNS-soner, bør ikke peke til én enkelt domenekontroller, og spesielt kun til seg selv som foretrukket DNS for navneoppløsning.
DNS-navneregistrering og navneoppløsning for domenekontrollere er en relativt lett operasjon som er svært hurtigbufret av DNS-klienter og -servere.
Konfigurering av domenekontrollere til å peke til en enkelt DNS-servers IP-adresse, inkludert 127.0.0.1 loopback-adressen, representerer et enkelt feilpunkt. Denne innstillingen kan tolereres i en skog med bare én domenekontroller, men ikke i skoger med flere domenekontrollere.
Domenekontrollere for hub-side bør peke til DNS-servere på samme sted som dem for foretrukket og alternativ DNS-server og til slutt til seg selv som en annen alternativ DNS-server.
Grensteddomenekontrollere bør konfigurere den foretrukne DNS-serverens IP-adresse til å peke til en hub-site DNS-server, den alternative DNS-serverens IP-adresse til å peke til en in-site DNS-server eller en i det nærmeste tilgjengelige nettstedet, og til slutt til seg selv ved å bruke 127.0.0.1 loopback-adressen eller gjeldende statiske IP-adresse.
Å peke på hub-site DNS-servere reduserer antallet hopp som kreves for å få fullstendig registrert SRV- og HOST-poster for kritisk domenekontroller. Domenekontrollere på hub-siden har en tendens til å få mest administrativ oppmerksomhet, og har vanligvis den største samlingen av domenekontrollere på samme side. Fordi de er på samme nettsted, oppstår det replikerte endringer mellom hverandre:
- hvert 15. sekund i Windows Server 2003 eller nyere
- hvert femte minutt i Windows 2000 Server
Denne oppførselen lager slike DNS-posterVelkjente.
Dynamisk domenekontroller SRV og vert A- og AAAA-postregistreringer kan ikke gjøre den off-box hvis den registrerende domenekontrolleren på et filialområde ikke er i stand til å replikere utgående.
Medlemsdatamaskiner og -servere bør fortsette å peke på nettstedoptimale DNS-servere som foretrukket DNS. Og de kan peke på off-site DNS-servere for ytterligere feiltoleranse.
Ditt endelige mål er å forhindre at alt forårsaker tjenestenekt mens du balanserer kostnader, risiko og nettverksutnyttelse, for eksempel:
- replikeringsforsinkelse og replikeringsfeil
- maskinvarefeil, programvarefeil
- operasjonelle praksiser
- kort og langvarig strømbrudd
- brann, tyveri, flom og jordskjelv
- terrorhendelser
Sørg for at destinasjonsdomenekontrollere kan løse kildedomenekontrollere ved hjelp av DNS (for eksempel unngå fallback).
Du bør sørge for at domenekontrollere kan løse de guidede CNAME-postene til å være vertsposter for gjeldende og potensielle kildedomenekontrollere. Ved å gjøre det kan du unngå høy latenstid som introduseres av reservelogikk for navneoppløsning.
Domenekontrollere bør peke på DNS-servere som:
- Er tilgjengelig ved oppstart av Windows.
- Vær vert for, videresend eller deleger _msdcs.
og primære DNS-suffikssoner for gjeldende og potensielle kildedomenekontrollere. - Kan løse gjeldende CNAME GUID-poster (f.eks.
dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.com) og vertsposter for gjeldende og potensielle kildedomenekontrollere.
Manglende, dupliserte eller foreldede CNAME- og vertsposter bidrar alle til dette problemet. Rensing er ikke aktivert på Microsoft DNS-servere som standard, noe som øker sannsynligheten for foreldede vertsposter. Samtidig kan DNS-oppfanging konfigureres for aggressivt, noe som fører til at gyldige poster fjernes for tidlig fra DNS-soner.
Optimaliser domenekontrollere for navneoppløsning.
Manglende evne til å konfigurere DNS riktig slik at domenekontrollere kunne løse domenekontrollerens CNAME GUID-poster til å være vertsposter i DNS, var vanlig. For å sikre ende-til-ende-replikering av Active Directory-partisjoner, ble Windows Server 2003 SP1 og senere domenekontrollere modifisert for å utføre navneoppløsning fallback:
- fra domenekontroller CNAME GUID til fullt kvalifisert vertsnavn.
- fra fullt kvalifisert vertsnavn til NetBIOS-datamaskinnavn.
NTDS-replikeringshendelses-ID-ene 2087 og 2088 i Directory Service-hendelsesloggene indikerer at:
- en destinasjonsdomenekontroller kunne ikke løse CNAME GUID-posten for domenekontrolleren til en vertspost.
- fallback for navneløsning skjer.
WINS, HOST-filer og LMHOST-filer kan alle konfigureres. Så destinasjonsdomenekontrollere kan løse navnene på gjeldende og potensielle kildedomenekontrollere. Av de tre løsningene er bruken av WINS mer skalerbar, fordi WINS støtter dynamiske oppdateringer.
IP-adressene og navnene for datamaskiner blir uunngåelig foreldede. Dette problemet fører til at statiske oppføringer i HOST- og LMHOST-filer blir ugyldige over tid. Når dette problemet oppstår, kan spørsmål for én domenekontroller løses feil til en annen domenekontroller. Og ingen navnespørring blir observert i et nettverksspor.
Endre oppstartsverdien for DNS-servertjenesten til manuell hvis du starter opp i en kjent dårlig konfigurasjon.
Hvis du starter opp en domenekontroller i en kjent dårlig konfigurasjon som er omtalt i denne artikkelen, følger du disse trinnene:
- Sett oppstartsverdien for DNS-servertjenesten til manuell.
- Start på nytt, vent til domenekontrolleren annonserer.
- Start DNS-servertjenesten på nytt.
Hvis tjenesteoppstartsverdien for DNS Server-tjenesten er satt til manuell, venter ikke Active Directory på at DNS Server-tjenesten starter.
Ytterligere hensyn
Unngå enkeltpunkter for feil.
Eksempler på enkeltpunkter for feil inkluderer:
- Konfigurere en DC til å peke til en enkelt-DNS-server IP
- Plassering av alle DNS-servere på virtuelle gjestemaskiner på samme fysiske vertsdatamaskin
- Plassering av alle DNS-servere på samme fysiske nettsted
- Begrense nettverkstilkobling slik at destinasjonsdomenekontrollere bare har en enkelt nettverksbane for å få tilgang til en KDC- eller DNS-server
Installer nok DNS-servere for lokal, regional og bedriftsomfattende redundansytelse, men ikke så mange at ledelsen blir en byrde. DNS er vanligvis en lett operasjon som er høyt bufret av DNS-klienter og DNS-servere.
Hver Microsoft DNS-server som kjører på moderne maskinvare kan tilfredsstille 10 000-20 000 klienter per server. Installering av DNS-rollen på hver domenekontroller kan føre til et for stort antall DNS-servere i bedriften din. Og å gjøre det vil øke kostnadene.
Forskyv omstartene av DNS-servere i bedriften din når det er mulig.
- Installasjonen av enkelte hurtigreparasjoner, oppdateringspakker og programmer kan kreve en omstart.
- Noen kunder starter domenekontrollere på nytt på en planlagt basis (hver syvende dag, hver 30. dag).
- Planlegg omstarter, og installasjon av programvare som krever omstart, på en smart måte. Å gjøre det for å forhindre at den eneste DNS-serveren, eller potensielle kildereplikeringspartner som en destinasjonsdomenekontroller peker på for navneløsning, blir omstartet samtidig.
Hvis Windows Update eller administrasjonsprogramvare installerer programvare som krever omstart, forskyv installasjonene på målrettede domenekontrollere slik at halvparten av de tilgjengelige DNS-serverne som domenekontrollerne peker på for navneoppløsning omstarter samtidig.
Installer UPS-enheter på strategiske steder for å sikre DNS-tilgjengelighet under kortvarige strømbrudd.
Utvid dine UPS-støttede DNS-servere med generatorer på stedet.
For å håndtere langvarige strømbrudd har noen kunder distribuert elektriske generatorer på stedet for å holde nøkkelservere online. Noen kunder har funnet ut at generatorer kan drive servere i datasenteret, men ikke HVAC på stedet. Mangelen på klimaanlegg kan føre til at lokale servere slår seg av når interne datamaskintemperaturer når en viss terskel.
Mer informasjon
10. mai 2010 testing av Active Directory-utviklingsteamet:
DNS venter på NTDS og kan ikke starte før den første replikeringen av katalogen er fullført. Det er fordi oppdaterte DNS-data kanskje ikke er replikert til domenekontrolleren ennå. På den annen side trenger NTDS DNS for å løse IP-adressen til kildedomenekontrolleren for replikeringen. Anta at DC1 peker på DC2 som sin DNS-server, og DC2 peker på DC1 som sin DNS-server. Når både DC1 og DC2 starter på nytt samtidig, vil det være en treg oppstart på grunn av denne gjensidige avhengigheten. Grunnårsaken til denne trege oppstarten er DNSQueryTimeouts.
Hvis DNS Server-tjenesten kjører bra når NTDS starter, tar NTDS bare to DNS-spørringer for å løse IP-adressen til kildedomenekontrolleren:
- en for IPv4
- den andre for IPv6
Og disse DNS-spørringene returnerer nesten umiddelbart.
Hvis DNS Server-tjenesten ikke er tilgjengelig når NTDS starter, må NTDS sende ut 10 DNS-spørringer for å løse IP-adressen:
- fire for GUID-basert navn
- fire for fullt kvalifisert navn
- to for enkeltetikettnavn
Latens for hver DNS-spørring kontrolleres av DNSQueryTimeouts. Som standard er DNSQueryTimeouts satt til1 1 2 4 4. Det betyr at DNS-klienten vil vente 12 (1 + 1 + 2 + 4 + 4) sekunder på DNS-serversvaret. Hver navnekontekstkilde tar 120 sekunder å løse IP-adressen. Anta at det er fem navnekontekster (konfigurasjon, skjema, domene, ForestDnsZones, DomainDnsZones) og én enkelt replikeringskilde. I dette scenariet vil det ta 850 (170 X 5) sekunder, eller mer enn 14 minutter, før NTDS fullfører den første replikeringen.
Det ble gjort flere tester for å validere oppførselen ovenfor.
Start domenekontrolleren på nytt når DNS-serveren er en tredje domenekontroller som er online. For hver navnekontekst hver kilde har vi to DNS-spørringer, og de fullførte nesten umiddelbart:
i I_DRSGetNCChanges, NC = CN=Konfigurasjon,DC=contoso,DC=comin getContextBindingHelper, pszAddress = dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contosos.com GetContextBindingHelper, pszAddress = dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contososos.com GetContextBindingHelper in resolveIDAd yDnsNameW i GetIpAddrByDnsNameHelper start GetAddrInfoW: 22: 31:40.534 slutt GetAddrInfoW: 22:31:40.534 i GetIpAddrByDnsNameHelper start GetAddrInfoW: 22:31:40.534 end GetAddrInfoW: 22:31:40.534Start DC1 og DC2 på nytt samtidig. DC1 bruker DC2 for DNS DC2 bruker DC1 for DNS. For hver navnekontekst hver kilde har vi 10 DNS-spørringer, og hvert søk tar omtrent 12 sekunder:
i I_DRSGetNCChanges, NC = CN=Konfigurasjon,DC=contoso,DC=com i getContextBindingHelper, pszAddress = dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.contoso.microsoftDnsAddress based in DGUDNS-ID. xAddrByDnsNameW i GetIpAddrByDnsNameHelper start GetAddrInfoW : 22:37:43.066 slutten GetAddrInfoW: 22:37:55.113 i GetIpAddrByDnsNameHelper start GetAddrInfoW: 22:37:55.113 end GetAddrInfoW: 22:38:07.131 in GetIpAddrInfoW: 8 7.131 slutten GetAddrInfoW: 22:38:19.161 i GetIpAddrByDnsNameHelper start GetAddrInfoW: 22:38:19.176 end GetAddrInfoW: 22:38:31.185 FQDN i GetIpVxAddrByDnsNameW i GetIpAddrByDnsNameHelper start GetAddrInfoW: 32Adr: 2Adr. :43.182 i GetIpAddrByDnsNameHelper start GetAddrInfoW: 22:38:43.182 end GetAddrInfoW: 22:38:55.191 i GetIpAddrByDnsNameHelper start GetAddrInfoW: 22:38:55.191 end GetAddrInfoW: 22:39:07.216 i GetIpAddrByDnsNameHelper start GetAddrInfoW:21W: Slutt GetAddrInfoW: 22:39:07.216 :39:19.286 NetBios i GetIpVxAddrByDnsNameW i GetIpAddrByDnsNameHelper start GetAddrInfoW : 22:39:19.286 slutt GetAddrInfoW: 22:39:31.308d i GetIpAddrByDnsNameHelper start GetAddrInfoW: 22:39:31.308 end GetAddrInfoW: 22:39:43.324For å studere forholdet mellom DNSQueryTimeouts og den trege oppstarten ytterligere, ble DNSQueryTimeouts satt til1 1 2 4 4for å få DNS-klienten til å vente i 31 (1 + 1 + 2 + 4 + 4) sekunder. I denne testen ble det brukt 31 sekunder på å vente:
i I_DRSGetNCChanges, NC = CN=Configuration,DC=contoso,DC=com i getContextBindingHelper, pszAddress = dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contosos.com i resolveIDVDNSAddress basedBVDNS yDnsNameW i GetIpAddrByDnsNameHelper start GetAddrInfoW: 18 :06:48.143 slutt GetAddrInfoW: 18:07:19.158 i GetIpAddrByDnsNameHelper start GetAddrInfoW: 18:07:19.158 end GetAddrInfoW: 18:07:50.162 i GetIpHdrInfoW:AddrInfoW:8AddrBy0:8 2 end GetAddrInfoW: 18:08:21.161 i GetIpAddrByDnsNameHelper start GetAddrInfoW: 18:08:21.161 end GetAddrInfoW: 18:08:52.158 FQDN i GetIpVxAddrByDnsNameW i GetIpAddrByDnsNameHelper start GetAddrInfoW: 18:08:52.221 end:ByDrInfoW:2Addr. yDnsNameHelper start GetAddrInfoW: 18:09:23.231 end GetAddrInfoW: 18:09:54.243 i GetIpAddrByDnsNameHelper start GetAddrInfoW: 18:09:54.243 end GetAddrInfoW: 18:10:25.239 i GetIpAddrByDnsNameHelper start GetAddrInfoW: 25.23:109. 243 NetBios i GetIpVxAddrByDnsNameW i GetIpAddrByDnsNameHelper start GetAddrInfoW: 18 :10:56.243 slutt GetAddrInfoW: 18:11:27.244 i GetIpAddrByDnsNameHelper start GetAddrInfoW: 18:11:27.244 end GetAddrInfoW: 18:11:58.265