The Troubleshooter's Resources Networking

In the process of troubleshooting a workstation, a server, or other network component, you have many resources at your disposal. In this section, we’ll take a brief look at some of them. Those you use depend on the situation and your personal preferences. You will eventually have your own favorites.

Log Files

log files can indicate the general health of a server. Each log file format is different, but generally speaking, the log files contain a running list of all errors and notices, the time and date they occurred, and any other pertinent information. Let’s look at a couple of the log files from the most commonly used network operating systems, NetWare 5 and Windows 2000 Server.

NetWare Log Files

NetWare uses three log files that can help you diagnose problems on a NetWare server:

  • The Console Log file (CONSOLE.LOG)
  • The Abend Log file (ABEND.LOG)
  • The Server Log file (SYS$LOG.ERR)

Each file has different uses in the troubleshooting process.

The Console Log file

The Console Log file (CONSOLE.LOG) keeps a history of all errors that have occurred and information that has been displayed on the server’s console. It is located in the SYS:ETC directory on the server and is created and maintained by the utility CONLOG.NLM, which comes with Net- Ware versions 3.12 and later. You must load this utility manually (or place the load command in the AUTOEXEC.NCF file so that it starts automatically upon server startup) by typing the following at the console prompt:


Once this utility is loaded, it erases whatever CONSOLE.LOG file currently exists and starts logging to the new file.

we can tell that someone edited the AUTO-EXEC.NCF file and then restarted the server. This indicates a major change on the server. If we were trying to troubleshoot a server that was starting to exhibit strange problems after a recent reboot, this might be a source to check.

A sample CONSOLE.LOG file

A sample CONSOLE.LOG file

The Abend Log File

This log file registers all Abends on a NetWare server. An Abend (ABnormal END) is an error condition that can halt the proper operation of the NetWare server. Abends can be serious enough to lock the server, or they can simply force an NLM to shut down. You know an Abend has occurred when you see an error message that contains the word Abend on the console. Additionally, the server command prompt will include a number in angle brackets (for example, <1>) that indicates the number of times the server has Abended since it was brought online.

Because the server may reboot after an Abend, these error messages and what they mean can be lost. NetWare versions 4.11 and later include a routine to capture the output of the Abend both to the console and to the ABEND.LOG file. ABEND.LOG is located in the SYS:SYSTEM directory on the server.

The ABEND.LOG file contains all the information that is output to the console screen during an Abend, plus much more:

  • The exact flags and registers of the processor at the time of the Abend
  • The NLMs that were in memory, including their versions, descriptions, memory settings, and exact time and date

Here is a portion of our ABEND.LOG file:
Server S1 halted Friday, February 12, 1999 2:37:03 pm
Abend 1 on P00: Server-5.00a: Page Fault Processor
Exception(Error code 00000002)
CS = 0008 DS = 0010 ES = 0010 FS = 0010 GS = 0010
SS = 0010
EAX = 00000000 EBX = D0AC2238 ECX = 0697DEF0
EDX = 00000009
ESI = D0C5C040 EDI = 00000000 EBP = 0697DED0
ESP = 0697DEC0
EIP = D0AC2232 FLAGS = 00014246
D0AC2232 C600CC MOV [EAX]=?,CC
EIP in ABENDEMO.NLM at code start +00000232h
Running process: Abendemo Process
Created by: NetWare Application
Thread Owned by NLM: ABENDEMO.NLM
Stack pointer: 697DCE0
OS Stack limit: 697A000
Scheduling priority: 67371008
Wait state: 5050170 (Blocked on keyboard)
Stack: D0AC22C1 (ABENDEMO.NLM|MenuAction+89)
D1FEA602 (NWSNUT.NLM|NWSShowPortalLine+3602)
--00000008 ?
--00000000 ?
--0697DF20 ?
--D0134080 ?
--00000001 ?
D1FEA949 (NWSNUT.NLM|NWSShowPortalLine+3949)
--00000010 ?
--0697DEF0 ?
--0697DEF4 ?
--0697DFAC ?
--D0C2E100 (CONNMGR.NLM|WaitForBroadcastsToClear+C90C)
--00000003 ?
--00000008 ?
--00000012 ?
--00000000 ?
--00000019 ?
--00000050 ?
--000000FF ?
--00000001 ?
--00000010 ?
--00000001 ?
--00000000 ?
--00000011 ?
--0697DFDC ?
--0000000B ?
--00000000 ?
--0000000B ?
--00000000 ?
--00000000 ?

Additional Information:

The CPU encountered a problem executing code in ABENDEMO.NLM. The problem may be in that module or in data passed to that module by a process owned by ABENDEMO.NLM.

Loaded Modules:
SERVER.NLM NetWare Server Operating System
Version 5.00 August 27, 1998
Code Address: FC000000h Length: 000A5000h
Data Address: FC5A5000h Length: 000C9000h

LOADER.EXE NetWare OS Loader
Code Address: 000133D0h Length: 0001D000h
Data Address: 000303D0h Length: 00020C30h

CDBE.NLM NetWare Configuration DB Engine
Version 5.00 August 12, 1998
Code Address: D087E000h Length: 00007211h
Data Address: D0887000h Length: 0000684Ch

This information can be useful when determining the source of an Abend. For example, anytime you see the words Page Fault or Stack in the output, the Abend occurred because of something having to do with memory. Usually, it’s because a program or process tried to take memory that didn’t belong to it (for example, from another program). When NetWare detects this, it shuts down the offending process and issues an Abend.

The Server Log File

The general Server Log file (SYS$LOG.ERR ), found in the SYS:SYSTEM directory, lists any errors that occur on the server, including Abends and NDS errors and the time and date of their occurrence. An error in the SYS$LOG.ERR file might look something like this:

1-07-1999 11:51:10 am: DS-7.9-17
Severity = 1 Locus = 17 Class = 19
Directory Services: Could not open local database,
error: -723

The Severity, Locus, and Class designations in the second line substitute for lengthy text descriptions of the error and can provide more information:

  • Severity indicates the seriousness of the problem.
  • Locus indicates which system component is affected by the error (for example, memory, disk, or LAN cards).
  • Class indicates the type of error.

Tables 10.1, 10.2, and 10.3 explain the codes used for Severity, Locus, and Class. Based on the information in these tables, we can determine some information about the preceding example of a SYS$LOG.ERR file. A severity of 1 indicates a warning condition (so the problem isn’t really serious), a locus of 17 indicates that the error relates to the operating system (which would make sense because this is a Directory Services error), and a class of 19 indicates that the problem is with a domain, meaning that the problem is defined by the operating system but it’s not an operating system problem. These designations tell us the reported error is related to NDS and that it’s not really serious. In fact, this particular error might occur when you bring up the server and the database hasn’t yet been opened by the operating system.

syslog.err severity code descriptions

syslog.err Locus code description

syslog.err Locus code description

syslog.err  class code description

syslog.err  class code description

Windows 2000 Server Log Files

Windows 2000 Server, like other network operating systems, employs comprehensive error and informational logging routines. Every program and process theoretically could have its own logging utility, but Microsoft has come up with a rather slick utility, Event Viewer, which, through log files, tracks all events on a particular Windows 2000 Server system.

Normally, though, you must be an administrator or a member of the Administrators group to have access to Event Viewer.
To use Event Viewer, follow these steps:

  1. Choose Start _ Programs _ Administrative Tools _ Event Viewer to open the Microsoft Management Console (MMC) Event Viewer snap-in:

    Windows 2000 Server Log Files

  2. The System Log displays by default. To view the Application or Security Log, select it from the list in the left frame under the Tree tab.

Using Event Viewer, you can take a look at three types of logs:

  • The System Log
  • The Security Log
  • The Application Log

The System Log

This log file tracks just about every event that occurs on that computer. It is similar to Net- Ware’s SYS$LOG.ERR file. However, whereas the SYS$LOG.ERR file tracks many categories of errors, the System Log tracks only three main types of events:

  • Information (An event occurred, especially a service failure.)
  • Warning (An event occurred that could cause problems.)
  • Error (A component has failed and needs immediate attention.)

In a log file, the icon that precedes the date indicates the event’s type. The previous screen shot shows the three types of events found in the System Log.

Figure shows a sample System Log. The list contains several categories of information, including the date and time the event occurred, the source of the event (which process the event came from), which user (if applicable) initiated the process, the name of the computer the event happened on, and the Event ID number (in the Event column). The Event ID number is the unique error type of a particular event. For an explanation of each Event ID number, check the Help file or go to and search for “Event ID.”

A sample System Log (Note the different error types and event IDs.)

A sample System Log (Note the different error types and event IDs.)

If you want more detail on a specific event, double-click it. Figure shows the event detail for the following event (listed in Figure):

1/7/9911:33:15 AMDiskNone7N/AS1

The note in the Description box indicates that Windows 2000 Server found a bad disk block. Even though this is an error event, it is not serious. One bad block is not a problem; several disk blocks starting to go bad at once is a problem. The Data box lists the exact data the Event Viewer received about the error condition. This may be useful in determining the source of the problem. More than likely, if you have a serious problem that you can’t fix, this is the information that you will send to the vendor (or to Microsoft) to help troubleshoot the problem.

The Security Log

This log tracks security events specified by the system’s or domain’s Audit policy. The Audit policy specifies which security items will be tracked in Event Viewer. To set the local Audit policy on your Windows 2000 workstation, follow these steps:

  1. Choose Start -> Programs -> Administrative Tools -> Local Security Policy to open the MMC Local Security Settings snap-in.
  2. The Event Detail dialog box

    The Event Detail dialog box

  3. In the left frame, expand Local Policies and click on Audit Policy to display the local and effective settings for your machine’s Audit policy in the right frame:

    Audit policy in the right frame

  4. Double-click the policy you would like to change the auditing for. This brings up the Local Security Policy Setting dialog box for the policy you selected:

    Local security policy setting

  5. Check the Success or Failure check box to track the success or failure of the policy’s events. Since these are security settings, most often you’ll want to log failures, but you can check both boxes.
  6. Click OK, and the success or failure (or both) of the event will be logged for this system. After you set the Audit policy for a system, you can view its Security Log. Follow these steps:
    • Choose Start -> Programs -> Administrative Tools -> Event Viewer to open the Microsoft Management Console (MMC) Event Viewer snap-in.
    • The System Log displays by default. To view the Security Log, select it from the list in the left frame under the Tree tab:

      Event viewer

As you can see, this log looks similar to the System Log in most respects. The main differences are the icons and the types of events recorded here. To view the detail for an event, double-click it.

The Security Log displays two types of events:

  • Success Audit (The event passed the security audit.)
  • Failure Audit (The event failed the security audit.)

The previous screen shot shows the icons associated with these two types of events. When an item fails a security audit, something security-related failed. For example, a common entry (assuming the Failure check box is checked in the Local Security Policy Setting dialog box) is a Failure Audit with a value of Logon/Logoff in the category. This means that the user failed to log on.

The Application Log

This log is similar to the other two logs except that it tracks events for network services and applications (for example, SQL Server and other BackOffice products). It uses the same event types (and their associated icons) as the System Log. Figure shows an example of an Application Log.

A sample Application Log

A sample Application Log

To access the Application Log, in Event Viewer, choose Log -> Application. The Source column indicates which service logged which event.

All together, the log files present a picture of the general health of a Windows 2000 Server. Generally speaking, if you see an error message, open Event Viewer and check the System Log. If you don’t see the event here, check the other two logs.

Manufacturers’ Troubleshooting Resources

In addition to viewing log files, you can use several types of troubleshooting tools that manufacturers make available for their network operating systems. You can use these resources to augment your own knowledge as well as to solve those pesky problems that have no pattern or few recognizable symptoms. Each type of resource provides different information or different levels of support (some of which have been discussed in previous chapters, but their importance to troubleshooting necessitates discussing them again here). Let’s examine the most popular:

  • README files
  • Telephone support
  • Technical support CD-ROM
  • Technical support website


README files contain information that did not make it into the manual. The latest information released about the software can often be found in the README files. Also, they may contain tips, default settings, and installation information (so you don’t have to read the entire first chapter to install the software).

When troubleshooting application or networking software, check out the README file before you try any of the other manufacturers’ resources. It is usually found on the first installation disk or CD.

Telephone Support

Many people prefer telephone support over other forms of support. You actually get to talk to a human being from the software manufacturer about the problem. Most, if not all, software manufacturers have toll-free support numbers. The people on their end of the line can provide anything from basic how-to answers to complex, technical answers.

Unfortunately, because of their popularity, technical support phone lines are often busy. When the line is finally free, you might, however, find yourself in “voicemail hell.” We’ve all been through it: Press 1 for support for products A, B, and C. Press 2 for Products D, E, and F, and so on and so on. Most people get frustrated and hang up. They prefer to speak with a human being as soon as the call is answered. Today, phone support is often not free (the number to reach support might be, but the support itself is not) but must be purchased via either a time limited contract or on an incident-by-incident basis. This is particularly true for network operating system software support. To solve this problem, companies have devised other methods, such as the technical support CD-ROM and website, which we will discuss next.

The Technical Support CD-ROM

With the development of CD-ROM technology, it became possible to put volumes of textual information on a readily accessible medium. The CD-ROM was, thus, a logical distribution vehicle for technical support information. In addition, the CD was portable and searchable. Introduced in the early 1990s, Novell’s Network Support Encyclopedia (NSE) CD-ROM was one of the first products of this kind. Microsoft’s TechNet came soon after. Both companies charge a nominal fee for a yearly subscription to these CDs (anywhere from $100–$500).

To be sure, the first editions of these products (as with the first editions of most software products) left much to be desired. Search engines were often clumsy and slow, and the CDs were released only about twice a year. As these products evolved, however, their search engines became more advanced, they included more documents, and they were released more often. And, probably most important, manufacturers began to include software updates, drivers, and patches on the CD.

The Technical Support Website

The technical support CDs were great, but people started to complain (as people are wont to do) that because this information was vital to the health of their network, they should get it for free. Well, that is, in fact, what happened. The Internet proved to be the perfect medium for allowing network support personnel access to the same information that was on the technical support CD-ROMs. Additionally, websites can be instantly updated and accessed, so they provide the most up-to-date network support information. Since websites are hosted on servers that can store much more information than CD-ROMs, websites are more powerful than their CD-ROM counterparts. Because they are easy to access and use and because they are detailed and current, websites are now the most popular method for disseminating technical support information.

Hardware Network Troubleshooting Tools

In addition to manufacturer-provided troubleshooting tools, there are a few hardware devices we can use to troubleshoot the network. These are actual devices that you can use during the troubleshooting process. Some devices have easily recognizable functions; others are more obscure. The following are four of the most popular hardware tools (and the Network+ exam tests you on them, by the way):

  • A crossover cable
  • A hardware loopback
  • A tone generator
  • A tone locator

The Crossover Cable

Sometimes also called a cross cable, a crossover cable is typically used to connect two hubs, but it can also be used to test communications between two stations directly, bypassing the hub. A crossover cable is used only in Ethernet UTP installations. You can connect two workstation NICs (or a workstation and a server NIC) directly using a crossover cable.

A normal Ethernet (10Base-T) UTP cable uses four wires—two to transmit and two to receive. Figure 10.5 shows this wiring, with all wires going from pins on one side directly to the same pins on the other side.

A standard Ethernet 10Base-T cable

A standard Ethernet 10Base-T cable

The standard Ethernet UTP crossover cable used in both situations has its transmit and receive wire pairs crossed so that the transmit set on one side (hooked to pins 1 and 2) is connected to the receive set (pins 3 and 6) on the other. Note that four of the wires are crossed as compared with the straight-through wiring of the standard 10Base-T UTP cable.

A standard Ethernet 10Base-T crossover cable

A standard Ethernet 10Base-T crossover cable

You can carry a crossover cable in the tool bag along with your laptop. If you want to ensure that a server’s NIC is functioning correctly, you can connect your laptop directly to the server’s NIC using the crossover cable. You should be able to log in to the server (assuming both NICs are configured correctly).

The Hardware Loopback

A hardware loopback is a special connector for Ethernet 10Base-T NICs. It functions similarly to a crossover cable, except that it connects the transmit pins directly to the receive pins (as shown in Figure). It is used by the NIC’s software diagnostics to test transmission and reception capabilities. You cannot completely test an NIC without one of these devices.

The Hardware Loopback

Usually, the hardware loopback is no bigger than a single RJ-45 connector with a few small wires on the back. If a NIC has hardware diagnostics that can use the loopback, the hardware loopback plug will be included with the NIC. To use it, simply plug the loopback into the RJ-45 connector on the back of the NIC and start the diagnostic software. Select the option in your NIC’s diagnostic software that requires the loopback, and start the diagnostic routine. You will be able to tell if the NIC can send and receive data through the use of these diagnostics.

Tone Generator and Tone Locator

The combination of tone generator and tone locator is used most often on telephone systems to locate cables. Since telephone systems use multiple pairs of UTPs, it is nearly impossible to determine which set of wires goes where. Network documentation would be extremely helpful in making this determination, but if no documentation is available, you can use a tone generator and locator.

The tone generator is a small electronic device that sends an electrical signal down one set of UTP wires. The tone locator is another device that is designed to emit a tone when it detects the signal in a particular set of wires. When you need to trace a cable, hook the generator (often called the fox) to the copper ends of the wire pair you want to find. Then move the locator (often called the hound because it chases the fox) over multiple sets of cables (you don’t have to touch the copper part of the wire pairs; this tool works by induction) until you hear the tone. A soft tone indicates that you are close to the right set of wires. Keep moving the tool until the tone gets the loudest. Bingo! You have found the wire set.

Use of a common tone generator and locator

Use of a common tone generator and locator

Software Troubleshooting Tools

In addition to these hardware troubleshooting tools, you can use software programs to gain information about the current health and state of the network. These tools fall into two main categories:

  • Protocol analyzers
  • Performance-monitoring tools

We use the term network software diagnostics to refer to these tools.

Protocol Analyzer

Any software that can analyze and display the packets it receives can be considered a protocol analyzer. Protocol analyzers examine packets from protocols that operate at the lower four layers of the OSI model (including Transport, Network, Data Link, and Physical) and can display any errors they detect. Additionally, most protocol analyzers can capture packets and decode their contents. Capturing packets involves copying a series of packets from the network into memory and holding the copy so that it can be analyzed.

You could, for example, capture a series of packets and decode their contents to figure out where each packet came from, where it was going, which protocol sent it, which protocol should receive it, and so on. For example, you can find out the following:

  • The nature of the traffic on your network
  • Which protocol is used most often
  • If users are accessing unauthorized sites
  • If a particular network card is jabbering (sending out packets when there is no data to send)

Two common examples of protocol analyzers are Sniffer, a Network General product, and Novell’s LANalyzer.

Performance-Monitoring Tools

In addition to protocol analyzers, many network operating systems include tools for monitoring network performance and can display statistics such as the number of packets sent and received, server processor utilization, the amount of data going in and out of the server, and so on. Net- Ware comes with the MONITOR.NLM utility, and Windows 2000 comes with Performance Monitor. Both monitor performance statistics. You can use these utilities to determine the source of the bottleneck when users complain that the network is slow.

To start the MONITOR.NLM utility in NetWare, simply type load monitor at the console prompt. To start the Performance Monitor program in Windows 2000, you must first be logged in as Administrator (or a member of the Server Operators group). Once you are logged in, choose Start Programs -> Administrative Tools -> Performance.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Networking Topics