When network connectivity problems occur with one or more Windows 9x systems on your network, you can begin your initial troubleshooting expedition with a tried-and-true DOS-based networking tool, the Microsoft Network Diagnostics utility. This often-overlooked utility is easy to use and will give you basic information about the health of the connection between systems on the network. I’ll show you how to use the Network Diagnostics program to troubleshoot network connectivity problems on a Windows 9x network. I’ll also explain how you can take full advantage of this command’s features.
Keep in mind that the Microsoft Network Diagnostics utility is designed only to check basic network communications between two systems on a local network segment. Furthermore, the Network Diagnostics utility is available only in Windows 95, 98, and Me—not in Windows NT, Windows 2000, or Windows XP.
The Network Diagnostics utility is basically a low-level real-mode network diagnostic tool whose origins can be traced back to the LAN Manager and Windows for Workgroups days. It shouldn’t shock you to learn that the utility is actually a component of the DOS-based Net command.
For the Network Diagnostics utility to work, each of the systems you plan to test must be running the same protocol or same set of protocols—NetBEUI, IPX/SPX-compatible, or TCP/IP. The utility will run successfully no matter what type or model of network adapters are in the systems being tested.
The Network Diagnostics utility is very easy to use. To begin, you’ll run the Network Diagnostics utility on one system and set it up to run as a diagnostic server that will wait for requests from other systems. You’ll then move to another system and run the Network Diagnostics utility as diagnostic client. Once you do, the diagnostic client will immediately begin scanning the network for a diagnostic server. If it finds one, the utility will run a simple test that involves sending a few data packets to the diagnostic server, waiting for a reply, and then verifying that the data packets did indeed come from the diagnostic server.
The Microsoft Network Diagnostics utility also has a couple of parameters that you can use. The first parameter, /Status, allows you to get more detailed network diagnostics information on a specific system. The second parameter, /Names, allows you to specify a custom name for your test.
Setting up a server
To set up a diagnostic server, open an MS-DOS Prompt window and type Net Diag at the command prompt. When the Microsoft Network Diagnostics utility launches, it will immediately begin checking to see what network protocols are running on the system.
For example, if both the NetBEUI and IPX/SPX protocols are running, in addition to TCP/IP, you’ll see a message prompting you to select a protocol, as shown in Figure A.
|If both of the supported protocols are running, you’ll be prompted to specify one.|
If only one of the protocols is running, or if one of the protocols is specifically configured as the default protocol, the Network Diagnostics utility will immediately begin searching the network for a diagnostics server using that protocol. Because this system will become the diagnostics server, the utility won’t find one. It will then display the message shown in Figure B, prompting you to confirm that currently there isn’t a diagnostic server running on the network.
|If only one of the supported protocols is running, the utility will immediately begin looking for a diagnostics server.|
When you press N, the Network Diagnostics utility will configure the current system as the diagnostics server, as shown in Figure C. At this point, you’ll leave this system alone and go to the other system on which you want to test the network connectivity.
Running the tests
Once you set up the diagnostic server, you’ll launch the Microsoft Network Diagnostics utility in diagnostic client mode on the other system. To do so, open an MS-DOS Prompt window and type Net Diag at the command prompt. When the Network Diagnostics utility launches, it will immediately begin checking to see what network protocols are running on the system. If it finds both NetBEUI and IPX/SPX protocols running, it will again prompt you to choose one. It’s important that you select the same protocol that you selected for the diagnostic server.
If only one protocol is running, the Network Diagnostics utility will begin searching the network for a diagnostic server, as shown in Figure D. If the system being configured as the client is only running one of the protocols, be sure that it’s running the same protocol as the system configured as the diagnostic server—otherwise, the test won’t run.
|If only one protocol is running, the utility will immediately begin searching for a diagnostic server.|
As soon as the Network Diagnostics utility locates a diagnostic server, it will alert you to that fact and immediately run the connectivity tests, as shown in Figure E.
|Once a diagnostic server is located, the testing begins.|
A successful test
If the test was successful, you’ll see a message to that effect, as shown in Figure F. The success of the test indicates that the two systems were able to communicate with each other.
|If the test is successful, the client will indicate that network information is being sent and received.|
You can verify this by returning to the system that is running as the diagnostic server. When you do, you should see that it is displaying a message indicating that it is indeed responding to the client, as shown in Figure G.
When a connectivity problem exists between the Network Diagnostics utility diagnostic server and the client, you’ll see one of two error messages. If the server was found but further communication was unsuccessful, you’ll see an error message like the one shown in Figure H. This will indicate some sort of high traffic situation.
|If the server can be found but can’t respond, chances are that the network is experiencing a high traffic situation.|
On the other hand, if the client can’t find the server, even after you press Y to acknowledge that one does in fact exist, you’ll see an error message like the one shown in Figure I. This message indicates that there is most likely a problem with a network card, its configuration, or the network cables.
|If the client is unable to communicate with the diagnostic server, there’s usually some sort of hardware problem.|
When you encounter a problem, your best bet is to repeat the test to ensure that everything was configured correctly the first time. For example, it’s possible that you selected the wrong protocol when you set up the diagnostic client. If both protocols are running on both systems, you can try repeating the test with the other protocol. You can also reverse the roles of the two systems and run the test again.
Getting more details
After you run the test, whether it’s a success or a failure, you may want to get more detailed information on exactly what occurred during the test. To do so, you can use the /Status parameter, which requires you to enter the name of the system and possibly the number associated with the protocol, as shown in Figure J.
As you can see, in this example, I pressed [Enter] to get information about the local system (you can get information about a remote system by typing just its name). Then, if more than one protocol is installed on the system, the Network Diagnostics utility will prompt you to enter the LANA number. If only one protocol is installed, you won’t be prompted for a LANA number.
The number 0 will always represent whatever protocol is specified as the default in the network configuration; 6 and 7 will represent the other protocols—TCP/IP and NetBIOS over IPX, but not necessarily in that order.
For more information on LANA numbers, see the Knowledge Base article “Determining LANA Numbers in Windows 95 (Q158781).”
Once you enter the LANA number, you’ll see a list of details, as shown in Figure K. Let’s take a closer look at the status report.
|The status report can help you pinpoint any problems on the network.|
The first line in the report tells you the MAC address assigned to the network adapter. The next line gives you information on how long the adapter has been running. Below that line, you’ll find details on the available Network Control Blocks (NCBs), which are used to pass NetBIOS commands on the network. As long as you have a large number of them available, there’s nothing to worry about. However, the maximum number of NCBs can be used to identify the protocol. In this case, NetBEUI is the default protocol and it uses 255 NCBs. TCP/IP uses 64 NCBs and NetBIOS over IPX uses 12 NCBs.
The next two lines indicate the number of open and allocated NetBIOS sessions. An open session is basically a communication channel between two systems. Keep in mind that two systems never have more than one session established with one another, regardless of the number of connections. If more than the total number of allocated sessions is needed, the NetBIOS provider will dynamically allocate more.
After the session information you’ll see details about the number of packets that have been transmitted and received since the adapter has been running. Two of the next three lines will indicate some interesting information about the operation of the network. Optimally, the number of retransmissions should be very low. A high number indicates a problem on the network resulting in damaged packets that can’t be recognized by the destination system and must be retransmitted after a time-out period.
Likewise, the number of collisions should be low. However, keep in mind that since Ethernet networks use CSMA/CD (Carrier Sense Multiple Access/Collision Detection), there will always be some collisions when more than one system is attempting to access the network at the same time. If the collision rate is high, say more than 10 percent, you definitely have an overloaded network as the source of your problems and you’ll want to think about rearranging your network configuration to better route your heavy traffic areas. CRC and alignment errors are only used by Macintosh systems.
The next section of the report is just the NetBIOS name table, which is used by any network service that uses the NetBIOS interface.
Naming your tests
If you’re consecutively running multiple instances of the Network Diagnostics diagnostic utility, you’ll need to use the /Names parameter to keep the tests from interfering with each other. To do so, specify the /Names parameter on the command line and provide a name when prompted to do so. Keep in mind that when you use the /Names parameter to set up a diagnostic server, you must use the same name when setting up the client.
The French connection
When you’re troubleshooting network connectivity problems on a Windows 9x network, the Network Diagnostics utility can provide you with some excellent diagnostic information. There is one glitch that you might need an interpreter for when using the utility. If you run the Network Diagnostic utility using the Net.exe file from the Windows NT 3.51 Server CD, the output will appear in French, according to the Microsoft Knowledge Base article Q136298. Having your systems updated to Windows NT 4 will mitigate any confusion.