The Repair feature is a powerful tool that is seldom used because it is not well understood. Accessing this feature is easy -- just right-click on a network connection in your Networking Connections folder (or on a connection icon in your system notification area) and select Repair from the shortcut menu.
When you do this, a dialog box opens and a series of messages appear showing the progress of the repair actions being taken. What happens under the hood here is that a series of command-line actions are being performed, and each progress message displayed indicates one of these actions has been performed.

Let's examine each of these steps that take place when you use Repair to understand what they do and why they are performed.

• Step 1: DHCP Renew

  This step only occurs if the network connection is configured to receive its address automatically using DHCP. If you've configured the connection manually with a static IP address and other TCP/IP settings, this step is skipped. The command-line action that is being performed here is similar to but not identical to the following familiar command:

  ipconfig /renew

  This command attempts to contact the DHCP server from which the computer's address has been previously leased. If the DHCP server can be contacted, the computer verifies its current TCP/IP configuration with the server to confirm that this configuration is valid.

  When this command is executed using the Repair feature, however, it behaves differently than when you run it from the command line. Instead of sending a unicast DHCP Renew message to the DHCP server from which the computer obtained its DHCP configuration, the command instead sends a broadcast DHCP Renew message to any available DHCP server on the network.
  The reason for this is that if the current TCP/IP configuration on the computer is invalid, the computer can attempt to obtain new TCP/IP settings from any available DHCP server by requesting a new address lease.

  The effect of performing this step of the Repair process is thus twofold:

  • It resolves DHCP configuration problems on the client, and
  • Resolves issues with not being able to contact a specific DHCP server on the network.
  TIP: You can prevent network problems resulting from DHCP server unavailability by implementing DHCP server redundancy on your network. For information about some different ways you can do this, see Ensuring DHCP Server availability. (Also see Troubleshooting a DHCP server)
• Step 2: Flush ARP Cache

  The command-line action that is being performed in this step is as follows:

  arp -d *

  This command flushes the contents of the Address Resolution Protocol (ARP) cache on the local computer. ARP is a protocol that is used to resolve IP addresses into media access control (MAC) addresses that are generally hardcoded into LAN adapters. The ARP cache contains recently resolved MAC addresses for IP nodes on the network.
  These MAC addresses are cached on the computer so that communications with these IP nodes can take place without needing to resolve them repeatedly.
  • If one or more of the entries in the ARP cache are incorrect, network communication may fail with some IP nodes on the network.
  • If the incorrect cache entry is for a node on the local subnet, communication with that node will fail.
  • If the incorrect cache entry is for the default gateway, communication with nodes on remote subnets will fail.
  The type of network communication failure experienced (whether nodes on the local subnet or on remote subnets) can thus provide an indication of which ARP cache entry is incorrect (provided incorrect ARP cache entries is actually the problem).
• Step 3: Flush NetBIOS Cache

  The command-line action that is being performed in this step is as follows:

  nbtstat -R

  This command flushes the contents of the NetBIOS cache on the local computer. Running this command also pre-loads any entries in the LMHOSTS file into the cache. On most Windows-based networks, including those on which Active Directory is deployed and DNS is used for name resolution, the legacy NetBIOS name resolution is still used for certain functions.

  As the NetBIOS names of remote hosts are resolved into their associated IP addresses, either by querying a WINS server or by using NetBIOS broadcasts, these hostname-to-IP-address mappings are added to the NetBIOS cache on the local computer so that communication with remote hosts can take place without needing to resolve them repeatedly.
  If one or more of the entries in the NetBIOS cache are incorrect, network communication may fail with some IP hosts on the network.
  If the incorrect cache entry is for a host on the local subnet, communication with that host will fail.
  If the incorrect cache entry is for the default gateway, communication with hosts on remote subnets will fail. The type of network communication failure experienced (whether hosts on the local subnet or on remote subnets) can thus provide an indication of which NetBIOS cache entry is incorrect (provided incorrect NetBIOS cache entries is actually the problem).

  Incorrect NetBIOS cache entries can sometimes be caused by stale entries in the WINS database on WINS servers. This is because WINS trumps NetBIOS broadcast name resolution when WINS has been implemented, so corrupt or stale WINS entries can repopulate the NetBIOS cache with incorrect entries even after the cache has been cleared. The solution in this case is to

  1. tombstone the incorrect records in the WINS database,
  2. flush the NetBIOS cache again and
  3. then monitor the cache using the

     nbtstat -c

     command to ensure these incorrect entries do not get cached again.
• Step 4: Flush DNS Resolver Cache

  The command-line action that is being performed in this step is as follows:

  ipconfig /flushdns

  This command flushes the contents of the DHS resolver cache on the local computer. Running this command also pre-loads any entries in the HOSTS file into the cache. As fully-qualified DNS names of remote hosts are resolved into their associated IP addresses by querying a name server (DNS server), these FQDN-to-IP-address mappings are added to the DNS resolver cache on the local computer so that communication with remote hosts can take place without needing to resolve them repeatedly. If one or more of the entries in the DNS resolver cache are incorrect, network communication may fail with some IP hosts on the network.

  To view the current contents of the DHS resolver cache, type

  ipconfig /displaydns

  at a command prompt.
  If the IP address of the remote host you are trying to resolve has recently changed, then you may not be able to connect with that host using its FQDN until you flush your DNS resolver cache. Of course, cache entries will time out by themselves using their specified TTLs obtained from the name server during name resolution, but if you notice that suddenly you can't connect to some remote host you could try repairing your network connection which flushes the DNS resolver cache like this.

• Step 5: Register again with WINS

  The command-line action that is being performed in this step is as follows:

  nbtstat -RR

  This command attempts to re-register the local computer in the WINS database on WINS servers. What this means is that all NetBIOS names for the local computer are first released and then renewed in the database. This is only useful of course if your network has WINS servers, but most enterprise environments that have Active Directory deployed and also have Exchange Server deployed generally still use WINS, see KB 837391 for more info.

  When a Windows computer is shut down properly, it should release its records from the WINS database. If a computer was not shut down properly, the WINS records for the computer are not removed from the database.
  Stale records in the WINS database can cause network communication problems, especially for portable computers like laptops that may be removed from one network and attached to another. Using the Repair feature can often resolve these problems by forcing the computer to re-register with WINS.

• Step 6: Register again with DNS

  The last command-line action that is performed when you use the Repair feature is this:

  ipconfig /registerdns

  This command attempts to re-register the local computer in the DNS database on name servers. What this means is that all DNS names for the local computer are first released and then renewed in the DNS database (assuming you have an Active Directory network that uses Dynamic DNS or DDNS for registering DNS names in the database).