Preparation
-
The object oriented programming paradigm is fully implemented within the Windows operating system environment. What this means is that the OS has a vast collection of program subroutines already built that client programs can access and use directly rather than have to write a subroutine that does a common task all over again in every single executable. Since Windows can create windows and therefore has all of the executable code to present edged boxes with title bars and menus and so on, then a program can simply ask Windows to even creat itself on screen. Almost all windows programs do this and therefore save all of the development time and effort of writing the code and embedding the bitmaps to generate their own windows. This is the one of the core ideas behind the Windows object model - reusable code libraries. The vast majority of these are called Dynamic Linked Libraries which hints that Windows will pick them up into RAM only when they are requested by an application (or one of its own components) which is another core concept of the Windows object model - dynamic and therefore efficient usage of RAM libraries are loaded into RAM as needed and they are dumped out of RAM when they are no longer needed. Since Windows is over 200MB, if it had to permanently launch all of its libraries into RAM at startup, Windows 98 would have needed far more RAM than the average user could have afforded in 1998.
This means that as a Windows program launches it informs the OS of the list of *.DLL's and other executable code components that it is going to need. If any of these is not in RAM yet, then the OS will search for them and launch them as well. If an executable is misbehaving such as causing an hourglass for a moment and then it does not launch when it is double clicked, then either it or one of its components could be corrupt, or that component may not be "reentrant." This is another core concept of the Windows object model - object instances. If there is more than one window open, then the DLL code used to create windows is in use simultaneously by more than one program. There are two ways that this can be done: 1) The DLL can be loaded twice in full into RAM, in one place for one program and in another place for the other program. This however would tend to fill RAM quickly with endless copies of the same DLL, or 2) the same copy of the DLL can be reentered by more than one program so that one program is using the top part of the program code and another program is executing it further down at the same time. This is called "reentrant." Not all DLLs or not all subroutines within them are reentrant and this can cause crashes if Windows does not start a separate instance or copy of the same DLL; one for each program.
After installing Quikview.exe which is supposed to be a light-weight file viewer for quickly glancing at the contents of Word DOC's to JPEG's it can then be used to inspect the interior of executable files also. This is by far its most powerful usage. This can assist the technician in determining what files are missing or corrupt that the program needs in order run so that they can be found, tested and replaced if necessary.
Open a DOS box and perform the following procedures:
C:\WINDOWS\SYSTEM>debug cvt32.dll
-f 1100 11ff 0
-w
Writing 09000 bytes
-q
This has damaged a DLL that a program will attempt to use in a moment with disastrous consequences. Quickview will then be used to identify what component(s) could have caused the problem.
Procedures
First click on Start > Settings > Control Panel > Add/Remove Programs > Windows Setup. In this window double click Accessories. In the Accessories components window place a check beside Quickview:
Click OK to this window and Apply on the Add/Remove programs window. Provide the location to the Windows 98 installation CABs and then close the applet when the installation is complete. Answer No to the offer to reboot. Back at the desktop click Start > Programs > Accessories > System Tools > Drive Converter (FAT32). You will be greeted by this:
The message box lists the name of the executable that has caused Windows the problem: CVT1.EXE. Open the details and it mentions that an invalid page fault occured in the module CVT32.DLL. This will not always be the correct file, but it is a starting point.
Close the message box and click Start > Find > Files and Folders and type the file name CVT1.EXE in and choose the C: drive in the "Look in:" dropdown box then click Find. Right click on the file and select the Quickview choice:
Quickview recognizes the file as an executable and displays information about it:
Scroll down and notice the "Import Table" section. This lists all of the DLL's that the program attempts to use. Notice that cvt32.dll is the first one listed of several:
At this point list all of the DLL's used by the program. Open the DOS Prompt and change directory to the WIN98 directory that holds all of the CABs. Now use extract to pull CVT32.DLL out of the CAB's into this directory. Now run the command FC to compare the original (damaged) version of the file versus the copy pulled out of the CABs:
C:\WIN98>fc /b cvt32.dll \windows\system\cvt32.dll
The result on screen will scroll off of the screen and end up looking like this:
000011E8: 00 28
000011E9: 00 58
000011EA: 00 C4
000011EB: 00 7E
000011EC: 00 C3
000011ED: 00 CC
000011EE: 00 CC
000011EF: 00 CC
000011F0: 00 8B
000011F1: 00 44
000011F2: 00 24
000011F3: 00 04
000011F4: 00 2D
000011F5: 00 A4
000011F6: 00 03
000011F9: 00 83
000011FA: 00 F8
000011FB: 00 12
000011FC: 00 77
000011FD: 00 0F
000011FE: 00 33
000011FF: 00 C9
C:\WIN98>
FC.EXE is displaying the offset into the file where a difference was found and what value is present in the first file listed in the command and what value is at the same offset in the second file of the command issued.
-
It is important to recognize the difference in output between what FC reports when a damaged file is found and when a file matches the original and is not damaged. Here is FC comparing COMM.DRV already extracted from the CAB's with the one in the SYSTEM folder:
C:\WIN98>fc /b comm.drv \windows\system\comm.drv
Comparing files comm.drv and \WINDOWS\SYSTEM\COMM.DRV
FC: no differences encountered
C:\WIN98>_
-
FC has found the corrupt file and the problem is solved; simply copy the good DLL into the C:\WINDOWS\SYSTEM folder. However, this is a good time to look at how the OS works with DLL's.
-
Whenever Windows launches an executable file, the file requests the amount of RAM that it will need and passes the list of external components that it will need. Most of the time these components are DLLs but they can also be *.EXE's, *.BIN's, etc. Windows is therefore responsible for fetching the DLL's for the program. Here is the default search order which Windows uses to find the DLL's that an EXE has requested:
- The directory where the application resides.
- The current directory (EXPLORER.EXE actively open or last actively open window)
- The Windows system directory. (i.e. C:\WINDOWS\SYSTEM)
- The Windows directory. (i.e. C:\WINDOWS)
- The directories listed in the PATH variable
-
If Windows fails to find the DLL after exhausting all of these possibilities you will receive a big red "X" message box complaining that a necessary file was not found.
-
This search order will be preempted by the following Registry Key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs
If a DLL is listed in this key, then Windows will remember that and whenever a DLL of that name is requested by an executable, Windows will pull it directly from the SYSTEM folder and bypass the default search order. What this means is: if a program is misbehaving or crashing or blowing up with red "X" messages especially immediately after install or reinstall, then open it with Quickview and list the DLL's that it needs. Then do a Find Files and Folder's for these files. If there is more than one of these and one copy is in the SYSTEM folder and the other copy is in the directory where the application's EXE resides then you have found the problem: it has a custom version of the DLL and Windows loads the standard one from the SYSTEM folder which the application does not expect.
-
Applications can put Windows in trouble by overwriting a standard DLL in the SYSTEM directory. This is probably the most common cause of "...performed an illegal...EXPLORER.EXE" messages. SFC.EXE can help if the system will stay stable long enough to run it, but when errors are coming from the OS itself the best bet is to back everything up and reinstall.
-
Now to test the theory about Windows search order and the ability to control it with the Registry key. First rename the bad copy of the DLL in the C:\WINDOWS\SYSTEM folder. Attempt to run the program again and Windows will announce quickly that a required DLL could not be found:
-
Now open Regedit and click Edit > Find > "knowndlls" (no quotes!) and click OK. When Regedit has found it, click Edit > New > String Value. Name it CVT32. Double click it and put the following into the value as its data: "..\..\WIN98\CVT32.DLL" (no quotes!). The situation should now look like this:
-
The reason that you have to put the "up two levels" syntax is that the default path for known DLLs is C:\WINDOWS\SYSTEM (%windir%\SYSTEM actually) so you must lead Windows out of this directory and into the one where the DLL is actually stored and an absolute reference will not do this. Now with regedit still open try to run the Drive Converter again. It should start will no problems. Cancel it and delete the string value just created.
-
Rename the old damaged DLL in the C:\WINDOWS\SYSTEM folder back to CVT32.DLL, start Dr. Watson and then try to execute the program and see what Dr. Watson has to say.
-
Since the above operation found the corrupt DLL and the working original in currently in the WIN98 directory a permanent solution should now be implemented and another possible cause of the problem should be dealt with. It is possible that the reason that the DLL is damaged is because it is stored on bad sectors of the hard drive. Overwriting it with the new fresh version of the file would then place that fresh copy right onto the same bad sectors and problem would persist. To avoid this, rename the bad copy of the file in the system folder to CVT32.BAD allowing it to continue to occupy potentially bad sectors and now copy the good DLL from C:\WIN98 into C:\WINDOWS\SYSTEM; the problem was found and corrected at this point:
C:\WIN98>ren \windows\system\cvt32.dll cvt32.bad
C:\WIN98>copy cvt32.dll \windows\system
1 file(s) copied
C:\WIN98>_
Working complete PC