So far.
I use VS 8 with the latest MASM. My program works in the debugger, but when I try to run stand alone an error window pops up. I'm using XP Sp 2.
The funny this is I have the exact same problem if I use Iczelion 3:
Unhandled exception at 0x77d50387 in icz3.exe: 0xC0000005: Access violation reading location 0x0015c101.
I pmed Sluggy since he has VS 8 also. He tried with icz3 and had no problem. Please test the exe made on my machine, and tell me if it crashes.
Details on the problem:
Icz3 source not changed.
It crashed in the call to CreateWindowEx, but the problem is the return from RegisterClassEx.
Using the debugger RegisterClassEx returns a correct 16-bit atom.
Running standalone RegisterClassEx has a 24-bit return. From the error line above 0x0015c101 is the return from RegisterClassEx
Useing GetLastError after RegisterClassEx returns:
ERROR_FILE_NOT_FOUND
2 The system cannot find the file specified.
The exe run in the debugger and stand-alone exe are not different. It is only one exe.
Other windowed programs are running fine, so I doubt user32.dll is corrupt.
Iczelions tutorials have been use for years with no bugs, but icz3 and my app both use RegisterClassEx, and both fail. I even used the same values for my WNDCLASSEX.
Has anyone else had the problem of your program working differently in the debugger vs stand-alone? Any idea how to fix these kinds bugs?
The exe is built with debugging info.
Thanks for any help.
[attachment deleted by admin]
well , the source may not changed but how about the cmd line options that you are use to build it ?
Anyway, post the whole project,otherwise it's imposible someone to help you.
Okay I uderstand. Uploaded is the VS 8 project. Everything.
Masm command line:
ml.exe /c /nologo /Fo"Debug\icz3.obj" /W3 /Zi /Gz /errorReport:prompt /Ta
Link command line:
/OUT:"F:\Code\icz3\Debug\icz3.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"Debug\icz3.exe.intermediate.manifest" /DEBUG /PDB:"f:\Code\icz3\Debug\icz3.pdb" /SUBSYSTEM:WINDOWS /MACHINE:X86 /ERRORREPORT:PROMPT kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
The window inc is from MASM32 v7. The latest ML is a little more strict so I had to rem out some non-essential stuff to prevent redefinition errors. Sluggy had the same problem.
[attachment deleted by admin]
On my machine the exe crashes but not the recompiled project.
The calls to CreateWindowsEx is strange on the exe:
0040109B push 0
0040109D push dword ptr [ebp+8]
004010A0 push 0
004010A2 push 0
004010A4 push 80000000h
004010A9 push 80000000h
004010AE push 80000000h
004010B3 push 80000000h
004010B8 push 0CF0000h
004010BD push 40300Fh
004010C2 push eax
004010C3 push 0
004010C5 call 00401146
ADDR ClassName was assembled with a push eax. Did you use the same source ?
I redownloaded the source to make sure I used the same source. I found the problem.
manhattan- you surely know MASM 8 is a bit different. I talked to a friend of mine and he said to make sure the structure is aligned.
So I put align 4 at start ,winmain, and wndproc. And lo and behold it works.
Then I remove the align 4s. Clean the project and rebuild. It still works. It seems like I unstuck MASM somehow. A case of PFM it seems.
The eax is not the problem, the problem was RegisterClassEx giving a 24-bit return. eax is thats 24-bit return being pushed into CreateWindowEx where it failed.
Running standalone RegisterClassEx has a 24-bit return. From the error line above0x0015c101 is the return from RegisterClassEx
0x0015c101 was the return from RegisterClassEx. Should be a 16 bit value.
From a non working exe:
invoke RegisterClassEx, addr wc
00401099 8D 45 D0 lea eax,[ebp-30h]
0040109C 50 push eax
0040109D E8 DC 00 00 00 call RegisterClassExA (0040117E)
[ebp-30h] = 0x0012FE34 00000002
From a working exe:
invoke RegisterClassEx, addr wc
00401099 8D 45 D0 lea eax,[wc]
0040109C 50 push eax
0040109D E8 E0 00 00 00 call RegisterClassExA (401182h)
&[wc] = 0x0012FF7C 00000030
I'm not sure how MASM came up with that, but it was wrong, very very very wrong.
I now really surprised that putting and eax,0000ffffh as a hack to ''fix" the return actually worked. (My now working exe does not use the hack).
Thanks for checking manhattan.
Hello!
Hm, this sympthoms are very familiar. I make a build and it craches. I make a debug build it works fine (this excludes debugging with symbolic info :'().
Okay, than let's have a look at the normal build again. Build, ok, works... ??? :eek Well then build it again. Still works... I don't understand.
Later, after coding a while the last buld crashes again. I play the same game (debug, rebuild).
I think such build is called an 'unstable version' and to clean it up is one of the hardest work. I guess the other forum members too would appreciate some tipps how to track up bugs that can cause such instability.
I won't count on alignment: I have a more stable projects which WndProc and MainWin procedures are not DWORD aligned.
I believe the bugs can be memory leaks, unpreserved registers, trash in the stack, accidentally overwritten memory variables...
Greets, Gábor
Quote from: ThoughtCriminal on February 02, 2006, 07:07:12 PM
I now really surprised that putting and eax,0000ffffh as a hack to ''fix" the return actually worked. (My now working exe does not use the hack).
When you pass a parameter to CreateWindowEx, if the top 16 bits are zero it assumes it's an atom. Otherwise it assumes it points to a text string. So you were probably getting a crash when it tried to read the 'text string' pointed to by an atom with some junk up top. Hence why your hack worked :thumbu
I've recompiled your project too. But the 'bug' as you call it propably is a heap problem /or OS one/.
Try to rebuild it without a manifest and turn off any cmd line option that you don't need.
Here's mine, 1:1 with yours.
[attachment deleted by admin]
The problem could not be the alignment of the WNDCLASSEX structure because it's LOCAL.