I tried searching for some info on this and didn't find anything x86 ASM specific.  Searched this site and didn't find anything relevant at all.

I am trying to isolate the possibility of either IDE I am using (easycode masm) or the compiler I am using MASMv10 for a crash I am having.

What happens is that in my window proc I move the wParam to eax then shift then check for BN_CLICKED (of course after I check uMsg == WM_COMMAND).  If a button was pushed then do this

STD
Invoke SetDlgItemText, hWnd, IDC_WINDOW1_STATIC1, Addr blah

blah is just a db "stuff",0 in the DATA section

I thought this is an IDE issue because it does some fancy stuff with creating the exe (managing the DispatchMessage TranslateMessage etc).  Is there anyone that could put these two lines (and replace IDC_WINDOW1_STATIC1 with whats on the window) in their window proc and see if it crashes? Am I going crazy? Why does it matter if the direction flag is set???

Here is the thread I started at Coders Corner that has the full code. http://manoscoder.gr/phpBB3/viewtopic.php?f=8&t=356
Posted on 2011-09-07 23:18:12 by GoldStar611
I'd like to see the error in more detail.
Specifically, I would like to know the particulars of the GPF, and the state of the cpu at that time.
Post an archive containing the binary executable, and I'll look into it.
Posted on 2011-09-08 02:21:49 by Homer
error 413 request entity too large when I try to post the program. I uploaded it here
www.tdidb.com/Debug.zip

I tried to find a program that comes with windows 7 and calls this function to manually set the direction flag in olly but failed to find anything
Posted on 2011-09-08 14:18:39 by GoldStar611
Opened up MSTSC.exe under olly, and set breakpoints on all SetDlgItemTextW (the unicode veresion)
Ran the program and broke on the first function, set the direction flag..no noticable affect.
got to the second breakpoint, set the direction flag again and EIP, EAX and a few others ALL went to 00000000

If you are persistent enough in charmap.exe toggleing the direction flag will eventually cause an error in ntdll....now I was setting the direction flag just before the call (I used a BP) then stepped over the call and it errors out eventually
Posted on 2011-09-08 14:26:58 by GoldStar611
Direction flag
The rules for the direction flag is the same in all systems. The direction flag is cleared by
default. If the direction flag is set, then it must be cleared again before any call or return.


agner.org/optimize/calling_conventions.pdf

I am trying to isolate the possibility of either IDE I am using (easycode masm) or the compiler I am using MASMv10 for a crash I am having.
Hehe, no third option eh :-)
Posted on 2011-09-08 16:46:37 by drizz
Interesting, must be some sort of "optimizations" ...make the caller ensure everything is setup right so I dont have to...

Thanks for that link
Posted on 2011-09-08 17:26:14 by GoldStar611
Wouldn't have suspected dflag would in any way impact on this api function, I'll likely poke around in there on the weekend just for my own curiosity.
Posted on 2011-09-09 04:46:56 by Homer

Interesting, must be some sort of "optimizations" ..
No. No more than an "optimization" when you preserve: esi edi...  rsi rdi ... stack alignment... etc etc
There are rules and you must apply them.


Wouldn't have suspected dflag would in any way impact on this api function, I'll likely poke around in there on the weekend just for my own curiosity.
It would if it uses string intructions and expects dflag to be cleared by convention.






Posted on 2011-09-09 09:53:05 by drizz
In your Debug.zip file, your Window1Procedure is over-commented. If we remove the comments completely and look at what the assembler sees, it equates to:

Window1Procedure Proc hWnd:HWND, uMsg:ULONG, wParam:WPARAM, lParam:LPARAM

Mov Eax, wParam

Shr Eax, 16

Std


Invoke SetDlgItemText, hWnd, IDC_WINDOW1_STATIC1, Addr blah
Xor Eax, Eax
Ret

Window1Procedure EndP


Not sure how Windows will react with this code, but keep in mind that this SetDlgItemText function is being called on EVERY message (even the WM_NCCREATE). What's probably more important is the fact that you are returning false on the WM_NCCREATE event which makes CreateWindowEx return a NULL pointer instead of a valid window handle.

I'm not saying that this is specifically the error that's causing you problems, but that's where I would start. Try removing some of those comments and if it's still causing you problems, keep in mind that any API function that uses strings expects the dflag to be cleared.

The core Win32 functions will preserve the values of EBP, EBX, ESI, EDI, and DF. On entry, the direction flag, DF, is expected to be cleared for ascending mode in string ops.


Regards,
Bryant Keller
Posted on 2011-09-09 16:10:21 by Synfire
Thanks Synfire, those commented sections were to (hopefully) communicate that I knew how to properly filter the message into firing only when I push the button.  I commented them out to see if it was SOLELY the STD + INVOKE that were making a mess..not MASMs macro for .IF .ENDIF etc...
Posted on 2011-09-09 16:43:45 by GoldStar611