Chapter 12 - Troubleshooting Tools and Strategies

Many excellent network troubleshooting tools are available for Windows NT Server and Windows NT Workstation. Most are included with the product or in the Windows NT Server and Windows NT Workstation Resource Kits. Microsoft Network Monitor is an excellent network tracing tool that is included in the Microsoft Systems Management Server product.

When troubleshooting any problem, it is helpful to use a logical approach. Some questions to ask are:

• What does work?

• What doesn't work?

• How are the things that do and don't work related?

• Have the things that don't work ever worked on this computer and network?

• If so, what has changed since they last worked?

Troubleshooting a problem "from the bottom up" is often a good way to quickly isolate it. The troubleshooting tasks discussed in this chapter are organized using this "bottom up" approach.

The first section of this chapter gives an overview of TCP/IP troubleshooting tools. The next section discusses various TCP/IP troubleshooting tasks, followed by a section on using Performance Monitor and Network Monitor to analyze network behavior. The final section of this chapter provides information about common TCP/IP networking problems.

Overview of TCP/IP Troubleshooting Tools
Identify the TCP/IP Configuration by Using IPConfig
Test Connection to the TCP/IP Network by Using Ping
Understanding Address and Name Resolution
Troubleshoot NetBIOS Name Resolution by Using NBTStat
Test IP-address-to-MAC-address Resolution by Using ARP
Understanding IP Routing for Windows NT
Examine the Route Between Network Connections by Using Tracert
Examine the Route Table by Using Route
Display Current TCP/IP Connections and Statistics by Using Netstat
Using Performance Monitor
Using the Microsoft Network Monitor
Using the Microsoft Knowledge Base
Troubleshooting Other Connection Problems

The following table lists the diagnostic utilities included with Microsoft TCP/IP that can be used to identify or resolve TCP/IP networking problems.

Table 12.1 TCP/IP Diagnostic Utilities

For complete details about the TCP/IP utilities, see Appendix A, "TCP/IP Utilities Reference."

These additional Windows NT tools can be used for TCP/IP troubleshooting:

• Microsoft SNMP service — provides statistical information to SNMP management systems

• Event Viewer — tracks errors and events

• Performance Monitor — analyzes TCP/IP and WINS server performance

• Registry Editor — allows viewing and editing of Registry parameters

In general, when troubleshooting it is usually best to first verify that the computer TCP/IP configuration is correct, and then verify that a connection and route exist between the computer and network host by using ping, as described in the section "Test Connection to the TCP/IP Network by Using Ping" later in this chapter.

Compile a list of what works and what doesn't work, and then study the list to help isolate the failure. If link reliability is in question, try a large number of pings of various sizes at different times of the day, and plot the success rate. When all else fails, using a protocol analyzer, such as Microsoft Network Monitor, can be helpful.

When troubleshooting a TCP/IP networking problem, begin by checking the TCP/IP configuration on the computer experiencing the problem. Use the ipconfig command to get the host computer configuration information, including the IP address, subnet mask, and default gateway. Ipconfig is a command-line utility that prints out the TCP/IP-related configuration of the local computer.

Note: Windows 95 users use winipcfg in place of ipconfig.

When ipconfig is used with the /all switch, it produces a detailed configuration report for all interfaces, including any configured serial ports (RAS). Ipconfig output may be redirected to a file and pasted into other documents. This output of ipconfig can be reviewed to find any problems in the computer network configuration. For example, if the computer has been configured with an IP address that is a duplicate of an existing IP address, the subnet mask will appear as 0.0.0.0.

The following example illustrates the results of an ipconfig/all command on a computer that is configured to use a DHCP server for automatic TCP/IP configuration, and WINS and DNS servers for name resolution:

    Windows NT IP Configuration
    Host Name . . . . . . . . . : davemac1.terraflora.com
    DNS Servers . . . . . . . . : 172.16.48.03
    Node Type . . . . . . . . . : Hybrid
    NetBIOS Scope ID. . . . . . :
    IP Routing Enabled. . . . . : No
    WINS Proxy Enabled. . . . . : No
    NetBIOS Resolution Uses DNS : No
    Ethernet adapter Elnk31:
    Description . . . . . . . . : ELNK3 Ethernet Adapter.
    Physical Address. . . . . . : 00-20-AF-1D-2B-91
    DHCP Enabled. . . . . . . . : Yes
    IP Address. . . . . . . . . : 172.16.48.10
    Subnet Mask . . . . . . . . : 255.255.248.0
    Default Gateway . . . . . . : 172.16.48.03
    DHCP Server . . . . . . . . : 172.16.48.03
    Primary WINS Server . . . . : 172.16.48.03
    Secondary WINS Server . . . : 172.16.48.03
    Lease Obtained. . . . . . . : Sunday, June 25, 1996 11:43:01 
    PM
    Lease Expires . . . . . . . : Wednesday, June 28, 1996 
    11:43:01 PM
    Ethernet adapter NdisWan5:
    Description . . . . . . . . :
    Physical Address. . . . . . : 00-00-00-00-00-00
    DHCP Enabled. . . . . . . . : No
    IP Address. . . . . . . . . : 0.0.0.0
    Subnet Mask . . . . . . . . : 0.0.0.0
    Default Gateway . . . . . . :

If no problems appear in the TCP/IP configuration, the next step is to test the ability to connect to other host computers on the TCP/IP network.

Ping is a tool that helps to verify IP-level connectivity. When troubleshooting, the ping command is used to send an ICMP echo request to a target host name or IP address. Use ping whenever you need to verify that a host computer can connect to the TCP/IP network and network resources. You can also use the ping utility to isolate network hardware problems and incompatible configurations.

It is usually best to verify that a route exists between the local computer and a network host by first using ping and the IP address of the network host to which you want to connect. First try pinging the IP address of the target host to see if it will respond, because this is the simplest case. The command syntax is:

ping IP_address

Perform the following steps when using ping:

1. Ping the loopback address to verify that TCP/IP is installed and configured correctly on the local computer.

Ping 127.0.0.1

2. Ping the IP address of the local computer to verify that it was added to the network correctly.

Ping IP_address_of_local_host

3. Ping the IP address of the default gateway to verify that the default gateway is functioning and that you can communicate with a local host on the local network.

Ping IP_address_of_default_gateway

4. Ping the IP address of a remote host to verify that you can communicate through a router.

Ping IP_address_of_remote_host

Ping uses Windows Sockets-style name resolution to resolve a computer name to an IP address, so if pinging by address succeeds, but fails by name, then the problem lies in address or name resolution, not network connectivity. Refer to the section "Test IP-address-to-MAC-address Resolution by Using ARP" later in this chapter.

If you cannot use ping successfully at any point, check the following:

• The computer was restarted after TCP/IP was installed and configured.

• The local computer's IP address is valid and appears correctly in the IP Address tab of the Microsoft TCP/IP Properties dialog box.

• IP routing is enabled and the link between routers is operational.

Type ping -? to see what command-line options are available. For example, ping allows you to specify the size of packets to use, how many to send, whether to record the route used, what time-to-live (TTL) value to use, and whether to set the "don't fragment" flag.

The following example illustrates how to send two pings, each 1450 bytes in size, to address 172.16.48.10:

C:\>ping -n 2 -l 1450 172.16.48.10
Pinging 172.16.48.10 with 1450 bytes of data: 

Reply from 172.16.48.10: bytes=1450 time=10ms TTL=32
Reply from 172.16.48.10: bytes=1450 time=10ms TTL=32

By default, ping waits only 750 ms for each response to be returned before timing out. If the remote system being pinged is across a high-delay link such as a satellite link, responses could take longer to be returned. The -w (wait) switch can be used to specify a longer timeout.

TCP\IP under Windows NT allows a computer to communicate over a network with another computer by using any of the following:

• IP address

• Host name

• NetBIOS name

If you get the correct response when using ping with an IP address but an incorrect response when using ping with the host name or NetBIOS name, you have a name resolution problem. The following sections describe the processes that occur when using a host name or a NetBIOS name, instead of an IP address, to connect with hosts on a TCP/IP network.

A DNS server or the HOSTS file is used when you use the TCP/IP utilities, such as ping. You can find the HOSTS file in the winnt\system32\drivers\etc directory. This file is not dynamic; entries are made manually. The format of the file is the following:

IP Address Friendly Name

172.16.48.10jsmith_nt   # Remarks are denoted with a #.

Host Name Resolution Using a HOSTS File

The general process that occurs when using the HOSTS file for name resolution is summarized in the following steps.

1. Computer A enters a command using the host name of Computer B.

2. The HOSTS file on Computer A (in the \Systemroot\System32\Drivers\Etc directory) is parsed. When the host name of Computer B is found, it is resolved to an IP address.

3. The Address Resolution Protocol (ARP) is then used to resolve the IP address of Computer B to its hardware address. If Computer B is on the local network, its hardware address will be obtained by using the ARP cache or by sending a local broadcast asking for a reply from Computer B with its hardware address. If Computer B is on a remote network, ARP will determine the hardware address of the default gateway for routing to Computer B.

Note: Host name resolution using a Domain Name System (DNS) server is similar to the preceding steps. Instead of parsing the HOSTS file in Step 2, the DNS server looks up the host name of Computer B in its database and resolves it to an IP address.

The following types of problems can occur because of errors related to the HOSTS file:

• The HOSTS file or the DNS server does not contain the particular host name.

• The host name in the HOSTS file or in the command is misspelled or uses different capitalization. (Host names are case-sensitive.)

• An invalid IP address is entered for the host name in the HOSTS file.

• The HOSTS file contains multiple entries for the same host on separate lines; if so, the first entry is the one that is used.

• A mapping for a computer name-to-IP-address was mistakenly added to the HOSTS file (rather than LMHOSTS).

NetBIOS over TCP/IP (NetBT) resolves NetBIOS names to IP addresses. TCP/IP provides many options for NetBIOS name resolution, including local cache lookup, WINS server query, broadcast, DNS server query, and LMHOSTS and HOSTS lookup.

Nbtstat is a useful tool for troubleshooting NetBIOS name resolution problems. The nbstat command allows for removing or correcting preloaded entries.

• nbtstat - n displays the names that were registered locally on the system by applications such as the server and redirector.

• nbtstat -c shows the NetBIOS name cache, which contains name-to-address mappings for other computers.

• nbtstat -R purges the name cache and reloads it from the LMHOSTS file.

• nbtstat -a <name> performs a NetBIOS adapter status command against the computer specified by name. The adapter status command returns the local NetBIOS name table for that computer plus the MAC address of the adapter card.

• nbtstat -S lists the current NetBIOS sessions and their status, including statistics, as shown in the following example:

NetBIOS Connection Table

DAVEMAC1 <00> Connected Out CNSSUP1<20> 6MB 5MB DAVEMAC1 <00> Connected Out CNSPRINT<20> 108KB 116KB DAVEMAC1 <00> Connected Out CNSSRC1<20> 299KB 19KB DAVEMAC1 <00> Connected Out STH2NT<20> 324KB 19KB DAVEMAC1 <03> Listening

TCP\IP under Windows NT allows a computer to communicate over a network with another computer by using either an IP address, a host name, or a NetBIOS name. However, when one computer attempts to communicate with another computer using one of these three naming conventions, that name must ultimately be resolved to a hardware address, the medium access control (MAC) address.

The Address Resolution Protocol (ARP) allows a host to find the MAC address of a destination host on the same physical network, given the destination host's IP address. To make ARP efficient, each computer caches IP-to-MAC address mappings to eliminate repetitive ARP broadcast requests.

The arp command allows a user to view and modify the ARP table entries on the local computer. The arp command is useful for viewing the ARP cache and resolving address resolution problems.

Windows NT supports routing on both single- and multi-homed computers with, and without, the Multi-Protocol Router (MPR). MPR includes Routing Information Protocol (RIP) for TCP/IP and RIP for IPX. Routers use RIP to dynamically exchange routing information. RIP routers broadcast their routing tables every 30 seconds by default. Other RIP routers will listen for these RIP broadcasts and update their own route tables.

This section provides information about the Windows NT-based route table as used on single- and multi-homed computers with, and without, MPR. This background information will help with TCP/IP troubleshooting.

Even a single-homed TCP/IP host has to make routing decisions. The route table controls these routing decisions. You can display the route table by typing route print at the command prompt. The following is an example route table from a single-homed machine. Windows NT automatically builds this simple route table based on the IP configuration of your host.

Network Address   Netmask          Gateway Address  Interface       Metric

0.0.0.0           0.0.0.0          172.16.16.1      172.16.48.169      1
127.0.0.0         255.0.0.0        127.0.0.1        127.0.0.1          1
172.16.16.0       255.255.248.0    172.16.16.169    172.16.16.169      1
172.16.48.169     255.255.255.255  127.0.0.1        127.0.0.1          1
172.16.255.255    255.255.255.255  172.16.48.169    172.16.48.169      1
224.0.0.0         224.0.0.0        172.16.48.169    172.16.48.169      1
255.255.255.255   255.255.255.255  172.16.48.169    172.16.48.169      1

Network Address

The network address in the route table is the destination address. The network address column can contain:

• Host address

• Subnet address

• Network address

• Default gateway

Netmask

The netmask defines which portion of the network address must match in order for that route to be used. When the mask is written in binary, a 1 is significant (must match) and a 0 need not match. For example, a 255.255.255.255 mask is used for a host entry.

The mask of all 255s (all 1s) means that the destination address of the packet to be routed must exactly match the network address in order for this route to be used. For another example, the network address 172.16.48.0 has a netmask of 255.255.192.0. This netmask means that the first two octets must match exactly, the first 2 bits of the third octet must match (192=11000000), and the last octet does not matter. Because 18 in the decimal number system is equivalent to 00110000 in binary, a match would have to start with 0011. Thus, any address of 172.16 and the third octet of 48 through 255 (255=11111111) will use this route. This is a netmask for a subnet route and is therefore called the subnet mask.

Gateway Address

The gateway address is where the packet needs to be sent. This can be the local network card or a gateway (router) on the local subnet.

Interface

The interface is the address of the network card over which the packet should be sent out. 127.0.0.1 is the software loopback address.

Metric

The metric is the number of hops to the destination. Anything on the local LAN is one hop, and each router crossed after that is an additional hop. The metric is used to determine the best route.

Multihomed Router

The following is the default route table of a multihomed Windows NT host:

To enable routing, check Enable IP Forwarding on the Routing tab of the Microsoft TCP/IP Properties dialog box. At this point, Windows NT will route between these two subnets.

A note on default gateways: in the TCP/IP configuration, you can add a default route for each network card. This will create a 0.0.0.0 route for each. However, only one default route will actually be used. In this case, the 199.199.40.139 is the first card in the TCP/IP bindings, and therefore the default route for this card is used. Because only one default gateway will be used, configure only one card to have a default gateway. This will reduce confusion and ensure the results you intended.

If the Windows NT router does not have an interface on a given subnet, it will need a route to get there. This can be done by adding static routes or by using MPR.

Adding a Static Route

The following is an example route.

Route Add 199.199.41.0 mask 255.255.255.0 199.199.40.1 metric 2

The route in this example means that to get to the 199.199.41.0 subnet with a mask of 255.255.255.0, use gateway 199.199.40.1, and that the gateway is 2 hops away. A static route will also need to be added on the next router, telling it how to get back to subnets reachable by the first router. With a network of a few routers or more, static routes can become very complicated.

Tracert is a route tracing utility. Tracert uses the IP TTL field and ICMP error messages to determine the route from one host to another through a network. Sample output from the tracert command is shown in the ICMP section of this chapter.

Route is used to view or modify the route table. Route print displays a list of current routes known by IP for the host, including routes that Windows NT creates by default and routes learned by running RIP. Sample output is shown in the IP section of this chapter. Route add is used to add routes to the table, and route delete is used to delete routes from the table. Note that routes added to the table are not made permanent unless the -p switch is specified. Non-persistent routes last only until the computer is restarted.

In order for two hosts to exchange IP datagrams, they must both have a route to each other, or use default gateways that know of a route. Normally, routers exchange information with each other using a protocol such as RIP.

Netstat displays protocol statistics and current TCP/IP connections. Netstat -a displays all connections, and netstat -r displays the route table plus active connections. The -n switch tells netstat not to convert addresses and port numbers to names. The following is sample output:

 C:\>netstat -e
 Interface Statistics

 Received      Sent
 Bytes  3995837940    47224622
 Unicast packets        120099        131015
 Non-unicast packets    7579544       3823
 Discards               0             0
 Errors                 0             0
 Unknown protocols      363054211

 C:\>netstat -a

 Active Connections
 
 Proto Local Address  Foreign Address   State
 TCP  davemac1:1572  172.16.48.10:nbsession ESTABLISHED
 TCP  davemac1:1589  172.16.48.10:nbsession ESTABLISHED
 TCP  davemac1:1606  172.16.105.245:nbsession ESTABLISHED
 TCP  davemac1:1632  172.16.48.213:nbsession ESTABLISHED
 TCP  davemac1:1659  172.16.48.169:nbsession ESTABLISHED
 TCP  davemac1:1714  172.16.48.203:nbsession ESTABLISHED
 TCP  davemac1:1719  172.16.48.36:nbsession ESTABLISHED
 TCP  davemac1:1241  172.16.48.101:nbsession ESTABLISHED
 UDP  davemac1:1025  *:*
 UDP  davemac1:snmp *:*
 UDP  davemac1:nbname  *:*
 UDP  davemac1:nbdatagram *:*
 UDP  davemac1:nbname     *:*
 UDP  davemac1:nbdatagram *:*
 
 C:\>netstat -s
 IP Statistics
 
 Packets Received             = 5378528
 Received Header Errors       = 738854
 Received Address Errors      = 23150
 Datagrams Forwarded          = 0
 Unknown Protocols Received   = 0
 Received Packets Discarded   = 0
 Received Packets Delivered   = 4616524
 Output Requests              = 132702
 Routing Discards             = 157
 Discarded Output Packets     = 0
 Output Packet No Route       = 0
 Reassembly Required          = 0
 Reassembly Successful             = 0
 Reassembly Failures               = 0
 Datagrams Successfully Fragmented = 0
 Datagrams Failing Fragmentation   = 0
 Fragments Created                 = 0
 
 ICMP Statistics
 Received  Sent
 Messages                 693       4
 Errors                   0         0
 Destination Unreachable  685       0
 Time Exceeded            0         0
 Parameter Problems       0         0
 Source Quenchs           0         0
 Redirects                0         0
 Echos                    4         0
 Echo Replies             0         4
 Timestamps               0         0
 Timestamp Replies        0         0
 Address Masks            0         0
 Address Mask Replies     0         0
 
 TCP Statistics
 
 Active Opens                 = 597
 Passive Opens                = 135
 Failed Connection Attempts   = 107
 Reset Connections            = 91
 Current Connections          = 8
 Segments Received            = 106770
 Segments Sent                = 118431
 Segments Retransmitted       = 461
 UDP Statistics
 
 Datagrams Received   = 4157136
 No Ports             = 351928
 Receive Errors       = 2
 Datagrams Sent       = 13809

The Windows NT Server and Windows NT Workstation Performance Monitor can be used to view many different TCP/IP-related counters. Because it accesses statistics that have been gathered by the SNMP service, the SNMP service must be installed on Windows NT-based computers where TCP/IP statistics are to be monitored. Performance Monitor counters are available for NIC, IP, ICMP, UDP, TCP, and NetBT.

One of the features of Performance Monitor is that it allows counters from various systems to be monitored from a single management window. It also supports setting alert levels for the counters being monitored.

Microsoft Network Monitor is a tool developed by Microsoft to make the task of troubleshooting complex network problems much easier and more economical. It is packaged as part of the Microsoft Systems Management Server product but can be used as a stand-alone network monitor.

In addition, Windows NT Server, Windows NT Workstation, and Windows 95 distribution media include the Network Monitor Agent software. Stations running Network Monitor can attach to stations running the agent software over the network or using dial-up (RAS) to perform monitoring or tracing of remote network segments. This can be a very useful troubleshooting tool.

Network Monitor works by setting the NIC to allow you to capture traffic to and from the local computer. Capture filters can be defined so that only specific frames are saved for analysis. Filters can be defined based on source and destination NIC addresses, source and destination protocol addresses, and pattern matches. Once a capture has been obtained, display filtering can be used to further narrow down a problem. Display filtering allows specific protocols to be selected as well.

Once a capture has been obtained and filtered, Network Monitor protocol parsing interprets the binary trace data into readable terms using parsing DLLs. The following sample Server Message Block (SMB) frame is shown fully parsed:

_***************************************************************_
   Frame Time  Src Other Addr Dst Other Addr Protocol 
   Description                      
   7     0.020 172.16.48.36    172.16.48.10   SMB      
   C get attributes, 
   File = \temp 

   FRAME: Base frame properties
   FRAME: Time of capture = Jun 27, 1995 8:11:11.636
   FRAME: Time delta from previous physical frame: 3 
   milliseconds
   FRAME: Frame number: 7
   FRAME: Total frame length: 106 bytes
   FRAME: Capture frame length: 106 bytes
   FRAME: Frame data: Number of data bytes remaining 
   = 106 (0x006A)
   ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD 
   Internet Protocol
   ETHERNET: Destination address : 00608C0E6C6A
   ETHERNET: .......0 = Individual address
   ETHERNET: ......0. = Universally administered address
   ETHERNET: Source address : 0020AF1D2B91
   ETHERNET: .......0 = No routing information present
   ETHERNET: ......0. = Universally administered address
   ETHERNET: Frame Length : 106 (0x006A)
   ETHERNET: Ethernet Type : 0x0800 
   (IP: DOD Internet Protocol)
   ETHERNET: Ethernet Data: Number of data bytes 
   remaining = 92 (0x005C)
   IP: ID = 0x4072; Proto = TCP; Len: 92
   IP: Version = 4 (0x4)
   IP: Header Length = 20 (0x14)
   IP: Service Type = 0 (0x0)
   IP: Precedence = Routine
   IP: ...0.... = Normal Delay
   IP: ....0... = Normal Throughput
   IP: .....0.. = Normal Reliability
   IP: Total Length = 92 (0x5C)
   IP: Identification = 16498 (0x4072)
   IP: Flags Summary = 2 (0x2)
   IP: .......0 = Last fragment in datagram
   IP: ......1. = Cannot fragment datagram
   IP: Fragment Offset = 0 (0x0) bytes
   IP: Time to Live = 32 (0x20)
   IP: Protocol = TCP - Transmission Control
   IP: CheckSum = 0xC895
   IP: Source Address = 09.48.16.172
   IP: Destination Address = 172.16.48.10
   IP: Data: Number of data bytes remaining = 72 (0x0048)
   TCP: .AP..., len:  52, seq: 344830227, ack:  
   2524988, win: 8166, src:
     1677 dst: (NBT Session) 
   TCP: Source Port = 0x068D
   TCP: Destination Port = NETBIOS Session Service
   TCP: Sequence Number = 344830227 (0x148DB113)
   TCP: Acknowledgment Number = 2524988 (0x26873C)
   TCP: Data Offset = 20 (0x14)
   TCP: Reserved = 0 (0x0000)
   TCP: Flags = 0x18 : .AP...
   TCP: ..0..... = No urgent data
   TCP: ...1.... = Acknowledgement field significant
   TCP: ....1... = Push function
   TCP: .....0.. = No Reset
   TCP: ......0. = No Synchronize
   TCP: .......0 = No Fin
   TCP: Window = 8166 (0x1FE6)
   TCP: CheckSum = 0xC072
   TCP: Urgent Pointer = 0 (0x0)
   TCP: Data: Number of data bytes remaining =
    52 (0x0034)
   NBT: SS: Session Message, Len: 48
   NBT: Packet Type = Session Message
   NBT: Packet Flags = 0 (0x0)
   NBT: .......0 = Add 0 to Length
   NBT: Packet Length = 48 (0x30)
   NBT: SS Data: Number of data bytes remaining = 
   48 (0x0030)
   SMB: C get attributes, File = \temp
   SMB: SMB Status = Error Success
   SMB: Error class = No Error
   SMB: Error code = No Error
   SMB: Header: PID = 0xCAFE TID = 0x0800 MID =
    0x43C0 UID = 0x0800
   SMB: Tree ID   (TID) = 2048 (0x800)
   SMB: Process ID  (PID) = 51966 (0xCAFE)
   SMB: User ID   (UID) = 2048 (0x800)
   SMB: Multiplex ID (MID) = 17344 (0x43C0)
   SMB: Flags Summary = 24 (0x18)
   SMB: .......0 = Lock & Read and Write & 
   Unlock not supported
   SMB: ......0. = Send No Ack not supported
   SMB: ....1... = Using caseless pathnames
   SMB: ...1.... = Canonicalized pathnames
   SMB: ..0..... = No Opportunistic lock
   SMB: .0...... = No Change Notify
   SMB: 0....... = Client command
   SMB: flags2 Summary = 32771 (0x8003)
   SMB: ...............1 = Understands long filenames
   SMB: ..............1. = Understands extended attributes
   SMB: ..0............. = No paging of IO
   SMB: .0.............. = Using SMB status codes
   SMB: 1............... = Using UNICODE strings
   SMB: Command = C get attributes
   SMB: Word count = 0
   SMB: Byte count = 13
   SMB: Byte parameters
   SMB: Path name = \temp
   
   00000: 00 60 8C 0E 6C 6A 00 20 AF 1D 2B
   91 08 00 45 00  .`..lj. ..+...E.
   00010: 00 5C 40 72 40 00 20 06 C8 95 9D 
   39 09 8A 9D 39  .\@r@. ....9...9
   00020: 0D 98 06 8D 00 8B 14 8D B1 13 00 
   26 87 3C 50 18  ...........&.<P.
   00030: 1F E6 C0 72 00 00 00 00 00 30 FF 
   53 4D 42 08 00  ...r.....0.SMB..
   00040: 00 00 00 18 03 80 00 00 00 00 00 
   00 00 00 00 00  ................
   00050: 00 00 00 08 FE CA 00 08 C0 43 00 
   0D 00 04 5C 00  .........C....\.
   00060: 74 00 65 00 6D 00 70 00 00 00
              t.e.m.p...   

The preceding parsed output example consists of three sections:

• summary window

• detailed description window

• hex output

If you are sending traces to support personnel at Microsoft, they are most useful in electronic form rather than printed form, because they can be manipulated and scanned electronically. Large printed traces are time-consuming to read.

The Microsoft Knowledge Base (KB) is an excellent source of information on all aspects of Windows NT Server and Windows NT Workstation. It contains thousands of articles written by the support professionals in the Corporate Network Systems unit at Microsoft. Articles are updated daily, and topics include:

• Installation and configuration information

• Status on known problems and fixes

• Service Pack updates

• Technology discussions

• Troubleshooting tips

• Hardware-specific information

For example, to find additional information about the LMHOSTS file in Windows NT, query on the following words in the Microsoft Knowledge Base:

lmhosts and windows and nt

The Microsoft KB is available from many different sources, including the Internet (full-text search capabilities for WWW browsers on www.microsoft.com), several on-line services, and CD-ROM subscription services, such as Microsoft TechNet.

This section presents some possible TCP/IP symptoms with recommendations for using the diagnostic utilities to determine the source of the problems.

To determine the cause of Error 53 when connecting to a server

1. If the computer is on the local subnet, confirm that the name is spelled correctly and that the target computer is running TCP/IP as well. If the computer is not on the local subnet, be sure that its name and IP address mapping are available in the LMHOSTS file or the WINS database.

   Error 53 is returned if name resolution fails for a particular computer name.

2. If all TCP/IP elements appear to be installed properly, use ping with the remote computer to be sure that its TCP/IP software is working.

To determine the cause of long connect times after adding an entry to LMHOSTS

• Because this behavior can occur with a large LMHOSTS file with an entry at the end of the file, mark the entry in LMHOSTS as a preloaded entry by following the mapping with the #PRE tag. Then use the nbtstat -R command to update the local name cache immediately.

  Or, place the mapping higher in the LMHOSTS file.

  As discussed in Chapter 10, "Using LMHOSTS Files," the LMHOSTS file is parsed sequentially to locate entries without the #PRE keyword. Therefore, you should place frequently used entries near the top of the file and place the #PRE entries near the bottom.

To determine the cause of connection problems when specifying a server name

• Use the nbtstat -n command to determine what name the server registered on the network.

  The output of this command lists several names that the computer has registered. A name resembling the computer's computer name should be present. If not, try one of the other unique names displayed by nbtstat.

  The nbtstat utility can also be used to display the cached entries for remote computers from either #PRE entries in LMHOSTS or recently resolved names. If the name the remote computers are using for the server is the same, and the other computers are on a remote subnet, be sure that they have the computer's mapping in their LMHOSTS files.

To determine why only IP addresses but not host names work for connections to remote computers

1. Make sure that the appropriate HOSTS file and DNS setup have been configured for the computer by checking the host name resolution configuration using the Network icon in Control Panel and then choosing the DNS tab in the Microsoft TCP/IP Properties dialog box.

2. If you are using a HOSTS file, make sure that the name of the remote computer is spelled the same and capitalized the same in the file and by the application using it.

3. If you are using DNS, be sure that the IP addresses of the DNS servers are correct and in the proper order. Use ping with the remote computer by typing both the host name and IP address to determine whether the host name is being resolved properly.

To determine why a TCP/IP connection to a remote computer is not working properly

• Use the netstat -a command to show the status of all activity on TCP and UDP ports on the local computer.

  The state of a good TCP connection is usually established with 0 bytes in the send and receive queues. If data is blocked in either queue or if the state is irregular, there is probably a problem with the connection. If not, you are probably experiencing network or application delay.

To determine why the banner displayed with Telnet identifies a different computer, even when specifying the correct IP address

1. Make sure the DNS name and HOSTS table are up to date.

2. Make sure that two computers on the same network are not mistakenly configured with the same IP address.

   The Ethernet and IP address mapping is done by the ARP module, which believes the first response it receives. Therefore, the impostor computer's reply sometimes comes back before the intended computer's reply.

   These problems are difficult to isolate and track down. Use the arp -g command to display the mappings in the ARP cache. If you know the Ethernet address for the intended remote computer, you can easily determine whether the two match. If not, use arp -d to delete the entry; then use ping with the same address (forcing an ARP), and check the Ethernet address in the cache again by using arp -g.

   Chances are that if both computers are on the same network, you will eventually get a different response. If not, you might have to filter the traffic from the impostor host to determine the owner or location of the system.

To determine the cause of the message, "Your default gateway does not belong to one of the configured interfaces..." during Setup

• Find out whether the default gateway is located on the same logical network as the computer's network adapter by comparing the network ID portion of the default gateway's IP address with the network ID(s) of any of the computer's network adapters.

  For example, a computer with a single network adapter configured with an IP address of 102.54.0.1 and a subnet mask of 255.255.0.0 would require that the default gateway be of the form 102.54.a.b because the network ID portion of the IP interface is 102.54.

The following table lists the UNIX-style database files that are stored in the \systemroot\System32\Drivers\Etc directory when you install Microsoft TCP/IP:

Table 12.2 UNIX-style Database Files

To troubleshoot any of these files on a local computer:

• Make sure the format of entries in each file matches the format defined in the sample file originally installed with Microsoft TCP/IP.

• Check for spelling or capitalization errors.

• Check for invalid IP addresses and identifiers.

When you attempt to reinstall a TCP\IP service, the following error message may appear:

The Registry Subkey Already Exists.

To correct this problem, ensure that all the components of a given TCP\IP service are properly removed and then remove the appropriate registry subkeys.

Warning: Using Registry Editor incorrectly can cause serious, system-wide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the incorrect use of Registry Editor can be solved. Use this tool at your own risk.

Connectivity Utilities

If you have removed the TCP/IP service components, you must also remove the following registry subkeys:

HKEY_LOCAL_MACHINE \Software \Microsoft \NetBT
HKEY_LOCAL_MACHINE \Software \Microsoft \Tcpip
HKEY_LOCAL_MACHINE \Software \Microsoft \TcpipCU
HKEY_LOCAL_MACHINE \SYSTEM \CCS \Services \DHCP
HKEY_LOCAL_MACHINE \SYSTEM \CCS \Services \LMHosts
HKEY_LOCAL_MACHINE \SYSTEM \CCS \Services'NetDriver'\Parameters\Tcpip
HKEY_LOCAL_MACHINE \SYSTEM \CCS \Services \NetBT

SNMP Service

If you have removed the SNMP service components, you must also remove the following registry subkeys:

HKEY_LOCAL_MACHINE \Software \Microsoft \RFC1156Agent
HKEY_LOCAL_MACHINE \Software \Microsoft \Snmp
HKEY_LOCAL_MACHINE \System \CCS \Services \Snmp

TCP\IP Network Printing Support

If you have removed the LPDSVC line printer service components, you must also remove the following registry subkeys:

HKEY_LOCAL_MACHINE \Software \Microsoft \Lpdsvc
HKEY_LOCAL_MACHINE \Software \Microsoft \TcpPrint
HKEY_LOCAL_MACHINE \SYSTEM \CCS \Services \LpdsvcSimple TCP\IP Services

If you have removed the simple TCP/IP services components, you must also remove the following registry subkeys:

HKEY_LOCAL_MACHINE \Software \Microsoft \SimpTcp
HKEY_LOCAL_MACHINE \SYSTEM \CCS \Services \SimpTcp

DHCP Server Service

If you have removed the DHCP Server service components, you must also remove the following registry subkeys:

HKEY_LOCAL_MACHINE \Software \Microsoft \DhcpMibAgent
HKEY_LOCAL_MACHINE \Software \Microsoft \DhcpServer
HKEY_LOCAL_MACHINE \SYSTEM \CCS \Services \DhcpServer

WINS Server Service

If you have removed the WINS Server service components, you must also remove the following registry subkeys:

HKEY_LOCAL_MACHINE \Software \Microsoft \Wins
HKEY_LOCAL_MACHINE \Software \Microsoft \WinsMibAgent
HKEY_LOCAL_MACHINE \SYSTEM \CCS \Services \Wins

This problem occurs if you have Use default gateway on remote network selected under TCP/IP settings in the RAS Phonebook. This feature adds a route to the route table, and the new route allows IP addresses that are not resolved by other entries in the route table to be routed to the gateway on the RAS link. However, to use Internet utilities, such as a WEB browser or FTP, this feature must be enabled.

To ping or otherwise connect to computers in a remote subnet across a router while you are connected as a RAS client to a remote Windows NT RAS Server

• Use the route add command to add the route of the subnet you are attempting to use and tie that route to the local LAN gateway by adding the appropriate subnet mask.