CLOSE Using X Crashes Program

[Larry McAnally]

I've seen several similar post but still can't figure it all out.

My program uses a modal dialog ddt style and everything runs fine until I click the X in the upper right corner to end it or Alt-F4. Then I usually get a crash message asking if I want to send it to Microsoft. the error only occurs after the return to PBMain because I can display a message box there before it crashes and that's the last statement in my code.

I'm new to Windows programming so I'm having trouble understanding how I should terminate my program gracefully. I've closed my open files but do I also have to close the modal dialog somehow within the callback procedure before I can exit?

[Chris Holbrook]

Why not try commenting out sections of your code until it works properly, then work out why! Second best, post the program here and people will debug it for you quite quickly.

Most common causes would include not releasing resources (memory, fonts, DCs) which you have acquired, and letting array indices run amok which sometimes doesn't cause an error right away.

[Cliff Nichols]

Most likely an Array out of bounds, or a invalid pointer (Have you run debug yet? that will clear up most of the problems) Since code not shown, I can only guess.

Also, is the code on a XP or earlier? or a Vista machine?

[Larry McAnally]

Thanks

I take it that the answer to my question about having to do anything special to close the modal dialog is no. That was worrying me after seeing all the postings about postquitmessage and dialog end etc. so I wasn't looking any further.

I have been testing in debug but since the problem only occurs under complex combinations, I haven't been able to follow it that far. However, I now believe it is an array problem since I do have a lot of array activity.

The program is too big to post but I think I can track it down now that I'm satisfied that I'm not failing to close my dialog properly.

Sorry I couldn't give more detail but I believe both postings helped me. I will start trying to narrow it down as suggested. Thanks

[Michael Mattias]

The answer is probably in your dialog procedure, which is not shown.

I don't know DDT very well, but if "DIALOG END " is required, and is not inserted by the compiler as a default action in response to WM_SYSCOMMAND/SC_CLOSE notification, that could be your problem (which you can solve by doing that). But I think DDT probably handles this for you.

More likely is you are doing something you shouldn't either in response to WM_SYSCOMMAND/SC_CLOSE, WM_DESTROY, or following DIALOG SHOW. But without seeing what that is, we just don't know.

[Fred Harris]

Couple years ago I lost the better part of a day tracking down that exact same problem (program crashes when 'X' in title bar clicked), and what I finally tracked it down to was a pointer over-run error involving zero vs one based subscripts in my pointer minipulations. Four bytes were being scrambled in my data segment and no doubt those four bytes had something to do with the 'X' button close out code of Windows. Array minipulations are exactly the same sort of thing, as others have said. Corrupting data like that in your data segment is one of the meanest things you can do as a programmer because it causes the program to act in unpredictable and mysterious ways. While Windows prevents you from messing with data in other processes, it will gladly let you screw up memory in your own data segment. The easiest way for me to check those sorts of things is to generate massive amounts of debug output code while I'm working on the program. PowerBASIC's TRACE feature is good for that, although I use my own file.

[Michael Mattias]

Fred's post reminds me... the "real" error may not even be in your "end of dialog" processing... memory corruption errors may occur long before "end of dialog" but only show symptoms much, much later.

Your best bet may be to run the program with a TRACE.. that will show you if there were any "Error 9" and in what procedures they occurred. From there, additional TRACE functions may help you pinpoint the problem area.

FWIW, you need may need to compile with #DEBUG ERROR ON to make sure the error 9's are trapped and show up in the trace.. which also reminds me.....

Assuming you have not compiled and run with #DEBUG ERROR ON, that might be an even better 'First step". If the program does NOT generate a protection fault when compiled using this option, but DOES generate a protection fault when compiled without that option, for sure the problem is a null pointer or array bound violation "somewhere" in your program.

[Adam J. Drake]

Larry,

There have been times that in a situation like this that I have been unable to determine the cause of the crash beyond possibly doing too much right around close, so I use PostMessage so something gets placed at the end of the message queue, and then do a DIALOG END there.

Example:

        CASE %WM_SYSCOMMAND
            IF (CBWPARAM AND &HFFF0) = %SC_CLOSE THEN
                FUNCTION = 1
                PostMessage CBHNDL, %WM_USER + 2048, 0, 0
                EXIT FUNCTION
            END IF
            
        CASE %WM_USER + 2048
            DIALOG END CBHNDL

[Cliff Nichols]

looking back, I think all my "Unexplained" crashes, occur after the cause of the crash.....may not even show itself until closing.

Typical causes:

1. Array out of Bounds - (Caught if Exe and debug, but not if DLL since I can not use the debug)
2. Thread not finished, so it can not close (What Ye open, Ye must close, to catch this one)
3. Invalid Handles - (Easily replicated, (although I have no clue why M$ even lets me get away with this one) Create multiple dialogs with the same values, and you can see each one, (some minimal interaction, like move it) but when closing these "Ghosts" as I call them, are not really there, and a new dialog has taken its place, so the handle to the "Ghost" is invalid and you get a crash)
4. Invalid Pointers (especially those that are constantly updating) - These are the ones danged near impossible to find without repeated tests on what I call your best "Guesstimation" and sometimes out of your control. (I have one that plagues me with RichEdit, or RTF that I can almost SWEAR its in the callback to show the text, but I have no source to look at the callback to see if the pointer is out of scope, so my only recourse is to protect against my best guess.

My best guess (and I am sure MCM will agree with me on this) is to try to come up with a simple example of the complex code, and you will either go

Orrrrr
Find someone that can point out a fatal flaw that you just can not see (no matter how long you stare at the problem)

[Michael Mattias]

My best guess (and I am sure MCM will agree with me on this) is to try to come up with a simple example of the complex code,

No, he won't agree.

If the program really is this large, when you reduce the program dollars to donuts you will remove the code containing the memory corruption... assuming it really is memory corruption.

First step is check the compile options for #DEBUG ERROR ON. If not compiled this way, do that and see if the problem occurs. If it doesn't occur, then the problem is certainly memory corruption caused by bad use of pointers or array bounds violations.

Assuming it is memory corruption, the second step is to find the "Error 9", which is easily done with either TRACE or the stepping debugger.

When you now find your error 9, check your code; then slap yourself upside the head for making such a rookie mistake.

Note that neither TRACE nor the stepping debugger will identify the use of INVALID pointers; the generated "ERROR 9" occurs only with NULL pointers.

I won't try to sugar-coat it: Finding and fixing memory corruption errors is a very difficult and often time-consuming project. But the time can be reduced by using the tools provided by the compiler.



MCM

[Cliff Nichols]

Ok, so maybe I should have said "simple example of the complex code," but added "that contains the same problem you are currently having"

[Michael Mattias]

Good point, my bad.... if you CAN replicate the behavior in a reduced program, by all means post that.

I'm just trying to prepare Mr. McAnally for the very real possibility that after reducing the program, the error may well be gone; and perhaps attemptimg to isolate the problem using other means might be a more fruitful first step.

MCM