Microsoft

Get IT Done: Troubleshooting hardware installation problems in Windows Server 2003

Refer to Microsofts Windows Catalogs to find hardware that works with Windows Server 2003.


Whether you're upgrading an existing server or setting up a new server, having Windows fail to recognize your hardware is always a frustrating experience. Unfortunately, there are a number of reasons why a piece of hardware might not work correctly with Windows Server 2003. Here are some of the hardware problems you may face and how to resolve hardware compatibility problems.

The hardware compatibility list
Before I get into the actual troubleshooting process, I want to take a moment and discuss the hardware compatibility list (HCL). When Windows NT was first released so long ago, Microsoft worked hard to give people the impression that their hardware absolutely would not work unless it appeared on the HCL.

Since that time, the HCL has perhaps become one of the most ignored aspects of Windows. After all, just about every hardware manufacturer provides Windows drivers for their hardware, whether the device is actually on the HCL or not.

Although most hardware components may come with a Windows driver, it doesn’t necessarily mean that you should use them. In fact, the last time that I called Microsoft’s technical support about a potential hardware problem, they wouldn’t even talk to me until I replaced the failing device with a device that was listed on the HCL. Although that happened a while ago, I suspect that Microsoft’s policy hasn’t changed.

When Windows Server 2003 was released, Microsoft emphasized the importance of the HCL by removing several well-known network cards from the HCL. It isn’t that these network cards won’t work with Windows, but rather that Microsoft finds them to be inadequate for a server environment. The list consists of ISA plug-and-play adapters for reliability reasons, PCMCIA adapters (because you shouldn’t be using a laptop as a server), and USB adapters (because of bandwidth limitations). You can find the complete list in the Microsoft Knowledgebase.

In case you're wondering, Microsoft doesn’t ship a copy of the HCL with Windows because the list is constantly changing as new products are released. Instead, you can find the HCL on Microsoft’s Web site.

Troubleshooting an unknown device
The first step in troubleshooting a hardware problem is to make sure that Windows recognizes the malfunctioning device. After all, if Windows doesn’t even know that the device exists, you can’t expect the device to work. You can see exactly what components Windows recognizes by using the Device Manager.

To access the Device Manager, right click on My Computer and select the Properties command from the resulting shortcut menu. When you do, you'll see the System Properties sheet. Now, select the Hardware tab and click the Device Manager button.

When the Device Manager appears, you'll first want to look under Other Devices. Usually if a device is listed under Other Devices, the device appears next to a yellow circle containing an exclamation point. This means that the device is unrecognized because it does not have a device driver.

Most of the time, this tends to occur with USB or Firewire devices. The reason is that most USB and Firewire devices are designed to be automatically detected and to use drivers that are built into Windows. However, this does not apply to all such devices. For example, I have a USB modem that, when plugged in, produces the unknown device error. Unfortunately, Windows does not automatically recognize the modem, so a third-party driver is required.

As strange as it may sound, there are also circumstances in which you can provide Windows with a perfectly good device driver for an unknown device and Windows will still fail to recognize the device. Most of the time this happens when you supply a VXD-based driver. As you may know, VXD drivers are virtual device drivers. VXD files were originally intended for use in Windows 9x. Even so, VXD files were also supported in Windows 2000. Windows Server 2003, however, is specifically designed not to use VXD files. If you try to install a VXD file, though, Windows will usually place the device on the Other Devices list rather than giving you a message stating that you are using an incompatible driver. In such cases, the only way to make the device work is to get your hands on a driver that’s supported by Windows Server 2003.

Another reason that a device may appear in the Other Devices portion of Device Manager is that it may have an invalid device ID number. Every plug-and-play device has an ID number assigned to it. The device ID number might be made up of a variety of components, such as the manufacturer’s ID number, the system vendor ID, or even the revision level. Since the device ID number is required for plug-and-play devices, any device without a device ID number or using an invalid device ID number may be listed in the Other Devices section of Device Manager.

Typically, you won’t run into this problem unless you're using a poorly written device driver on a really cheap device. However, there are circumstances in which good hardware with a good device driver can produce such a condition. For example, Compaq produces a software application called Compaq Insight Manager. This software is designed to monitor the hardware for potential problems. To do this, the software creates virtual device drivers that it uses for linking to the hardware. Keep in mind that Windows Server 2003 doesn’t support virtual device drivers. Therefore, it is very possible that you could have been running Compaq Insight Manager under Windows 2000 Server with no problems. If you then upgraded the server to Windows 2003, the virtual device drivers would be unrecognized and would therefore appear in the Other Devices column.

There are other types of device drivers that can use perfectly valid drivers but cause a device to appear in the Other Devices column. Typically, this occurs with drivers designed to make a device emulate a different device. For example, drivers that are designed to make a parallel port emulate a SCSI port are notorious for having this problem.

Software-based virtual device drivers
Another common problem is that some device drivers are entirely software based. For example, I have a program that allows you to turn any printable document into a PDF file. This software installs itself as a print driver, even though there is really no hardware associated with the driver. Although there are exceptions, software-based devices are incompatible with Windows Server 2003.

If you have a malfunctioning device and you suspect that the device might be software based, there is an easy test that you can use to find out. Simply boot the machine into Safe Mode and then pull up Device Manager. If the device isn’t listed while the machine is running in Safe Mode, then you can be sure that the device is software based. However, if the device remains while in Safe Mode, it is not an absolute guarantee that the device is hardware based. There are conditions in which a software-based driver may still load in Safe Mode.

Once you determine that a device driver is or may be related to a software device, it’s time to figure out where the device is being loaded from. If the device driver appears in the Device Manager when the system is running in normal mode, but not when the system is running in Safe Mode, then one of the programs being launched during Startup is loading the Device Driver. You can check the system’s Startup folder and the system tray for clues as to the program that may be loading the driver. However, on most systems there are way more background programs running than the ones that appear on the Startup menu or in the system tray.

The easiest way to find out exactly what is running at Startup is to look at the system registry. Once you know what is running at Startup, you can use the process of elimination to narrow down the software component that is loading the invalid device driver. To do so, you might disable one registry key at a time or rename one file at a time that’s being called by the registry.

I should point out that editing the registry is dangerous. Making an incorrect change to the registry can destroy Windows and/or your applications. Therefore, you should make a full system backup before messing with the registry. With that said, you can open the Registry Editor by entering the REGEDIT command at the Run prompt. Once the Registry Editor opens, you can find the programs that are set to run at Startup by going to
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run.

If you are uncomfortable with using the Registry Editor or if the list of programs that load at Startup is just too long, there is another way that you can track down the program that’s calling the device driver. Try looking at your event logs. Often, the event logs will contain clues as to which program might be causing the problem.

The system information console
Another tool that can really help you to track down a hardware problem is the system information console. You can access this console by entering the MSINFO32.EXE command at the Windows Run prompt. When the console loads, navigate through the console tree to the Components section. The Components section lists all of the add-on components in your system. For example, the components section will document things like network cards, modems, and sound cards. Unlike the Device Manager, though, it does not document your system board or disk controllers. For the components that are addressed, the System Information console tends to provide a bit more information than the Device Manager does.

While the information given for each device is helpful, you should focus on a container within the Components section called Problem Devices. The Problem Devices container gives you the name of any device that the system sees as malfunctioning. It then goes on to give you a little bit more information that you can use to help to identify the device and/or the problem.

For example, on my test computer, the Device manager was displaying a PCI Simple Communications Controller in the Other Devices section. When I looked in the Problem Devices section of the System Information console, I found a listing for the PCI Simple Communications Controller. The console also told me that the device’s PNP ID number was
PCI\VEN_14F1&DEV_2F1&SUBSYS_201616EC&REV_01\4&351887D&0&58F0
The console also gave me this error message:
The Drivers For This Device Are Not Installed

By using this information, I was able to tell that the error was related to a PCI card for which the system had no drivers. To give you a little history behind this error, this was a brand new computer that had shipped with the Home Edition of Windows XP. When I brought the system home, I formatted the hard drive and loaded a default installation of Windows Server 2003. Since I didn’t use the system’s drivers CD, there was simply one hardware device within the system for which Windows Server 2003 didn’t have a driver. A quick check of the back of the computer revealed a modem that was not listed within Device Manager.

To fix the problem, I went back into the Device Manager and right-clicked on the PCI Simple Communications Controller listing found in the Other Devices section. I then selected the Properties command from the resulting shortcut menu to reveal the device’s properties sheet. I clicked the Reinstall Driver button found on the properties sheet’s General tab. This launched the Hardware Update Wizard. The wizard asked if I wanted to automatically install the driver or if I wanted to install a driver from a specific location. I used the option to install a driver from a specific location, inserted my drivers CD, pointed the wizard to the CD, and soon had a functional modem. The problem was solved.

Physical hardware failures
This was an easy problem to fix because I had a brand new computer with a device that I assumed to be good, which was simply missing a device driver. But what do you do if a device driver is loaded and Device Manager recognizes the device, but the device is still malfunctioning?

The first thing that you should do in such a situation is to ask yourself if the device has ever worked. If the device has worked in the past, ask yourself what has changed since the device last worked? Was a service pack applied to the computer? Was a new driver installed?

If the device previously worked, this might be a good time to try out Windows 2003’s driver rollback feature. To do so, open the Device Manager, right-click on the malfunctioning device, and select the Properties command from the resulting context menu. When you do, you’ll see the device’s properties sheet. Now, select the properties sheet’s Driver tab and click the Roll Back Driver button. This will revert the system back to using the previous driver for the component.

Hopefully, this will get the job done. If not though, you probably either have a bad component or an incorrect device driver. It is also possible that the device is conflicting with some other device in the system, but conflicts are much more rare than they used to be.

The next step that I recommend is to go to the Internet and download the latest device drivers for each device in your system. You can then install these device drivers by right-clicking on the appropriate device, selecting the Properties command from the resulting shortcut menu, and then going to the Driver tab of the device’s properties sheet and clicking the Update Driver button.

Driver signing
While I’m on the subject of updated drivers, I want to take a moment and discuss signed drivers. For workstations, I usually don’t worry too much if a driver isn’t signed. However, in the case of a production server, you should always use signed device drivers. If a manufacturer doesn’t provide signed device drivers, then I would seriously think about switching to a different hardware manufacturer.

If you want to see which, if any, of your current device drivers are unsigned, enter the SIGVERIF command at the Start menu. This launches the Signature Verification utility. Normally, this utility will scan all Windows system files. However, you can use the Advanced button to tell the tool to only scan the \%SYSTEMROOT%\System32\Drivers folder. The program will create a log file named SIGVERIF.TXT. You can view the log file by clicking the utility’s Advanced button, selecting the Logging tab and clicking the View Log button.

If you want to ensure that only digitally signed files are installed onto the server in the future, you can do so by opening the Control Panel, clicking the System icon, and selecting the Hardware tab from the System Properties sheet. This time though, instead of going into the Device Manager, click the Driver Signing button. By default, the system is configured to warn you before installing unsigned drivers. However, the Driver Signing Options dialog box also contains an option to block the installation of unsigned drivers.

Bad hardware
If the new device drivers don’t fix the problem, then you either have a bad hardware component or you have a device conflict. To find out which is the case, try replacing the malfunctioning device with a known good one. If the new component works, then you know that you had a bad component. If the known good component fails, then you have a conflict somewhere.

Troubleshooting conflicts is difficult, and I could easily write an entire article on the subject. However, what I can tell you in this limited amount of space is that the easiest way to troubleshoot a conflict is to remove all add-on components from your system except for the known good version of the malfunctioning component. When you boot the system, the component should work because anything that it might be conflicting with is gone.

Now, start putting the other components back into the system one at a time, testing the system between each one. You should be able to use this technique to find the conflict.

Editor's Picks