Impossible to find bug...

[ThoughtCriminal]

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]

[Mincho Georgiev]

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.

[ThoughtCriminal]

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]

[manhattan]

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 ?

[ThoughtCriminal]

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.

[gabor]

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

[zooba]

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

[Mincho Georgiev]

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]

[MichaelW]

The problem could not be the alignment of the WNDCLASSEX structure because it's LOCAL.