Microsoft

Get IT Done: Troubleshooting real mode and protected mode drivers

Learn how to manually make the switch to protected mode drivers.


When hardware problems occur in a Windows 9x environment, the first thing many people try to do is determine whether the hardware is physically damaged or a software configuration error is to blame. If it turns out to be a software problem, typically the next step in the troubleshooting process is to check the device driver responsible for the hardware. What you may not realize, though, is there are actually two different types of device drivers at work in Windows 9x. These include real mode drivers and protected mode drivers. In this first part of my Daily Drill Down series, I’ll introduce you to both types of drivers and explain how to go about troubleshooting driver problems to make your system run as smooth as silk.

What’s the difference?
So if there are two different types of device drivers at work within Windows 9x, you may be wondering what the difference is between the two and when it’s appropriate to use each type. To understand the answer to this question, you need to understand a little bit about the way that Windows 9x works.

Unlike Windows 2000 or Windows NT, Windows 9x is not a completely independent OS. Instead of relying on its own kernel to interface with your system, Windows 9x relies on MS-DOS to do the work. Granted, you don’t actually have to install DOS before loading Windows 9x, but Windows 9x comes with its own version of DOS that gets installed when you install Windows. Any time that you boot the system, DOS is loaded before Windows can begin to load. Of course this process is hidden from view so that you don’t notice it, but it does happen.

So what does the boot process have to do with hardware device drivers? Well, you’ve probably seen drivers that exist at the Windows level. For example, if you install a new printer through Windows, you use a driver to do so. These Windows-level device drivers are known as protected mode drivers.

Just as protected mode drivers exist at the Windows level, real mode drivers exist at the DOS level. If you’re familiar with DOS, then you’ve probably seen how DOS based systems make use of the CONFIG.SYS and AUTOEXEC.BAT files for loading drivers. Such commands invoke real mode drivers.

You might be thinking that the only difference between real mode and protected mode drivers is that real mode drivers exist at the DOS level while protected mode drivers exist at the Windows level. While this is the main difference between the two driver types, there are other important differences between the two that exist because of the level at which the drivers function.

One such difference is that DOS is a 16-bit environment, while Windows 9x is a 32-bit environment. Therefore, real mode drivers don’t achieve the same level of performance as their protected mode counterparts. Another important difference is that protected mode drivers are designed to work with Windows 9x, and real mode drivers aren’t. Because real mode drivers exist at a lower level than the Windows 9x shell, there’s a chance that these drivers could interfere with Window’s ability to function correctly. Usually, such a malfunction would occur in the form of an apparent hardware malfunction or a General Protection Fault (GPF).

Why is protected mode better?
You may be wondering why real mode drivers are prone to causing GPFs and hardware failures, but protected mode drivers aren’t. First, let me reassure you that protected mode drivers can and sometimes do malfunction. It just isn’t as likely that a well-written, protected mode driver will malfunction. The reason that protected mode drivers aren’t as susceptible to failure is that they are specifically designed to coexist with Windows 9x.

The reason that protected mode drivers can coexist with Windows 9x is that they are aware of what’s going on with Windows 9x. Windows 9x multitasks applications and system processes in a way that prevents them from interfering with each other. Real mode drivers, on the other hand, control the hardware directly without using any of Window’s safeguards.

As you can see, it’s safe and more efficient to use protected mode drivers, but how do you go about implementing them? Fortunately, Windows 9x does some of the work for you. For example, suppose you were upgrading an older version of Windows or installing Windows 9x on a system that contained only DOS. Because Windows 9x ships on CD, the system would probably already contain real mode CD-ROM drivers. These drivers would look something like this:
CONFIG.SYS
DEVICEHIGH=A:\D011V110.SYS /D:MSCD000

AUTOEXEC.BAT
MSCDEX /D:MSCD000


However, when you install Windows 9x, Windows will automatically detect the real mode CD-ROM drivers and replace them with a protected mode driver. If you look back at the CONFIG.SYS and AUTOEXEC.BAT files, you’ll either see that the lines have been removed completely or that the word REM (the DOS command for remark) has been added to the beginning of each line. It tells DOS to treat the line as a comment rather than as a command.

Manually making the switch to protected mode drivers
Unfortunately, Windows isn’t smart enough to remove all of the real mode drivers. Windows can only swap drivers for hardware that it knows about. Therefore, if you have something really common such as a CD-ROM drive, Windows will have no trouble making the switch. On the other hand, if you have some really old piece of hardware that Windows knows nothing about, then there’s no way for Windows to make the switch. In such a case, you’ll have to make the switch manually.

The first step to making such a switch is to locate a protected mode driver for the hardware that you’re trying to support. Most hardware manufacturers offer Windows 9x drivers for their hardware, and you can usually find them on their Web sites. Unfortunately, if the hardware is extremely old, the manufacturer may have completely stopped supporting it. In such a case, you’ll have to upgrade to newer hardware. Anyway, once you’ve acquired a new driver, then all you have to do is to go through the CONFIG.SYS and AUTOEXEC.BAT files to find the commands that reference the real mode driver. When you’ve located these commands, remove them and save your changes. Now, boot Windows and use the Add New Hardware icon in Control Panel to install your new driver.

This raises an interesting question though: If the whole idea is to remove things from the CONFIG.SYS and the AUTOEXEC.BAT files, then what should be left in these files? The truth of the matter is that Windows 9x can function without a CONFIG.SYS or an AUTOEXEC.BAT file. If you’ve been around long enough to remember DOS and Windows 3.x, you may wonder how this is even possible. After all, in the older versions of Windows, it was absolutely critical to configure DOS properly so that you could achieve adequate performance from Windows. Even if you weren’t loading any hardware drivers through DOS, you still had to configure things like files, buffers, and memory managers. In Windows 9x, none of this is necessary.

If you’re familiar with DOS, you might recall the three files that were necessary for booting the system:
  • IO.SYS
  • MSDOS.SYS
  • COMMAND.COM.

Although these files still exist in Windows 9x, their roles have changed significantly. In Windows 9x, the majority of the boot process is handled by IO.SYS. MSDOS.SYS is now a text file that contains a few Window boot options, and COMMAND.COM functions in the same way that it always has. What’s interesting about IO.SYS, though, is that it has its own set of CONFIG.SYS and AUTOEXEC.BAT style commands built in. When you boot the system, IO.SYS not only takes you through the initial phases of the boot process but also prepares the system for Windows 9x to load by configuring things like files, buffers, and the memory management. You can actually view a portion of this by booting Windows to the command prompt (not a command prompt window) and entering the MEM /C | MORE command. When you do, you’ll see what’s loaded into memory. This will include several modules such as HIMEM.SYS, even if you don’t have a CONFIG.SYS or AUTOEXEC.BAT file.

My point is that protected mode drivers are far superior to real mode drivers. Windows is designed to function without any real mode drivers being loaded by the end user (unless you have special hardware requirements). The very few real mode drivers that Windows does require, it loads behind the scenes.

The troubleshooting process
Now, let’s assume that you’re having some sort of driver problem. To avoid any potential conflicts, you’ve removed any real mode drivers and replaced them with protected mode drivers, but the problem still exists. Where do you go from here?

In such a situation, the first question that you’ve got to ask yourself is, “Did the device ever work on this system?” If it did, you’ve got to figure out what’s changed since the last time that the device worked. Perhaps you’ve added new hardware or updated a driver for a different device. Maybe the system was moved and a component could have vibrated loose. Another possibility is that the system could have been victimized by a power surge. Whatever the reason, it’s up to you to figure out what happened and how to fix it.

The first step that I recommend taking is verifying that the hardware is hooked up correctly. If you’re dealing with an external device such as a modem, make sure all of the cables are secure and that the device has power. If it is an internal device, such as a network card, remove the device and reseat it. If the problem still exists, move on to step two.

Step two involves checking out the device driver. Often hardware manufacturers release multiple versions of a particular driver. Newer versions can correct bugs, boost performance, or add new capabilities. Don’t just assume that the driver disk that came with the malfunctioning device contains the latest driver. Go out to the hardware manufacturer’s Web site and download the latest driver.

When you install the new driver, you’re actually doing a couple of different things. First, you’re overwriting an old driver with a new driver. More importantly, you are updating the system. This means that if any driver-related files were accidentally removed from the system, you’ll add them back. Likewise, installing a new driver will update the registry as well. Thus, if a registry entry was removed or incorrectly modified, there is a good chance that installing a new driver will correct the problem. Of course this depends on the type of hardware malfunctioning. Some hardware devices use a single file for a driver, while other devices use dozens of files and registry entries. Therefore, replacing the existing driver with a new driver will usually correct a problem, but it isn’t a guaranteed fix.

Conclusion
Although both protected mode and real mode drivers will work, Windows 9x is designed to rely primarily on protected mode drivers. If you do find yourself plagued with a driver problem, try following my basic steps on troubleshooting. In part two, though, I’ll explain some of the more in-depth techniques you can use to troubleshoot driver problems.

Editor's Picks