Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to www.eventid.net. The EventId.Net for Splunk Add-on assumes that Splunk is collecting information from Windows servers and workstation via the Splunk Universal Forwarder.
WINS could not read from the User Datagram Protocol (UDP) socket.
|English: Request a translation of the event description in plain English.|
|Concepts to understand:|
What is the role of the WINS service?
As per Microsoft: "This message means that WINS was unable to receive a name packet. Stop the WINS service. Then double-click Network in the Control Panel. Under the Protocols tab, verify that the TCP/IP driver is installed and running. Restart WINS if necessary to correct the problem." We have seen reports on this problem even when the TCP/IP seems to be running fine.
I received this error after upgrading a Win2k DC to Win2k3. The solution was to give the Local System account read rights to the following registry key:
As per Microsoft: "This event indicates that WINS was unable to receive a name packet". See MSW2KDB for troubleshooting steps.
According to Microsoft this event can also occur if the file permissions on the WINS directory have been changed from their default settings. Change the file permissions back to the default of Everyone=Full Control for the %Systemroot%\System32\WINS directory. See ME158865.
This seems to be a common problem, here's a useful thing I found on a Google search... not really a fix, but it does help explain the problem: "I started receiving the error event 4204 on a freshly installed SBS2000 network. I used a packet sniffer to determine the source of the bad packets. Apparently WINS tries to find replicating partners on start-up and thereafter every 40 minutes by sending IGMP packets to multicast 220.127.116.11. Check out the ME151761 knowledge base article. In my case some devices on the network (a couple of network enabled Moxa serial port adapters) responded to the multicast and thereby caused the error messages. A google search revealed a guy had the same problem with a bunch of Netware 6 servers. I got the problem fixed now, after consulting with the excellent technical support at Moxa, and a couple of firmware upgrades (- on the serial port adapters that is)."
It appears that sometimes, this error is coming from Netware servers being on the same network as the WINS servers. Every 40 minutes the WINS servers send out a multicast packet, and for some reason, Netware server reply back with an ICMP packet stating "Destination Unreachable". This results in one event logged for each Netware server on the network.
I found that when a Windows 2000 based WINS server starts and then every 40 minutes (ME151761) it sends out IGMP packets to multicast address 18.104.22.168 looking for replication partners. I have four serial port adapters (MOXA) in my network (to translate serial communication to TCP/IP) and these reply to the multicast which cause the error event 4204 in the error log. One resolution could be to change the 40 minutes to a larger value as per ME151761.
Regarding ME151761, I've found on my Windows 2000 server (which was an upgrade from NT4) that the suggested timeout value of FFFFFFFF (something like 136 years) does not work, it still broadcasts every 40 minutes.
|Private comment: Subscribers only. See example of private comment|
|Links: ME134958, ME139782, ME151761, ME158865, MSW2KDB|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (0) - More links...|
Send comments or solutions
- Notify me when updated