Page Fault In Kernel32.dll

[Tim Wisseman]

I have a program that compiles fine and makes a 653K EXE
file. When I run the program on NT 4 Service Pack 6, or Windows 98, or
Windows 95, or a Windows 2000 machine the program crashes with a page
fault in Kernel32.dll, which is a very odd place for a page fault. . .

The machine code at the crash point always involves trying use data at
memory address [ebx] and the register ebx always contains a 0 that came off the stack.
It appears that a value of 0 is being passed to Kernel32.dll instead of a good memory address.

I am making these three calls to the Kernel32.dll:

DECLARE FUNCTION GetShortPathName LIB "KERNEL32.DLL" ALIAS "GetShortPathNameA" (lpszLongPath AS ASCIIZ, lpszShortPath AS ASCIIZ, BYVAL cchBuffer AS LONG) AS LONG
DECLARE FUNCTION GetCommandLine LIB "KERNEL32.DLL" ALIAS "GetCommandLineA" () AS DWORD
DECLARE FUNCTION CopyFile LIB "KERNEL32.DLL" ALIAS "CopyFileA" (lpExistingFileName AS ASCIIZ, lpNewFileName AS ASCIIZ, BYVAL bFailIfExists AS LONG) AS LONG

. . . and the crash sometimes is near the point CopyFile is used . . .

I am pretty sure these calls are not the cause of the problem.

When I try to find the point that the program
crashes by inserting message boxes the crash jumps to another spot
in the program. It seems to be always near areas where external
DLL's are being called or global arrays are being redimmed, but I am
not 100% sure. If I touch the source the crash spot jumps. If I run
the EXE more than once the crash is in the same spot, the error only jumps
after a new compile after changing the source slightly. So, it is
not acting anything like a normal GFP fault that is very easy to pen point
with messages boxes or a log file. Those normally do not jump at all and are
always in my EXE and DLL files and not the Kernel32.dll.

If I comment out just 300 lines of source the problem will only hit
NT machines (Service pack 4 and 6). The Windows 95, 98 and 2000 machines are
okay or at least seem to be okay, but I do not trust a program that crashes on NT but not 98.

Commenting out around 1000 lines of source anywere in the
program caused the Kernel32.dll crash to vanish on all systems.

To get around this problem I had to move a large piece of code to a DLL
and out of the main EXE. The main EXE has a size of 572K now.

I wonder what is going on?

Tim


------------------

[Steve Hutchesson]

Tim,

From experience, you often get page faults in system DLLs from another
problem in the program. Looking at the functions you have called, I doubt
that the problem is in kernel32.dll at all or for that matter in your code
either.

By the size of the compiled EXE, it looks like you may have found one of
the limits in the compiler which is dictated by its 16 bit origin.

I once tried to compile a PB exe that has a module of about 13 meg in it
of a binary file converted to DB format but about half way through the
compile, it stopped. It seems that it could not handle a file of that
magnitude without running out of memory somewhere.

What you have done in breaking up the code size is the best way to solve
the problem and it gives you the advantage of being able to dynamically
load the DLL if needed for extra memory efficiency. There is little
advantage in running a stand alone EXE once it gets to a half a meg or
bigger as the load time becomes too slow.

It will of course depend on your app but if you can selectively load bits
of it on a needs basis, the load time will end up a lot faster.

Regards,

[email protected]

------------------

[Lance Edmonds]

As has been pointed out here, PBDLL.EXE is actually a 16-bit application that produces Win32 app's, and as such, is limited to running in a 16Mb address space, along with other 16-bit processes that can eat into that space. Usually NT machines can make more of the 16Mb space available due to the "lack" of 16-bit O/S code (compared to the large amount of 16-bit code in Win9x), so I'm surprised that your problem shows up more in NT.

However, it is hard to see where the problem is without the code to check with, so we can only speculate until we can duplicate the problem ourselves...

Tim, if you can submit the code to Tech Support, we can take a look at what is happening.

Thanks!



------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Lance Edmonds]

Ok, I've just noticed a link in your other message to "big.zip" and this certainly seems to be too large for the compiler.

I've passed the URL to R&D so please leave the link up for a few days to give them time to review the file (or send it to tech support if you want to remove the file from your site).

Thanks!


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Tim Wisseman]

What I am trying to do is make a large source file that
triggers the problem, but is very simple. Big.zip was one of the
tries that caused a GPF in PBDLL.EXE.

If it is a problem with running out of memory while compiling
the key will be making a source file that is a little
too big for the compiler to handle, but the compiler does not
realize it.

. . . or it might be something else like too many globals,
too many subs, or too many strings.

I will keep testing the limits with test source code and
get back to you guys if I can find something.

Mostly, I was wondering if you guys have ever seen anything
like this before.

Tim



------------------