When you have a device driver problem, the key to solving it is to determine whether the driver responsible is a real mode driver or a protected mode driver. In my previous series on real and protected mode drivers, I explained many aspects of these two drivers, including how to replace your real mode drivers with protected mode drivers. However, there are situations in which it’s impossible or impractical to do such a replacement. So, in this Daily Drill Down, I’ll explain how to go about troubleshooting real mode device drivers.

Memory constraints
Real mode drivers are device drivers designed to function at the DOS level. They are loaded into memory before the core Windows 9x operating system is loaded. Windows 9x sits on top of DOS, and a few real mode drivers are automatically loaded to prepare DOS for Windows. For example, the IO.SYS file automatically loads the HIMEM.SYS driver. This driver would normally be loaded in CONFIG.SYS but is loaded automatically since Windows is dependent on it.

The idea that Windows loads some device drivers automatically to make way for the core Windows 9x operating system has some significant implications. Perhaps the most significant is that Windows still relies on a similar memory model to the one used by DOS 6.2 and Windows 3.11.

If you worked with Windows in the days of DOS and Windows 3.11, you may recall that it was a real pain to optimize the DOS-level configuration so that you could get optimum performance from Windows. The key to achieving optimum performance was memory management. So why am I telling you how to optimize an operating platform that’s been extinct since 1995? The reason is Windows 9x and Windows 3.11 are more closely related than most people realize. Just as the key to optimizing Windows 3.x’s performance was memory management, the key to solving real mode device driver problems in Windows 9x is the same type of memory management.

Similarities between Windows 9x and 3.x
At the real mode level, Windows 9x uses an almost identical memory model to that used by Windows 3.x. Even though it’s common to run Windows 9x on machines with 128 MB of RAM, it’s still the first 640 KB of memory that counts when you’re dealing with real mode device drivers.

Whether you’re talking about Windows 3.x, Windows 95, Windows 98, or Windows Me, the first 640 KB of memory is known as conventional memory. The conventional memory is the area in which programs started at the DOS level run by default. Unfortunately, this idea also applies to device drivers. One of the biggest problems with Windows 3.x was that so many things had to be loaded at the DOS level before Windows could function properly. For example, depending on your system, you might have to load network drivers, CD-ROM drivers, and mouse drivers before loading Windows. Of course, each one of these drivers occupies some memory. If you load each driver into the conventional memory, then the amount available is significantly reduced. In fact, in the days of Windows 3.x, it wasn’t at all uncommon to see people load so many device drivers that there wasn’t enough conventional memory left to run Windows. Believe it or not, it’s still possible for this to happen in a Windows 9x environment. In Windows 9x, more emphasis is placed on the higher memory ranges, but Windows is still greatly dependent on your system’s conventional memory. If you fill the conventional memory with too many real mode device drivers, Windows will not boot.

Obviously, bogging down the conventional memory to the point that Windows won’t load is a big problem. However, you’ll also experience problems if you even get near that point. If you load a lot of device drivers into conventional memory, the system will boot slower and Windows’ performance will be adversely affected. So, how do you make sure that necessary real mode device drivers don’t hamper Windows’ performance?

Does the device work at all?
First, you need to find out more about the nature of the problem. For example, is the problem a device driver problem, a hardware problem, or a Windows problem? Since the real mode device drivers function at the DOS level, if you’ve loaded a device driver at the DOS level, then your device should function at the DOS level. Granted, you may not have DOS based software available to use in conjunction with the device driver, but you should be able to gain at least some level of functionality from the DOS prompt (i.e., if you load a real mode device driver for your CD-ROM drive, then you should be able to access your CD-ROM drive through the DOS prompt).

Because of this, the first step in the process is to boot the machine into DOS mode and test your device driver. To do so, reboot your machine. When you see the message that says Starting Microsoft Windows 98 (or something similar), press [F8]. You should see the Microsoft Windows 98 Startup Menu. If you’re using a different version of Windows, the menu name will be different, but the commands will be the same. Next, select the Command Prompt Only menu option and press [Enter].

Once you’ve made your selection from the menu, Windows will begin loading all of the real mode device drivers and take you to a command prompt. Remember that Windows is loading its own built-in set of commands along with the commands that you’ve specified in the CONFIG.SYS and in the AUTOEXEC.BAT file.

Next, try testing your hardware device. Try inserting a CD and entering the DIR command to look at the CD’s contents, if you’re working with a CD-ROM drive. If the hardware device in question works at this level, then the driver itself is fine. The problem might be that you’re taking away too many resources from Windows or that the device is conflicting with another device. If your device doesn’t work at the DOS level, then the problem could be a bad device driver, an incorrectly configured device driver, insufficient memory, or a conflict with other hardware.

More memory considerations
After you’ve tested the hardware device, the next step is to take a closer look at your machine’s real mode configuration. As you look at the command prompt, consider the set of commands that were just processed during the boot sequence run every time you load Windows. Even though Windows has its own built-in set of real mode commands that are processed along with the IO.SYS file, in some cases, it’s possible to override the built-in commands with commands found in the CONFIG.SYS or AUTOEXEC.BAT files. For example, the IO.SYS file sets a default number of files and buffers. The number of file handles and buffers set in IO.SYS are designed to be adequate for running Windows 9x. If you’re loading a lot of real mode device drivers, you may need to add a FILES= or BUFFERS= line to the CONFIG.SYS file to add extra space for the files that you’re loading. However, I’ve seen people specify a number smaller than what Windows uses for a minimum requirement. When this happens, Windows will usually load, but it may have problems with General Protection Faults.

As you can see, it’s important not to override the default command set unless you use a value that’s designed to accommodate additional system requirements (such as real mode device drivers) that Windows may be unaware of. To help you to avoid accidentally overriding a default setting, I’ve listed the built-in command set below.


Please keep in mind that this particular command set applies to Windows 98. The command set that’s built into other versions of Windows may vary.

The CONFIG.SYS commands embedded in the IO.SYS file

The AUTOEXEC.BAT commands embedded in the IO.SYS file

Memory management
After checking your CONFIG.SYS and AUTOEXEC.BAT files for conflicts, take a look at the memory available. (To do so, reboot your system and press [F8] when you see the Starting Microsoft Windows 98 message, or a comparable message.) When you see the boot menu, select the Safe Mode Command Prompt Only command and press [Enter]. As before, Windows will boot to a command prompt. The difference this time is that it will not process the CONFIG.SYS or AUTOEXEC.BAT files; however, it will process the CONFIG.SYS and AUTOEXEC.BAT commands contained within the IO.SYS file.

When the boot process completes, enter the command MEM /C | MORE. This command will display the real mode device drivers that Windows has loaded into memory and the amount and type of memory that each device driver is using. At the end of this list, you’ll see a summary screen that shows the amount of free conventional, upper, reserved, and extended memory. Take note of the amount of free conventional memory. It’s typically impossible to keep the amount of free conventional memory exactly the same, but you need to make as much of it as possible available to Windows.

Reboot the system and go back to the Command Prompt Only option. Enter the MEM /C | MORE command again and compare the amount of free conventional memory to the amount available when Windows was running in Safe Mode’s Command Prompt Only mode. Many times, if you’re having real mode device driver problems, then you’ll discover that the two values are really far apart. Therefore, you’ll have to try to bring the values closer together. Although doing so isn’t easy, there are several tricks that you can use to get the job done.

Fixing this problem involves multiple reboots and configuration changes. To make the entire process easier and avoid making any big mistakes, I recommend working from a floppy disk until you get the configuration to an acceptable level.

To create a floppy disk for this purpose, insert a blank, formatted disk into your floppy drive and enter the command SYS A:. This will copy IO.SYS, MSDOS.SYS, and COMMAND.COM to the disk and make the disk bootable. The next step is to copy your CONFIG.SYS and AUTOEXEC.BAT files to the disk. Then, edit the copy of CONFIG.SYS and AUTOEXEC.BAT that exist on the floppy to make sure that each command contains the full path to any file that it addresses. Finally, make sure that the last line in the AUTOEXEC.BAT file reads like this:

Adding this line will allow you to use Windows commands such as SYS or MEM while working from a floppy disk. Once you’ve made your boot floppy, it’s time to start experimenting with the configuration. I’ll address the configuration in my next Daily Drill Down.

The key to solving real mode device driver problems is to make sure that the system’s memory is configured properly. I hope the scenarios I covered in this article will help diagnose problems you encounter when your real mode device drivers are taking up too much space. Watch for my next Daily Drill Down where I’ll explain how to reconfigure the system’s memory.