Microsoft-Windows-NlaSvc Error ID 4205


  • In my Window Server 2008 R2 OS in the Event Viewer there is an error pertains as Microsoft-Windows-Nlasvc Error ID 4205 states-(Gateway resolution failed on interface {d9470891-785a-4f67-82c7-53dc6646ad1ad} for o.o.o.o-[default gateway address] with error:0x57). What is this error? And What is the remedy for this error?
    vendredi 21 octobre 2011 14:34


Toutes les réponses

  • Hi,

    May wanna check this article. Although the error is not exactly the same you may take a look


    A computer cannot identify the network when the computer is running Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2, and is a member of a child domain 


    Do you have gateway address assigned to all network interfaces?

    Will appreciate if you give feedback if this has helped you. If yes please select “Mark as answer”.


    Best Regards,

    Spas Kaloferov

    [ MCITP: SA7 | EA7 | VA7 | EDA7 |DBA10 | DBD10 | BID10 | EMA14 | SPA14  ]

    NetShell Services & Solutions | “Design the future with simplicity and elegance”

    Visit me at: | www:

    vendredi 21 octobre 2011 15:47
  • I also see this event occuring repeatedly at a very high rate, polluting the event viewer so much that it makes it almost unusable, and that it generates too much disk activity.


    In fact this error has started since the time where my ISP has provided an IPv6 connectivity on its router (in addition to the existing IPv4 connectivity; in fact my ISP uses internally a proprietary Cisco tunnel to encapsulate the IPv6 traffic over the IPv4 connection over ADSL; the tunnel is established automatically by the router).

    Windows correctly gets an IPv6 address autoallocated in the IPv6 address block advertized by the router. Windows also attempts to use DHCPv6, but there's no DHCPv6 server implemented for now in the router (only the zero-config autoconfiguration is used).

    But the problem is that this IPv6 connectivity does not have any DNS server configured to be accessible by IPv6 (Windows also attempts to use DHCPv6 to get the DNSv6 address, but fails, and we are left without any DNS server on IPv6; it is not very important because the router implements a DNS proxy locally accessible on its IPv4 address, here, and name resolution is performed on this DNS server.

    Apparently, the NLA service of Windows does not detect that, on the PC, the hardware Ethernet interface is correctly configured with an IPv4 address (192.168.1.xx),  a correct IPv4 address mask ( to reach the default gateway ( which is the router that also advertized the DNS server (, i.e. the router itself as it is acting as a DNS proxy); but Windows has configured *both* a local-link IPv6 address (fe80:...) and correctly configured the Internet compatible (routable) IPv6 address (2001:...) within the correct IPv6 address block. But note that the router itself has *NO* IPv6 address for itself, so its DNS proxy is not reachable via IPv6. The network interface then has no DNS server for IPv6.

    Windows should continue to use the IPv4 DNS server, which can correctly resolve *both* IPv4 and IPV6 addresses for domain names, as well as performing the reverse resolution.

    The NLA Service however insists is trying to connect to an inexistant DNSv6 server, and constantly replies that it cannot identify the domain name of the IPv6 address, only because the NLA service still does not query the correct DNSv4 server which is configured on the same physical Ethernet network interface. I think this is a bug of the NLA service: it is perfectly valid for a network interface usable for Internet to have *no* DNSv6 server but only a DNSv4 server.

    Unfortunately, the NLA Service is spamming the Event viewer with lots of events (I get them by batches of 16 messages at the same time, with this Error ID 4205, every 10 seconds). This is really too much! The NLA service is unable to pace itself after the first failures. In fact it should not even log so many "Errors" in the Event viewer if it was doing things correctly.

    This is also a major performance problem (disk activity, slow responsiveness when listing the available networks, or when enumerating UPNP devices over the local network).

    Please Microsoft, correct the NLA service so that it will use the correct information and NOT require a DNSv6 server on an IPv6-enabled network interface, if it already has at least an IPv4 DNS server on the same network interface instance. It's true that nothing indicates that IPv4 and IPv6 will have the same routings, so the identification (by domain name) of the network may be different, but at least, in terms of security, the routable IPv6 address assigned to an interface should be treated like the routable IPv4 address on the same interface. So if you don't have a configured DNSv6 to get the name of the assigned IPv6 address, you should use the configured DNSv4 to query the name of the assigned routable IPv6 address (2001:...).

    Note: the local-link IPv6 address (fe80:...) is never routable, it will have no name except for local-link applications, and if there's a DNS server running and serving the local network. You may want to detect if this local link address has a name, but in fact this is superfluous: on the local ink, we are in the world of the "Residential Homegroup", and hosts are identified via the Microsoft networking protocol (SMB/CIFS) even if there's no DNS configured on the LAN.


    For all these reasons, I had to disable the logging of "Microsoft/Windows/NlaSvc" in the Event viewer. It is completely useless, uninformative (because it also indicates the network interfaces concerned only by their internal device driver instance UUID, without any indication of its informative name, and the message provides absolutely no hint about which query exactly failed, if this was an attempt to connect to a DNSv6 server, and which DNS server was attempted). Nobody will be able to use the event message data found in this Error ID:4205.

    • Proposé comme réponse Horia Puscuta samedi 10 août 2013 11:24
    mercredi 30 novembre 2011 16:18
  • Guys, this is the scenario that I face.

    I use a HSDPA Mobile broaband connection for internet and only IPV4 connectivity (IPV6 is unchecked in network connection properties). This happens maybe once or twice daily and the whole system hangs up. Nothing works and I have to power off the system and power it on again. All i remember changing is try the google DNS Server and then set it back to obtain automatically. 

    I note the following error once before a whole pile of the above error - The DNS proxy Server was unable to allocate 0 bytes of memory

    Apart from that nothing else remotely related to this error but yes, it does clog up the event viewer.

    Any ideas?

    • Proposé comme réponse verdy.p samedi 9 juin 2012 17:18
    • Non proposé comme réponse verdy.p samedi 9 juin 2012 17:18
    samedi 9 juin 2012 13:35
  • The simplest thing is to disable completely the error reporting made by NlsSvc (disable this bogous source of too many unneeded events).

    Open Start Menu > admin Tools > Events Viewer

    Select in the left column: Events Viewer (local) > Applications and Services Logs > Microsoft > Windows > NlaSvc > Operational

    In the right column (Actions), click: Properties to open the logging properties for this NlaSvc/Operational log.

    In the properties dialog, in the first "General" tab, there's a check box "Enable logging", uncheck it. Click the "Clear log" button to clear its existing content, then click "Validate" to apply the disabled logging.


    Disabling the logging in NlsSvc does not affect security (but this improves Windows performance, notably if those logged events are really too frequent and in fact unsolvable just like in this problem, where it is caused by a bug of NlaSvc.

    The NlaSvc incorrectly assumes that if you have an internet access on a physical interface, and that interface supports a DNS client configuration, and that interface also supports an IPv6 connectivity, this connectivity extends to the Internet and includes the configuration of an existing DNS server also accessible in IPv6 (this is wrong : you can have a full IPv6 connectivity, even with routing to the Internet, but still no DNS server configured and accessible with an IPv6 address; you can perfectly configure and use a DNS server that is only reachable by its IPv4 address to perform IPv6 resolutions, such as getting AAAA records from a domain name, or performing an inverse resolution from an IPv6 address to an identifiable canonical domain name). Due to this assumption, the NlaSvc is trying to get an IPv6 address of a DNS server, but can't get any one, and still continues to repeatedly get such configuration and logging the error constantly).

    But such logging may only be useful for debugging problems in the NlaSvc in specific local network configurations containing various interdomain gateways. Home users don't care about this service, most of the time, unless they have a specific hardware in their LAN configured for example to allow external accesses (e.g. to access your medias from a secure entry points, or for allowing remote administration of these devices and their integration in the Windows desktop). Most of the time, this debugging is a temporary need only : if you don't debug this, you can disable the logging in those Windows services.


    You may finally delete the huge file that stored these dummy unnecessary events (the location of the file is indicated in the properties dialog, but by default it was configured by default in the folder "%SystemRoot%\System32\Winevt\Logs" where it is named "Microsoft-Windows-NlaSvc%4Operational.evtx".

    You may visit the content of the "%SystemRoot%\System32\Winevt\Logs" folder to see which logs are unnecessarily long (check the associated services in the Events Viewer to see why their size became too large. In may just happen that their default maximum size (configured also in the "Properties" dialog within the Events Viewer) is in fact too large: check the last events you have, ignore those that are too old, look at their frequency. You probably don't need to leave them grow at a so large size, most services can use small logs, so configure them in their minimum allowed in the Properties dialog

    The minimum you can define for the maximum size of each events storage file is 64 KB for the few logs in text format, and 1028 KB for logs in "*.evtx" format (this is the events logging format used by almost all Windows builtin services in Windows 7/8) : when you clear an events log, its restarts to a minium size of 68KB and then grows as necessary up to this maximum, according to the policy defined in the Properties dialog.

    Some events logs are preconfigured in Windows to grow to a larger size than 1028KB : this is the case of the standard system logs that are configured to grow up to 20 MB (but if your clear them, they will restart at the initial empty size of 68KB (which is 64KB for an initial index and the first page of logs containing infos about when the log was created or cleared, by whom, and the policies you have defined (including restrictions of access to view them).

    • Modifié verdy.p samedi 9 juin 2012 17:57
    samedi 9 juin 2012 17:46
  • Just had these same errors, and read this comment and thought. Way to go, you tell 'em.  But it looks like the same error is still generating in Windows Server 2012, maybe not as many times as you got it but it's still for the same reason, anyway if I had a default gateway for IPv6 then I wouldn't need one for IPv4.  I wish I had an ipv6 default gateway to put down on my servers.  If anyone knows how I can solve this problem by using Teredo in an enterprise client domain configuration let me know.

    I always turn on peer name resolution protocol and tunneling but I want to know how to set up one of my servers to be a Teredo server, or if I can use one of the well known teredo servers like Microsoft's or googles in an enterprise domain behind an ipv4 router.. I want to learn how to utilize these technologies since Verizon is not offering me any ipv6 connectivity from my networks.

    vendredi 9 août 2013 18:12