References > Template Reference > Microsoft WINS > Microsoft Windows Internet Name Service (WINS) Events

Microsoft Windows Internet Name Service (WINS) Events

This template assesses the status and overall performance of a Microsoft WINS server by monitoring critical errors in the Windows Application Log file.

Prerequisites

WMI access to the target server.

Credentials

Windows Administrator on the target server.

Monitored Components

For details on monitors, see SAM Component Monitor Types.

All monitors should return values of zero. Returned values other than zero may indicate an abnormality. If you believe an abnormality exists, you should examine the Windows System log for details. Source name: WINS.

Network related events

This monitor returns the following events:

  • The Winsock send or receive function returned with an unexpected error;
  • The WinSock send function returned with an unexpected error;
  • WINS could not free a User Datagram Protocol (UDP) Buffer;
  • The WINS User Datagram Protocol (UDP) Listener thread encountered an error;
  • WINS encountered an error while processing a push trigger or update notification;
  • The WINS server cannot make or accept connections because the connections limit has been reached;
  • WINS tried to get its addresses but failed;
  • WINS did not get back any names from NetBIOS over TCP/IP (NetBT) when it did an adapter status;
  • The computer running the WINS server does not have a valid address;
  • WINS Push thread encountered an exception;
  • The Name Release or Query Response could not be sent due to an error;
  • INS could not send a User Datagram Protocol (UDP) message to a WINS client.

Event ID: 4210, 4211, 4219, 4246, 4283, 4286, 4291, 4292, 4301, 4242, 4188, 4189, 4208.

WINS encountered an error while processing a push trigger or update notification: check to see if the remote WINS that sent the trigger went down. If the remote WINS is on a different subnet, then maybe the router is down.

The WINS server cannot make or accept connections because the connections limit has been reached: Examine your replication topology, and make sure that you are configured for a true Hub-and-Spokes replication topology. Verify that there is not a TCP connection shortage. Before the TCP packet is sent, the computer verifies that it has sufficient resources, for example free outgoing TCP ports. To verify that there is not a TCP connection shortage, follow these steps: Run the following command on the failing computer (at the time that this computer is logging the event ID 4286 errors), and then save the output to a file. To do so, run the following command from a command prompt: netstat -a

Look for the total number of sessions and used ports, examine the state of the sessions to determine whether the number of sessions has reached the maximum value. By default, the maximum value is 5000.

The computer running the WINS server does not have a valid address: WINS binds to the first adapter in a machine with more than one adapter bound to TCP/IP. Check the binding order of adapters and make sure the first one has a valid IP address for the WINS server.

Other events: Try to restart your network adapter.

Low resources events

This monitor returns the following events:

  • WINS could not allocate a responder association;
  • WINS could not allocate an initiator association;
  • WINS could not allocate an implicit dialogue;
  • WINS could not allocate an explicit dialogue;
  • WINS could not allocate a User Datagram Protocol (UDP) Buffer;
  • WINS could not create a communication subsystem thread;
  • WINS encountered a low memory condition;
  • The WINS server started the burst handling of incoming requests.

Event ID: 4213, 4214, 4215, 4216, 4218, 4220, 4297, 4338.

For all of these events, check to see if the system is running out of memory.

Database related events

This monitor returns the number of events, such as:

  • WINS encountered a database error;
  • An error has prevented WINS from updating the WINS database, the database may be corrupt;
  • The static data file that is used to initialize the WINS database is too big;
  • WINS is trying to update the version number of a database record that it does not own;
  • WINS encountered an error doing a database backup to directory;
  • WINS has found some database corruption;
  • WINS could not start due to a missing or corrupt database;
  • WINS could not start because the existent database must be converted to the Windows 2000 format.

Event ID: 4224, 4254, 4258, 4275, 4289, 4302, 4311, 4318, 4319, 4320, 4322, 4323, 4324.

WINS encountered a database error: This may or may not be a serious error. WINS will try to recover from it. You can check the database error events under 'Application Log' category of the Event Viewer for the Exchange Component, ESENT, source to find out more details about database errors. If you continue to see a large number of these errors consistently over time (a span of few hours), you may want to restore the WINS database from a backup. The error number is in the second DWORD of the data section.

WINS is trying to update the version number of a database record that it does not own: This is a serious error if the WINS server is updating the record after a conflict. It is not a serious error if the WINS server is updating the record as a result of a request to do so from a remote WINS server (When a remote WINS server notices a conflict between an active owned entry and a replica it informs the owner of the replica to update the version number of the record. It is possible that the replica is no longer owned by the remote WINS). Check the previous log entry to determine which situation applies here.

WINS has found some database corruption: It will try to recover. This recovery process can take a long time. Do not kill WINS in the middle of the recovery. If you do, you will have to restart WINS with a clean database.

WINS could not start due to a missing or corrupt database: Restore the database using WINS Manager (or winscl.exe found in the Windows 2000 Resource Kit) and restart WINS. If WINS still does not start, begin with a fresh copy of the database. To do this: delete all the files in the %%SystemRoot%%\system32\WINS directory.

If the WINS database file (typically named wins.mdb) is not in the above directory, check the registry for the full filepath. Delete the .mdb file.

If jet*.log files are not in the above directory, check the registry for the directory path. Delete all log files. After that restart WINS.

WINS could not start because the existent database must be converted to the Windows 2000 format: If this is the first invocation of WINS after an upgrade From NT3.51, you need to run the convert utility (upg351db.exe in the %%SystemRoot%%\system32 directory) on the WINS database to convert it to the new database format. Once you have done that, you should restart WINS.

Corrupted WINS Database: In rare situations the WINS database may be corrupted. To recover from this situation, follow these steps:

  1. Stop replication.
  2. Delete the replication partners.
  3. Use the Jetpack tool on the database on the hub server.
  4. Reestablish replication, and then force a replication.
  5. Use the WINS Microsoft Management Console (MMC) to examine the consistency of the WINS database.
  6. In a large WINS environment where IP addresses constantly change, do not configure the Replicate on Address Change option on an NT4 WINS server. The equivalent setting on a Windows 2000 WINS server is the When Address Changes check box in the WINS snap-in. Click to clear the check box to restore the default setting.

Registry related events

This monitor returns the following events:

  • WINS could not get information about a key;
  • WINS could not get information about the Pull key;
  • WINS could not get information about the Push key;
  • INS could not get information about the DATAFILES key;
  • WINS could not get information about the SPEC_GRP_MASKS key;
  • WINS could not open a Pull subkey;
  • WINS could not open a Push subkey;
  • WINS could not close an open key;
  • WINS could not read the Refresh interval from the registry;
  • WINS could not read the Tombstone interval from the registry;
  • WINS could not read the Verify interval from the registry;
  • WINS could not read the retry count for retrying communication with a remote WINS;
  • WINS could not read the Tombstone Timeout from the registry;
  • WINS could not read the ConsistencyCheck value (type DWORD) from the Parameters\ConsistencyCheck subkey in the registry;
  • WINS could not read the MaxRecsAtATime value (type DWORD) in the Wins\Parameters\ConsistencyCheck subkey of the registry;
  • WINS could not read the UseRplPnrs value of the Wins\Parameters\ConsistencyCheck key.

Event ID: 4230, 4231, 4232, 4233, 4234, 4235, 4236, 4240, 4109, 4110, 4111, 4112, 4113, 4114, 4115, 4116.

WINS could not read the ConsistencyCheck value (type DWORD) from the Parameters\ConsistencyCheck subkey in the registry: The first consistency check is done at the time specified in the SpTime entry under the ConsistencyCheck subkey and is limited by the MaxRecsAtATime value. If the time is not specified, the check is done at 2 am. To correct the problem, open the registry and verify that the ConsistencyCheck subkey has been correctly sent up and all required values have been set. Correct the values as needed.

WINS could not read the MaxRecsAtATime value (type DWORD) in the Wins\Parameters\ConsistencyCheck subkey of the registry: Set this value if you do not want WINS to replicate more than a set number of records in one cycle while doing periodic consistency checks of the WINS database. When doing a consistency check, WINS replicates all records of an owner WINS by either going to that WINS or to a replication partner. At the end of doing a consistency check for an owner's records, it checks to see if it has replicated more than the specified value in the current consistency check cycle. If the value has been exceeded, the consistency check stops, otherwise it continues. In the next cycle, it starts from where it left off and wraps around to the first owner if required.

WINS could not read the UseRplPnrs value of the Wins\Parameters\ConsistencyCheck key: If this value is set to a non-zero (DWORD) value, WINS will do a consistency check of the owners in its database by going to one or more of its replication partners. If the owner of the records happens to be a replication partner, WINS will go to it, otherwise it will pick one at random. Set this value if you have a large number of WINSs in your configuration and/or if you do not want the local WINS to go to any WINS that is not a replication partner.

Other events: Check to see if the permissions on the key are set properly, system resources are low, or the registry is having a problem.

Operation events

This monitor returns the number of events, such as:

  • WINS received an error while trying to register a group's replica with name;
  • WINS received an error while trying to register a unique replica with name;
  • WINS received an error while trying to register the unique entry with the name;
  • WINS received an error while trying to register the group entry with the name;
  • WINS received an error while trying to update the version number of a record in the WINS database;
  • WINS received an error while trying to release a record in the WINS database;
  • WINS received an error while trying to query a record in the WINS database;
  • WINS encountered an error while deleting the file;
  • WINS encountered an error while deleting one or more records of a WINS;
  • WINS encountered an error while getting the browser names for a client.

Event ID: 4261, 4262, 4263, 4264, 4265, 4266, 4267, 4303, 4304, 4305.

Examine event in Event Viewer for details.

Replication events

This monitor returns the number of events, such as:

  • The WINS Replication Pull Handler could not connect to a WINS server;
  • WINS received a replica whose state is incorrect;
  • The WINS replicator Pull thread encountered an error while processing a request;
  • WINS received an error while registering replicas;
  • WINS's Replicator could not find any records in the WINS database;
  • The replication Pull or Push thread is shutting down due to an error.

Event ID: 4251, 4268, 4307, 4260, 4121, 4166, 4167.

The WINS Replication Pull Handler could not connect to a WINS server: Check network configuration.

The WINS replicator Pull thread encountered an error while processing a request: Check other log entries to determine what went wrong.

WINS received an error while registering replicas: It will not register any additional replicas of this WINS at this time (the address is in the data section 4th-8th byte). Check a previous log entry to determine the reason for this. If you get the same error during subsequent replication with the above partner WINS, you may want to restore the WINS database from the backup.

WINS's Replicator could not find any records in the WINS database: This means there are no active or tombstone records in the database. It could be that the records being requested by a remote WINS server have either been released or do not exist.

The replication Pull or Push thread is shutting down due to an error: Restart WINS.

Other events

This monitor returns the number of events, such as:

  • A WINS Remote Procedure Call (RPC) thread encountered an error;
  • The WINS TCP Listener thread encountered an error;
  • The WINS Scavenger thread encountered an error;
  • The WINS Challenger thread encountered an error;
  • A WINS worker thread encountered an error;
  • The Push Thread was requested for a range of records but could not find any records in the range;
  • The WINS Server could not initialize security to allow the read-only operations.

Event ID: 4244, 4245, 4247, 4248, 4249, 4227, 4337.

The Push Thread was requested for a range of records but could not find any records in the range: Make sure that the replication time intervals are set properly. If the tombstone interval and timeout intervals are not correct (that is, much less than the replication interval), the above condition is possible. This is because the records might get changed into tombstones and then deleted before the remote WINS can pull them. Similarly, if the refresh interval is set to be much less than the replication interval then the records could get released before a WINS can pull them (a released record is not sent). Make sure that the replication time intervals are set properly.

Other errors: Restart WINS.