Announcement

Collapse
No announcement yet.

Page Fault In Kernel32.dll

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Page Fault In Kernel32.dll

    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


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

  • #2
    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]

    ------------------
    hutch at movsd dot com
    The MASM Forum

    www.masm32.com

    Comment


    • #3
      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
      mailto:[email protected]

      Comment


      • #4
        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>
        Lance
        mailto:[email protected]

        Comment


        • #5
          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



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

          Comment

          Working...
          X