Repairing General Protection Errors - General Protection Fault GPF
The first thing you need to know in order to fix a General Protection Fault (GPF), is what is a GPF. So take a moment and read about it here on this site.
Now that you know what causes them, let's fix them. The obvious thing to do is to replace the offending file because it may be corrupted. This may work in some instances. I have read message boards and other sites and everyone has a quick fix. Replace file ??????.dll and reboot. Right, it never works for me when I do it.
So if replacing the offending file does not cure it, you can always format, take the computer to the Doctor or fix the problem yourself.
The problem you have is a mismatched DLL or an incorrect version of a file. It is a simple chore to solve. It just takes a little patience and some understanding of what is going on. Let me walk you through it.
If you elect not to format, and fix this yourself you will need to download System Sentry from this site and install it. Much of what you need to know will be found in the help files of System Sentry, however I will go into a little more depth here about file versions and file dates.
The first thing you do if you have Windows 9x or ME and Windows NT, Windows 2000, 2003, XP and Vista, 2008, & Windows 7 is NOT installed as a dual boot OS.. Open a MSDOS window and type in Fdisk /mbr, at the Windows\Command prompt. The MBR switch will remove the instructions in the Master Boot Record to look for the NT bootup command. It will rewrite the first 446 of 512 bytes of information with zeroes I have found that even when scandisk cannot find an error, the Master Boot Record and FAT1 can be damaged causing errors in VXDs and programs. I repeat, do not do this if you have Windows NT ,2000, 2003, XP and Vista, 2008, Windows 7 is installed, as you will need to reinstall Windows if you use the /mbr switch.
If you wish and you do have an extra hard drive available you can backup the Master Boot Record to it before using the MBR switch. Use Fdisk /cmbr <drive number> where 'drive number' represents the drive you wish to recreate the master boot record. To determine which number to use, have Fdisk display the partition information.
The next item to check is the Fonts folder, especially if you have a lot of fonts. I have 1037 and have found that if the Fonts Key in the Registry becomes corrupted Windows seems to crash a lot. It may also report that it has a problem accessing the Registry.
Once you have installed System Sentry and you have read the help file thoroughly; and you have some idea of how version numbers work, you're ready to fix your General Protection Error. The first step will be to set System Sentry up using the "System Version Checker" and "Check System Files". With this task done, click on" Check System Files" again and System Sentry will create a list of all files that need updating, as well as files that have been added since Windows has been installed, and files that have been overwritten. One of the files in the list will be the fault of the errors you are getting. Restore each file listed as "Needs Updating" and remove them from the list.
THIS IS IMPORTANT:
Before you replace any file, review the current version and date with the original version and date. Remember from the help file that the build number should be either 2 or 4 numbers. Here is how the version number works; 4.10.1998 is Major version # (period) Minor version #(period) Build # and the Optional Lower Build# as in 4.10.1998.0.
Your GPFs are caused by installers (setup programs) that must read the version number without the periods. So lets use this example. A file being installed that has a version number of 3.51.932.89 maybe (notice I use the word maybe) an older version then the existing file (the file already installed) 3.51.3345. The installer will see these versions as 35193289 and the existing file as 3513345. If the installer does not read versions, the existing file will automatically be replaced. Or the installer may replace files based on older dates and not look version numbers.
If the Installer does check versions then it will probably make both version numbers the same length such as 3519328 and 3513345 (7 & 7 characters respectively). If not, then the versions numbers look like this: 35193289 and 3513345 (8 & 7 characters respectively), still allowing the installer to overwrite the existing file. I am sure that you cannot see why version 3.51.3345 is newer then 3.51.932.89, so stay with me. This means that the installer will replace the existing file and the file being installed is an older file than the existing file and should not be overwriting the existing file, but it will. The procedure is very simple, if the FILE_BEING INSTALLED# is greater then EXISTING_FILE# replace it. The true version numbers are 3.51.0932.89 and 3.51.3345. But someone, usually Microsoft, got lazy and forgot the buffer or the zero. Reading the buffer would mean that the build number is 4 digits not 3, and would then tell the installing program where to place the zero.
I for one no longer force a 4 digit number because then I would always be putting a zero in front of the 3 digit number. This could be disastrous, as if the file was 3.51.123 (true version being 3.51.1230.00) and the existing was 3.51.932 (true version being (3.51.9320.00). This would make the installer correct in replacing the existing file.
Not all files use the lower build numbers (00), but these are supposed to be displayed as 2 digits. Many times you will see the lower build number displayed as a single digit. Not all files use a lower build number so this is optional and normally dropped when comparing versions.
This is why not even the Windows Explorer will add the zeros if no buffer or zero is in the version number is inside the file. I guess the people at Microsoft who wrote the original program for DOS have all retired now and forgot to tell the new comers "add a buffer if not the Zero". The System File Checker in Windows 98 has the same problem reading version number. Since it does not give you the option of reviewing the system files you may never find the file that is causing the GPF.
You also read in the help file that using dates are not valid either. The real villain here is not the guy who wrote the software you installed, and not the guy who wrote the setup program, or rather Microsoft which does not follow their own guide lines. Microsoft's right hand does not know what it's left hand is doing.
So lets use an example of a file that can get you in trouble. Please remember that DLLs come in matched sets so that an incorrect version match can cause your GPF. Using the following example of MYdll.dll watch what happens.
MYdll.dll 18.104.22.168 dated 5/1/98 and Mydll.dll 3.51.123 dated 5/11/98 are the same DLL. 3.51.123 dated 5/11/98 is older than the file 3.51.0235 dated 3/28/98. It is fairly safe to make this assumption if the file is only a few months older.
If the file being compared was a year old, 3.51.235 dated 4/13/97 to 3.51.123 then it is fairly safe to say the true version numbers are 3.51.2350 and 3.51.0123 respectively.
Now with all this in mind go down the list that System Sentry created and compare all files that have been changed. If you have any doubt about which file is newer, then use the hyperlink in the help file of System Sentry to check the file in the Microsoft database.
Now use the "Redundant DLL Checker" and Find Newer Versions, comparing the versions and dates. Replace the system file with the newer files. Have little fear about messing up. System Sentry has made a log of files you replaced and from where they came from; as well as a backup of the replaced file so you can undo the replacing of the file by reading the file "Action.log". With this all done use the System Version Checker again and after System Sentry has finished use the "Save These Files" on the System Version Checker. Once you have updated all the files reboot and try reproducing the GPF.
If you still get the GPF you will need to trace which file that is causing it. If you get the message that the Explorer caused a GPF in the Kernel32, I would really doubt that either of these files are the villain. It is most likely being caused by some EXE or DLL that is calling the Explorer or Kernel32.dll.
If you cannot figure out which file you will need a file tracker. I use a program Win-eXpose-I/O to track which files are called and searched for. Or you can use the Import / Exports in System Sentry to see what files another file uses.
Once you have found the file or at least think you found it you can go to the Microsoft DLL database and find which version you need. Then you will need to track down (find) the file on the Internet or on one of your CD-ROMs. If the file is compressed (Mydll.dl_) you can expand it using QikFix. Remember that reinstalling the program may not work because of the way the installer sees version numbers.