WinBatch Tech Support Home

Database Search

If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.

TechHome

WinBatch
Error Codes

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

General Protection Fault Errors (GPF) and Invalid Page Faults

Keywords: GPF General Protection Fault WBCMP16I.DLL WBCMP32I.DLL
In general, there are three different ways to make a WinBatch program GPFault:
  1. Misformed DllCall statement.

  2. A network connection to the winbatch exe or one of its DLL's gets torn down while the script is still running. 95% of all crashes of this nature occur when the Winbatch EXE and DLLs are on a network server and the link to the network server fails or is remapped or somehow disconnected.

    The solution is to move the programs to the local hard drive.

  3. A network connection to a running application program gets torn down while it is still running, (e.g., the application gpf's, not WinBatch).
A common problem that occurs is something we call the "Loader program problem" where a WinBatch RunWait function does not wait and the script continues, sometimes tearing down net connections prematurely.

You can add a Debug(1) statement to your script file and step thru it a line at a time to isolate the exact line causing the GPF. If you debug thru a RunWait statement, be aware when the debug window re-appears. It should re-appear when the RunWait is satisfied - AND NOT SOONER. If sooner, then it is the loader program problem.

There are special things to worry about with login scripts. They are:

  1. If launched from a login BAT file, use the 
    	start /w compiled.exe
    method.
  2. The program and DLL MUST be local and may not live in the network login directory, if the drive letter is re-assigned during the login process.

Additional Notes:

If you're getting the, "kernal32.dll error - illegal page fault" error from Windows, you should check to see if you're trying to delete an EXE file that is currently running. Check to see if it's running with something like: 
If AppExist("c:\program files\mcafee\validate.exe")
   Message("Error","Validate running.  Cannot update now")
   exit
endif

Cannot find WBCMP16I.DLL Error:

Question:

We have distributed a Winbatch executable which is having a problem for one user. When the Winbatch runs the user gets a message saying the wbcmp16i.dll has performed an illegal operation. I don't know exactly where the Winbatch is failing because I can't duplicate the problem. Any ideas?

Answer:

If you are getting a GPF error with a message about not being able to find "WBCMP16I.DLL": the WBCMP16I.DLL is the internal name of the compiled WinBatch EXE. Something horrible has happened: Probably a network connection is being torn down when WinBatch is running.

The shotgun approach to solving the problem includes:

  1. Distressed virus checkers - especially on the BIG EXE model.

  2. Corrupt exe or dll files.

  3. Hardware fault on target computer.

    If the user zips up the files and returns them to you, could do a filecompare with the originals to verify they did not get corrupted.

  4. Other windows files corrupted - Re-install windows.

  5. Add DEBUG(1) at the top of the script and have user step thru it to determine where it keels over. Quite likely some assumption you make about the users machine is not correct.

Related Question on Invalid page fault in module KERNEL32.DLL:

I have created a WinBatch (WBC 98B) program that installs Office 97 Professional SR-2 onto a PC. It was originally installing SR-1 with no problems. I have also added more code to the program. If you run the program doing a fresh install of Office 97, everything is ok. If it updates from Office 4.3, you get the error pasted below in the WBC Setup program I created. The Office 97 install progress gets to about 50% when this happens. The Office 97 Install continues, but the WBC Setup program obviously terminates. Here is the WB code that is invoked at the time. The commented was the original. (Either line causes the problem) 
	;RunWait("office97\setup.exe","/L custom\custom.lst /B2 /Q1N")

	RunShell("office97\setup.exe","/L custom\custom.lst /B2 /Q1N","",@NORMAL,@WAIT)


	---

	SETUP caused an invalid page fault in
	module KERNEL32.DLL at 0137:bff858cd.
	Registers:
	EAX=c001754c CS=0137 EIP=bff858cd EFLGS=00010202
	EBX=0064fe28 SS=013f ESP=0054ffe0 EBP=00550050
	ECX=8158cf20 DS=013f ESI=0055024c FS=27c7
	EDX=bff76648 ES=013f EDI=00550230 GS=0000
	Bytes at CS:EIP:
	53 56 89 4d f8 57 8b 41 40 8b 75 08 89 45 ec 83 
	Stack dump:

Answer:

I assume you verified that the RunWait never exits.

I'm worried about the generic name of the setup.exe. Maybe for testing call it xsetup.exe

Generally the only thing that will kill WinBatch in this manner is if you terminate the network connections to the Winbatch EXE file or its DLLS. If you are running the script off a network server you might try a test wehere you run it off a local copy instead.

Question (cont'd):

RunWait never exits.

I will try to rename the setup program and also try it locally. (Although this used to work ok prior to adding more code and updating to SR-2). I will let you know the results.

Could you let me know how to get a WinBatch program and dll to move itself to the local machine to continue a setup started on a network?

Answer:

The trick is to have WinBatch restart the same script in a different location. And tell the new script what is going on. This is done by passing parameters.

However, for starters, I would have TWO scripts. One on the network that the user runs. That script copies down the real script to the users PC and runs the real script. The "starter" script would look like 

	temp=Environment("TEMP")
	;make sure temp has a \ on the end
	if strsub(temp,strlen(temp),1)!="\"
		temp=strcat(temp,"\")
	endif
	tempmask=strcat(temp,"*.*")
	tempsetup=strcat(temp,"realsetup.exe")
	FileCopy("realsetup.exe",tempmask,0)
	FileCopy("wbdxx32i.dll",tempmask,0)
	Run(tempsetup,"")
	exit

Resolution:

It works! Used your suggestion to create a second program that copys the setup program and dll to the temp dir on C: and presto, all is well. All I did was pretty up the code you showed me and added curDir=DirGet()to hand over to the second program. Thank you very much for your help. 
Article ID:   W12974

Filename:   General Protection and Invalid Page Fault Errors.txt
File Created: 1999:04:15:16:50:54
Last Updated: 1999:04:15:16:50:54