September 9, 1996
Out, out, damned GPFs. Get thee to a link library!
Last week I described how consultant Michael Green succeeded in ridding his clients of 90 percent of their mysterious General Protection Fault (GPF) crashes. This week, I describe the complete procedure so you can banish them, too.
Green is a senior network analyst for Paranet Inc., a nationwide technical service that supports large computer networks. You can reach Houston-based Paranet at (800) 752-3475 or (713) 626-4800.
When supporting Windows 95, Green found that conflicting versions of DLLs were causing almost all GPFs by Windows applications. These libraries are files that applications install to provide features that an application alone could not ordinarily handle, such as special dialog box controls.
Unfortunately, Microsoft Corp. decreed years ago that shared DLLs are supposed to be written into the Windows System folder. When an older version of a DLL gets installed over a newer version, applications that relied on features of the newer version crash when those features are no longer there.
Vendors are supposed to check the internal version number of DLLs to prevent an older file from replacing a newer one. But even Microsoft has broken that rule occasionally.
Do not follow the procedure below if you are using any of the following Microsoft Office products: Microsoft Office 4.x, Excel 5.0, Word 6.0, PowerPoint 4.0, Project 4.0, or Visual FoxPro 3.0. I'll describe next week how to handle their DLL problems.
Meanwhile, you can begin to identify conflicting DLLs. A cursory examination of my personal system found several different versions of BWCC.DLL (Borland Windows Custom Controls) and several different versions of CTL3D.DLL (Microsoft's own 3-D controls for dialog box buttons and the like).
Step 1. Remove any floppy disks or CD-ROMs from their drives, then use Find to search "My Computer" for files named *.DLL. Click the Name button to sort by file name. Note DLLs of different sizes or dates.
It's OK for duplicate DLLs to be in your System folder and SysBkup (system backup) folder. During start-up, Windows 95 copies important DLLs from SysBkup over differing versions in the System folder.
This is how Microsoft does away with the driver WINSOCK.DLL from competing vendors. (See "How Microsoft disables rivals' Internet software," Sept. 25, 1995, page 42.)
Step 2. Make a complete backup of your system before changing anything.
Step 3. Make sure that the latest version of DLLs needed by your applications are in the System folder, and remove DLLs with the same name from other folders.
Windows will search for a file in the current folder first, then the Windows and System folders, and then in the folders on the DOS Path. You should ideally have only one copy of a shared DLL, and it should reside in System.
Don't assume later date stamps mean a newer file. Instead, right-click on each DLL in the Find window, and then click Properties, Version.
If a DLL displays an internal version number, use that. It is more reliable than the date stamp. Because of the WINSOCK.DLL problem mentioned in Step 1, leave different versions of this DLL in different folders, if found. For safety's sake, change only one DLL at a time, then test each application to spot problems.
Step 4. To determine which application uses which DLLs, download this FINDEXE.ZIP file. Unzip this and run FINDEXE.EXE. Click the Module List button to see which DLLs reside in memory.
When an application experiences a GPF, it's likely to involve a DLL that was recently loaded (near the end of the module list).
I'll have more on renegade DLLs next week.
Brian Livingston is the coauthor of the new Windows 95 Secrets and author of three other Windows books (IDG Books). Send tips to brian_livingston@infoworld.com or fax: (206) 282-1248.
Missed a column? Go back for more.
Copyright © 1996 by InfoWorld Publishing Company
![[Window Manager]](../../../pageone/hedrgifs/clblivin.gif)
