I've resorted to using the following macro to clear a buffer at the beginning of a loop:

ClearBuffer MACRO buffer
mov edi,offset buffer
mov ecx,sizeof buffer
xor al,al
rep stosb

I'm not positive but I think I borrowed it from a recent forum search on clearing buffers. It's probably a fairly inefficient way to do it, but that's not the problem. The problem is that I also use ecx as a counter in my loop and rely on it for referencing entries in a couple of tables. I just spent about an hour messing with the loop code before trying vkim's vkdebug (can't believe I've never used it before). I wasn't thinking before, because obviously that macro is destroying ecx's contents.

But here's the problem.... If I uncomment the "pushad" and "popad" in the macro or even put a "push ecx" and "pop ecx" around the call to that macro I get a dr watson error messagebox. Right now I'm using winnt4 at work if that makes a difference. If I comment out the ecx preservation lines, everything runs smoothly except the loop only runs through once cause of ecx being trashed.

When I get home I can attack the code with some better debugging tools but at work I'm stuck with only the masm32 package and my brain which apparently aren't enough. :) Does anyone have an idea why windows won't let me preserve ecx here?
Posted on 2002-04-30 17:53:13 by Will
you're probably calling the macro in a callback... you have to preserve
ebx,esi,edi,ebp,esp in callbacks.
Posted on 2002-04-30 18:14:20 by f0dder
Well I feel pretty lazy cause I had every intention to come straight home and debug the crap out of the program, but instead I got my arm twisted into going to the pub right after work and just got home now (11:30).

I'm calling the macro only from within a loop in my WndProc and the only register I use (besides eax) is ecx. Well that's not true. I also use edi (and thus esi right?) in the macro. But the program only crashes when I push and pop ecx. Is it because I don't preserve edi that I use in the macro? Should I do a "uses edi ecx"? It couldn't be that simple of a fix.
Posted on 2002-05-01 00:27:42 by Will
That would be my suggestion.

In my custom edit control, i use 'ebx' as a master pointer to the control's private heap memory. This pointer is assumed (by me) to be transparent and unchanged throughout the various functions,subfunctions, and API's called. By simply placeing "USES EBX" after the Control's WndProc, I dont ever have to worry again about ebx, or how it gets used.

Its my suggestion to do this at the begining of the fucntion/callback that uses ebx, esi, or edi. Then you can be assured that the scope of the function/callback is preserved, and any bugs that occour is not due to 'register trashing' :)

Besides, whats the difference if you place PUSH/POP within your code (or worse, in MACRO's) and not declair any "USES" param, or declairing "USES" params, and not placing PUSH/POP in your code?? There isnt, unless you PUSH/POP in macro's, which can cause multiple's. In this case, your in the hole for both bytes used, and CPU time.

Posted on 2002-05-01 02:47:54 by NaN
It depends on what is happening with the code in the proc that the macro is used with. The register usage of the PROC is what effects the crash, not just the contents of the macro.

Just make sure the PROC it is in observes the normal windows convention of preserving EBX ESI & EDI and then depending on how the proc uses ECX, you may have to save that as well before calling the macro.

To test the MACRO past its code directly into the proc and then see what your register usage is. That should give you a reasonable idea of what is happening.


Posted on 2002-05-01 02:56:57 by hutch--
Well I've found the troublesome line of code that's been crashing the program. I haven't figured out why yet, but ecx isn't holding what it's supposed to (much further along in the proc then where I thought the problem was). Although I would like to take a closer look with softice tonight just to see exactly where my screwup is.

It's still weird that the program doesn't crash until I try to preserve ecx though. I'm scratching my head trying to figure out how a push ecx, pop ecx could crash a program. -shrugs-
Posted on 2002-05-01 08:54:15 by Will
Obviously, push ecx/pop ecx can't cause a program to crash in all but the most rare situations. So, the stack isn't being corrected - easy to test - value of ESP after push should equal value of ESP before pop. Or, the data on the stack is getting trashed by code between push/pop. Or, the joyous combination of the two. :tongue:
Posted on 2002-05-01 09:04:42 by bitRAKE

Or, the joyous combination of the two.

Posted on 2002-05-01 09:43:48 by Will