Announcement

Collapse
No announcement yet.

Dialog Show Stack Fault - Win98

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

  • Dialog Show Stack Fault - Win98

    I've a DDT app that is generating a "stack fault in KERNEL32.DLL at address
    016F:BFF73625" when run on Win98. The base address for KERNEL32 is BFF70000
    but the MS DEPENDS tool doesn't show any function near the address of the
    stack fault; the closest one is "FT_EXIT32" at BFF72C89.

    I've traced it down to the DIALOG SHOW MODELESS statement, but beyond that
    I'm a bit stuck. The window partially paints, showing listboxes and textboxes,
    but no labels or buttons.

    The app works fine on my dev PC (Win2K Pro).

    To add to the confusion, I have another DDT app that works fine on 98. The failing
    app does use a few external DLLs, but they aren't called upon until the user
    clicks the "Go" button.

    Does the DIALOG SHOW statement trigger something that would cause Windows to walk
    the DLL dependencies, and finding a problem in an external DLL cause the stack fault?

    Thanks!


    ------------------
    Mark Newman



    [This message has been edited by Mark Newman (edited March 01, 2001).]
    Mark Newman

  • #2
    Mark, I don't know about your specific case, but every time I encounter
    a problem like that in my programs, the cause has almost always (99%)
    been that a handle I was using was wrong.

    Ie. My guess is that either you are using the wrong variable for a
    window/control handle, or the variable(s?) you are using have been
    changed/initialized.



    ------------------
    Bernard Ertl
    Bernard Ertl
    InterPlan Systems

    Comment


    • #3
      Bern,

      Thanks for the reply. That's what I was thinking too, but why does it work ok under
      Win2K? Is Win2k more tolerant of bad handles, even fixing them up as need be?

      I looked at the Win98 DrWatson log, and at the moment of the fault the KERNEL32.DLL
      instruction was "_FREQASM", but that's used all over the place. The nearest
      recognizable API functions were the Translate & Dispatch Message pair.

      Hmmm. I compared the source of the bad app with one that works and I can't see any
      significant difference between them; in fact the good app has 3 times as many
      DDT controls as the bad one, not that it should matter.

      I suppose it's time to start slicing up the app up until the fault goes away.



      ------------------
      Mark Newman
      Mark Newman

      Comment


      • #4
        To my very limited understand, Win2K is much better at trapping
        execution errors that would cause GPF's under Win98.

        It appears that Windows & PB are modeled the same when it comes to
        error handling. Ie. you have to specifically check for errors (like
        using the wrong handle) instead of relying on an interrupt or
        something to tell you that you goofed.

        For example, I've been able to write code (not on purpose!) that sent
        messages to non-existant controls. No system errors occurred, but
        the app didn't function as expected. So it IS possible to be using the
        wrong handle value/variable and experience what you are seeing.

        I would try tracking it down by monitoring what dialogs/controls
        are involved and checking all code related to them.

        Another possibility is that you are referencing an uninitialized/bad
        pointer variable.....


        ------------------
        Bernard Ertl

        [This message has been edited by Bern Ertl (edited March 01, 2001).]
        Bernard Ertl
        InterPlan Systems

        Comment


        • #5
          Anyway you could post a small example that shows the GPF. I seem to spend a lot of time tracking down win 98 gpfs If you can post failing code, I'd be happy to give it a go on a bunch of different machines.
          --Don

          ------------------
          www.basicguru.com/dickinson
          Don Dickinson
          www.greatwebdivide.com

          Comment


          • #6
            Hello, Captain Idiot here!

            Well, I found the trouble. It wasn't in the dialog creation, but in the dialog callback,
            where I had left a DIALOG DOEVENTS call in the WM_PAINT handler. I took that out and all
            is well. That DIALOG DOEVENTS was a remnant of earlier attempts to keep the modeless
            dialog message pump running but I didn't remove it when I switched to a better method.
            Thanks to Bern and Don!

            Be sure to join us next week for another exciting episode of Captain Idiot as he
            fights the never-ending battle of Windows Programming!

            ------------------
            Mark Newman

            [This message has been edited by Mark Newman (edited March 02, 2001).]
            Mark Newman

            Comment

            Working...
            X