Dialog Show Stack Fault - Win98

[Mark Newman]

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).]

[Bern Ertl]

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

[Mark Newman]

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

[Bern Ertl]

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).]

[Don Dickinson]

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

[Mark Newman]

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).]