UpdateWindow Doesn't Return (to the right place)

[raleeper]

1.  My program crashes and the debugger (the WinDbg that is installed with the Platform SDK) shows, if I am understanding it, the following:

    before invoke UpdateWindow,hwnd
        eip = 401149
        esp = 12ff8c
        ebp = 12ffac

    after invoke UpdateWindow,hwnd
        eip = 40132c
        esp = 12fde4
        ebp = 416930

So it ought to be returning to the next instruction at 40114e with esp and ebp unchanged.  Instead it returns to a seemingly random place in my code with the stack registers (except ss, which is unchanged) wrong.

2.  I am not asking for a solution to this specific problem.  There is something wrong with my code and I will find it or work around it in time.  I would be grateful if anyone could help me understand what is going on or what in general terms might be causing this.

Thanks.

[u]

Looks like the EBX/ESI/EDI problem in your WinProc.

[Tedd]

All I can say is there's something very strange going on with your code :lol
I think you'll need to post it to get any sense out of this one.
UpdateWindow does work fine normally (and I've just tested it to be sure :P) - it returns to the next instruction and without ebp or the segment registers being modified (esp is modified slightly because it removes its argument from the stack, but it's correct.)

[raleeper]

Aborted.

[raleeper]

All I can say is there's something very strange going on with your code :lol
I think you'll need to post it to get any sense out of this one.
UpdateWindow does work fine normally (and I've just tested it to be sure :P) - it returns to the next instruction and without ebp or the segment registers being modified (esp is modified slightly because it removes its argument from the stack, but it's correct.)

I've found the problem and fixed it.

The crash appeared to occur at UpdateWindow because that was the first API function to call my windows p. with wm_paint, and an uinitialized pointer meant my program was trying to read from [00000000], which I guess caused a protection or some other kind of fault.

Next time I get a crash I think I'll see what kind of error message Windows 98 gives.

Thanks.

[TNick]

If you are shure that i's not a stack problem, you could set a conditional break point in your WinProc and see what is going on in there.

Code Select Expand

.DATA
MustStop  DWORD  0
.CODE

.....

WndProc PROC .....
...
.IF MustStop==1
     and edx, edx ; set a breakpoint here in your debugger
     ; int 3        ; or just use int  3
.ENDIF
...
WndProc ENDP


If you think that UpdateWindow is the problem, you can invoke it like this:

Code Select Expand

mov MustStop,1
INVOKE UpdateWindow
mov MustStop,0

Nick

[raleeper]

Iyou could set a conditional break point in your WinProc and see what is going on in there.

Code Select Expand

.DATA
MustStop  DWORD  0
.CODE

.....

WndProc PROC .....
...
.IF MustStop==1
     and edx, edx ; set a breakpoint here in your debugger
     ; int 3        ; or just use int  3
.ENDIF
...
WndProc ENDP

...
Nick

I've found the problem, an uninitialized pointer, but I'll remember the conditional breakpoint technique.

Thanks.

[Tedd]

A less obtrusive way..

Code Select Expand

DEBUG equ 1     ; 0=off, 1=on

.code
    :
if DEBUG
    int 03h
endif
    :

The code inside the DEBUG closure is only generated if DEBUG==1, otherwise it's ignored.

[TNick]

Hello, Tedd! How are you?

I was thinking about a variable because, this way, you may set it just before the function that you're interested in and the breakpoint won't be executed until or after that.

Regards,
Nick