Windows

Get IT Done: Troubleshoot your hardware with Windows 98 log files and utilities

Learn how to use Bootlog, Detlog, Netlog, Setuplog, and Detcrash to solve setup problems.

With the introduction of Windows 98, we saw a more stable and better performing environment for your computer. Many improvements have been made to the way Windows 98 runs. When Windows has problems, however, many users have limited knowledge of the built-in hardware and device troubleshooting tools available to them. Some of these tools are improved versions of Windows 95 tools, others remain unchanged, and a variety of new tools have been added. Various logs provide the user with resources to both troubleshoot and optimize Windows 98. These logs enable you to more quickly diagnose and correct problems with hardware and associated drivers—and problems will inevitably happen to even the most knowledgeable of users.
If you found this article helpful, check out TechRepublic's TechProGuild subscription resource, which offers in-depth technical articles covering a variety of IT topics including Windows server and client platforms, Linux, troubleshooting issues, data networking challenges, NetWare, and more. With a TechProGuild account, you can also read the complete text of popular IT industry books online. Sign up now for a FREE 30-day TechProGuild trial.
Tools for troubleshooting setup
Windows 98 makes available a number of programs and log files for troubleshooting problems that occur during the setup process. Here’s a rundown of some of the more helpful troubleshooting aids.

Windows 98 Setup creates several log files. These files are located in the C:\ directory:
  • Bootlog.txt
  • Detlog.txt
  • Netlog.txt
  • Setuplog.txt
  • Detcrash.log

Bootlog.txt records the current startup process for starting Windows 98. Detlog.txt records the start of a detection test and the test outcome. It keeps a record of devices Setup finds during the detection process. Netlog.txt logs network components detected by Setup. Setuplog.txt records what took place during Setup, including successes and failures. This record is used by Safe Recovery to determine where Setup will resume. Detcrash.log records which detection steps were successfully completed so that Setup will not fail because of the same problem.

Two utilities can complement the logs. The Automatic Skip Driver Agent utility (Asd.exe) shows which drivers Windows had trouble with during startup and were therefore disabled or skipped. The Microsoft System Information utility displays system information, such as hardware resources, devices installed, and corresponding device drivers. The following sections describe these logs and tools in detail.

Why Bootlog.txt?
Have you ever seen an invalid Vxd or a loadfailed error message when booting Windows? Or do you see references to devices no longer on your system? One of the more useful troubleshooting log files maintained by Windows 98 is Bootlog.txt. This file consists of five sections that describe the sequence of events performed by Windows during system startup.

Creating the Bootlog.txt file
Bootlog.txt is created automatically during the initial running of Windows following setup. This is the one and only time that Bootlog.txt is created automatically. If you want to create this file interactively during the boot process, press [F8] when the message Now starting Windows 98… appears. On the resulting menu, select option 1-Logged. Alternatively, you can create Bootlog.txt by starting Windows 98 from the command prompt using the win /b switch. If you wish to create Bootlog.txt on every startup, the switch can be put in the appropriate section of the Win.ini file.

I highly recommend that you run this feature to learn the sequence of steps the operating system goes through to start the system. That way, you will be able to more easily isolate problem areas when errors occur.

Format of Bootlog.txt
I mentioned earlier that Bootlog.txt contains five sections. These sections and their roles are as follows:

Section 1: Loading real-mode drivers

This first section presents the loading process of real-mode drivers, such as Himem.sys, Emm386.exe, and Setver.exe. Real-mode drivers are written for the original 8086/8088 16-bit architecture for Intel chips and must be loaded into the first megabyte of RAM. Take a look at Figure A. An error-free loading of a real-mode driver returns a Loadsuccess=drivername entry. If the loading of a real-mode driver was unsuccessful, the returned entry is Loadfailed=drivername.

Figure A
Here’s the result of loading real-mode drivers.

A Loadfailed=drivername entry only indicates that the related device driver refused to load. In some circumstances, this is valid because the device may not be needed or detected by Windows.
Section 2: Loading VxDs

In this section, Windows loads the VxDs (virtual device drivers). A virtual device driver provides low-level hardware support for Windows. For example, Vmm32.vxd contains the Windows 9x kernel. Think of a virtual device driver as a low-level software component that manages a single resource, such as a hardware or system device, thus allowing many concurrent threads or accesses. As in the first section, an unsuccessful load returns a Loadfailed=drivername entry for the VxD that refused to load.

Section 3: Initialization of critical VxDs

Once all the VxDs have been loaded, Windows will initialize the system-critical VxDs, such as VCache (disk-caching software), among others.

Section 4: Device initialization of VxDs

Once all the system-critical VxDs have been initialized, Windows will initialize the rest of the VxDs. An unsuccessful VxD initialization returns a Deviceinitfailed=devicename entry.

Section 5: Successful VxD initialization

This section verifies that system VxDs have successfully initialized.

Using Detlog.txt
The Detlog.txt file records which hardware components have been detected by the system and what their parameters are. The Detlog.txt file is located in the root directory of the startup drive after Windows 98 has been installed. Entries in Detlog.txt are in the order of the hardware information discovered as each step of the detection process is carried out. Detlog.txt is an ASCII file created for users to read; Windows 98 Setup reads the binary information in Detcrash.log.

During Windows 98 Setup, after Setup restarts your computer for the first time, it begins hardware detection. Detection can also occur when you use the Add New Hardware option in Control Panel to add a new device.

Hardware detection is a continuous loop through a three-part process. The first step in the process is to identify the activity to be performed. Second, the routine queries the system to see if the device is at the default address for that device. Third, it verifies whether it was successfully detected. As you can see by the entry for a disk drive in Figure B, IRQ (interrupt request lines) and DMA (direct memory access channels) allocated to the device are also listed.

Figure B
Detlog.txt lists detected hardware and verifies their IRQ and DMA settings.


By creating an updated Detlog.txt file every time the detection process runs, the detection module tracks the detected devices and the I/O port addresses used. Any existing Detlog.txt is renamed Detlog.old.

Using Detcrash.log
The Detcrash.log file is created when the detection process causes Setup to stall or the computer to lock up during the hardware detection portion of the startup process. Detcrash.log is a binary file. For troubleshooting a system crash, check the last entry created in Detlog.txt. It would probably be useful to compare this file with the Detlog.old file to determine what has changed.

Using Netlog.txt
Netlog.txt describes the detection results for network components during Windows 98 Setup. It is found in the root directory. It also tracks subsequent network setup activity, such as the later installation of another protocol. As you can see in Figure C, a number of cryptic headings provide detailed information on the network setup of the Windows 98 system.

Figure C
Netlog.txt shows the network components detected.


The first entry in Figure C isClassInstall (0x6 on…). This entry indicates where network installation begins. In this case, it refers to Microsoft Virtual Private Networking.

The next entry is Examining class Net. Network detection is searching for network software of four class types: NET (network adapters), NETTRANS (protocols), NETCLIENT (clients), and NETSERVICES (such services as file and printer sharing).

Each NdiCreate (network device name) OK entry indicates the successful creation of the object.

There are several other entries that will appear in the Netlog.txt:
  • The entry ClassInstall (0x6) end indicates the end of the initial detection and preparation of the various network components for installation in the next section.
  • The entry ClassInstall (0x9) on… indicates the binding of the protocols to the network adapter. This will include the Client software.
  • The entry ClassInstall (0x9) end indicates that setup has finished binding the protocol(s) to the network adapter.
  • The entry ClassInstall (0xa) end indicates that the network setup process is concluded.
  • The final entry is ClassInstall (0xc) end.

Using Setuplog.txt
Setuplog.txt holds setup information created during installation by Windows 98 Setup. The log is found in the root directory and is utilized during Safe Recovery. During the installation of Windows 98, entries are written to the file, listing information about the specific steps as they occur in the setup process. This file is used by Setup for recovery in case of setup failure, and it can also be used for troubleshooting errors that occur during installation.

The information in Setuplog.txt is used to ensure that the installation does not fail twice because of the same problem. If Windows 98 Setup is restarted after a process fails, Setup reviews the contents of Setuplog.txt to determine which steps completed successfully before the error occurred. If it is determined that a process started but was not completed, that process is skipped, and the next part is processed. Even if Setup encounters devices that cause several installation attempts, the installation process will always progress and skip the modules that failed.

If an error occurs during installation, read Setuplog.txt to try to ascertain what process was in use when the error occurred.

Understanding Automatic Skip Driver Agent
With Windows 98, Microsoft introduced a new tool called Automatic Skip Driver (ASD) Agent. As described in the Windows 98 Resource Kit, ASD is used to detect and automatically disable device drivers or operations that fail during startup—that is, ones that can cause Windows 98 to hang. The drivers that failed to load are bypassed the next time you restart the computer. The ASD log file keeps a permanent record of all problems that ASD has detected.

If a device driver fails to load during startup, run Asd.exe. Disabled items can be viewed and reenabled. In the Automatic Skip Driver dialog box, click the operation that failed and then click Details. The device’s Details dialog box appears and provides a recommendation for solving the problem. This may include updating the driver by running Asd.exe. If you run Asd.exe with no errors in the registry, you will receive a message stating that no critical operation failures occurred.

Running Automatic Skip Driver Agent
There are two ways to access Asd.exe. From the Start menu, click Run and then type ASD and click OK. Alternately, click Start | Programs | Accessories | System Tools | System Information. Select the Tools menu and click Automatic Skip Driver Agent.

Using Automatic Skip Driver Agent
When Windows 98 starts, it attempts to load all device drivers required for the installed hardware. If a hardware device or its driver is defective, the device driver may fail to load and cause Windows to hang. ASD identifies the specific device(s) that failed to enumerate when Windows 98 started. (Enumeration is the process of identifying which plug and play devices are in the computer and assigning the appropriate hardware resources to the devices.) After two failed attempts to load, ASD disables the device driver or stops the operation that caused system startup to fail. Windows will no longer attempt to enumerate the component.

Devices disabled by ASD may be identified by a yellow exclamation point (!) in Device Manager. The Device Manager hardware error code associated with ASD is Code 11.

Along with device drivers, ASD can detect certain problems during startup and during normal operating system operation. As outlined in the Windows 98 Resource Kit, examples of operations that ASD monitors include:
  • Starting a device
  • Enumerating a device
  • Calling a PnP BIOS
  • Calling a PCI BIOS
  • Calling a VESA BIOS
  • Posting a video BIOS
  • Mapping an address space
  • Setting a graphics device power state
  • Posting a video BIOS after standby
  • Getting PCI IRQ routing table from a PCIBIOS 2.1 call

Understanding MSInfo
The Microsoft System Information (MSInfo) utility provides an excellent place to start your hardware troubleshooting. MSInfo collects information such as devices installed or device drivers loaded, and it provides a menu for displaying the associated system topics. Use it to diagnose computer problems and track down errors. For example, if a device is not functioning, MSInfo reports the following when viewing “problem devices”:
This device has a problem: Code=##

MSInfo also provides links in the Tools menu to other tools used for troubleshooting.

Running MSInfo
To run MSInfo, select Start | Programs | Accessories | System Tools | System Information. You can also run MSInfo by selecting Start | Run and typing MSInfo32 at the prompt.

The information displayed by MSInfo is divided into Hardware Resources, Components, and Software Environment. MSInfo maintains a history of device drivers installed on the system. If you are unsure of a system’s recent history, use MSInfo to better understand what has happened (see Figure D). To access this information, expand the subcategory Components and then click History. If a device fails and its history indicates a recent driver upgrade, you can try replacing it with the original driver and retesting.

Figure D
System Information can show the history of device driver changes.


The bottom line
We are all faced, at one time or another, with the cryptic hardware errors that occur in Windows 98. These troubleshooting logs and utilities provide you with additional tools in your arsenal. In a majority of cases, some preliminary investigation will uncover the source of the condition and will provide a course to follow.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.
0 comments

Editor's Picks