Software Conflicts
From the December 1997 issue of the I/O Port Newsletter
by Brian K. Lewis, Ph.D.*
Member of the Sarasota Personal Computer Users Group,Inc.
Probably the most frustrating things about computers are the little messages that say "your program has created an error in . . . " or "this program has performed an illegal operation and will be shut down." The result is the same, the program is shut down and probably won't run again until you reboot the computer. We generally think of these errors as a GPF or general protection fault. However, Microsoft has classified errors into four general groups: illegal instructions, invalid page faults, stack faults and GPFs. To the user, it's hard to tell the difference.
The problem is trying to figure out what has caused the error and how can it be prevented in the future. Microsoft's Knowledge Base contains half a dozen instances of situations involving the phrase "illegal operation". However, if you search just for "GPF", you'll find more than 1,100 documents. Most of these relate to specific third party (non-Microsoft) software problems. In a few instances, the notes say that the problem exists in Windows 95 and that Microsoft is working on a solution to be "provided really soon". So what can we do to reduce the number of these errors on our own systems?
If you upgraded a Windows 3.x system to Windows 95, you should check your system files for possible problems. They are the CONFIG.SYS, AUTOEXEC.BAT, WIN.INI and SYSTEM.INI files. Most new Windows95 computers don't have a CONFIG.SYS or AUTOEXEC.BAT file. So if you did an upgrade, there may be commands in these files which are no longer needed and could be removed. For example, if you don't run DOS programs, you do not need sound drivers to be loaded in the AUTOEXEC file. Or if you are still loading SHARE.EXE, this command can be removed from your AUTOEXEC.BAT file. Other possible sources of problems include the drivers for your CD-ROM. The real mode drivers are loaded in the CONFIG.SYS file and MSCDEX is loaded in the AUTOEXEC.BAT. Using a text editor or SYSEDIT, you can add a REM command to the beginning to the CD-ROM drivers lines in these files. Then when you reboot the computer check to see if your CD-ROM drive is working. If not, your system needs the real mode drivers. You might also check with the manufacturer to see if protected mode drivers are available.
Other sources of problems are resident programs that load into RAM whenever you boot your computer. Some programs simply aren't compatible with each other and shouldn't be run simultaneously. Testing for these problems can be time consuming. You need to open the startup folder to see what is being loaded when Windows starts. Any shortcuts listed in this folder can be moved to another folder temporarily. That's not the only place you need to look for startup programs. Check the LOAD= and RUN= lines in your WIN.INI file. You can comment out these lines by placing a semicolon at the beginning of the line. Also check your autoexec.bat for any memory resident software that may be loading. This includes anti-virus software. Most anti-virus software doesn't need to be run until it's needed to check a file. Unless, you are constantly engaged in loading files you've obtained from other users. After you have temporarily removed all the commands for memory resident software, then add them back one at a time. Checking, of course to see if any system problems occur before adding any of them.
All of this work may result in no reduction in the errors occurring in your system. So where do we go next? You'll find a 386 enhanced section in the SYSTEM.INI file. Again, if you upgraded from Win 3.x, there may be device drivers in this section that are no longer needed. You can start by adding a semicolon to the beginning of each line and then reboot your system. Remember, none of the changes to CONFIG.SYS, AUTO EXEC.BAT, WIN.INI or SYSTEM.INI will take place until you reboot the system and reload these files.
There is another possible source of conflict that can produce system failures. That is the problem of duplicate DLL's. A DLL is a dynamic link library. These files contain program routines used by many different programs simultaneously. The use of a single DLL allows programmers to write smaller programs because they can call functions contained in the DLL. So you may have the same DLL supplied by different software manufacturers and when you install the program, the DLL is copied to your hard disk. These programs save on RAM space, and if the rules Microsoft established are followed, very few problems would occur. Unfortunately, not everyone plays by the rules, Microsoft included. All DLL's that may be used by more than one program are supposed to be stored in the \Windows\system subdirectory. Every DLL is supposed to have an internal version number. So far, so good. However, in reality, you may end up with multiple copies of the same DLL scattered around your hard disk. For example, I have four copies of a file entitled MSSETUP.DLL. Not one copy of this DLL is in the Windows system folder. They are in four different locations associated with the programs that installed them. How can this be a problem? When you run a program, it loads into RAM any DLL's it needs that are not already loaded. If version 1.0 of a DLL is loaded in RAM and then another program is loaded that requires version 2.5, you will get an error when the second program calls a function that is not included in version 1.0. This problem is a common source of system crashes. When a 16-bit program crashes, the DLL's associated with this program are not unloaded from memory. That's why you cannot run the program again until you reboot the computer. This is not supposed to happen with 32- bit programs, but it does.
There is a freeware program available called FINDDUPS. It can be found on the Internet at http://www.infoworld.com/page one/opinions/livingst/finddups.zip. This program will search your hard disk and provide a list of the duplicate DLL's. It includes the version number and the path to the DLL. It also ignores the required duplicates that are in the SYSBACKUP folder and in the system folder. Once you have found your duplicate DLL's, DO NOT go through and delete them. Some programs will not work with the new version of a DLL and must have the older version. This is especially true of some Microsoft programs (Office, Word, Excel, Winsock). So, first copy the DLL to some safe location, like a floppy disk. Put the latest version in the \Windows\System subdirectory. Then try to run the programs that use the DLL. If no problems occur, go on to the next DLL. Remember that you must be careful anytime you start moving and/or deleting system files like DLL's.
There is one last place where outdated and unused information can cause problems. This is the Registry. Too often, uninstalling a program doesn't remove everything related to it. Anyone with Windows 95 should have the latest copy of Microsoft's registry cleaner (RegClean 4.1). One reference I found recommended running this program at least twice when you first obtain it. It will clean out "orphaned" keys from your registry. It is also freeware and is available from http://www.microsoft.com/kb/articles/q147/7/69.htm.
As you have realized in reading this far, there are no detailed and specific answers to the problems of system crashes caused by software conflicts. I can't even tell you what programs to look out for in your various system files. All you can do is try the "trial and error" method on your computer. Every system I have worked on has been different in it's hardware and software configurations, and in the resulting problems. There are no rules, except, BE CAREFUL & CONSERVATIVE in making any changes. Good hunting!
* Dr. Lewis, a former university & medical school professor, is currently a computer consultant and computer instructor for Sarasota County Technical Institute. He is available, on a fee basis, as an on-site consultant to help you with your home or business computer problems. He can be reached via e-mail at bklew@ix.netcom.com or voice mail at 941/925-3047.
Copyright 1997. This article is from the June 1997 issue of the Sarasota PC Monitor, the official monthly publication of the Sarasota Personal Computer Users Group, Inc., P.O. Box 15889, Sarasota, Fl 34277-1889. Permission to reprint is granted only to other non-profit computer user groups, provided proper credit is given to the author and our publication. We would appreciate receiving a copy of the publication the reprint appears in, please send to above address, Attn: Editor. For further information about our group, email: spcug@netline.net /Web: http:/www.spcug.org/
The Sarasota Personal Computer Users Group, Inc. has 1,000+ members and was established in 1982. We are members of the Assoc. of PC User Groups (APCUG), the Florida Assoc. of PC Users Groups, Inc.,the Assoc. of Shareware Professionals and we are members of the America Online Ambassador Program.
See http://www.spcug.org for all reviews from the Sarasota PC Monitor, go to the Newsletter Section.
For more information on the Tulsa Computer Society click here
This page has been accessed
times.
Tulsa Computer Society 11/08/97
Don Singleton, President
tcs@galstar.com