Demo programs hang after compilation

[asmator]

Hi,

I have a problem executing the demos.

I have compiled (console&Assemble console) the \console\demo1 program successfully. When I execute it, it totally hangs doing nothing. The process stays as a zombie in the tasks. However if I run the pre-compiled "hello.exe" that comes with MASM32, it works just fine. At the beginning I thought it was because I got this error during the installation in my Win8: http://masm32.com/board/index.php?topic=1110.0.

So, to overcome the problem I installed MASM32 in a WinXP, everything ran OK (I didn't get the error I got in Win8) and I overwrote the whole MASM32 directory into my Win8. Now I compile and execute demo1 with no problems.

However, when I try with demo2, I have the same problem again: it compiles but it hangs when running, whereas the pre-compiled proc.exe runs perfectly. I have compared both .exe files to find an explanation, and I get a few differences in the PE header "Virtual Size" of .text and .rdata, and then some differences in what seems addresses for JMP instructions, which I guess is normal.

How can I fix this?  Is it a problem about my installation?

Thanks.

[hutch--]

If you build a console app that has the "inkey" macro without a console, it can never receive the keystroke to make it exit. If its a console app, build it from the Build menu as a console app. Then run it from the command line to see what happens. The "inkey" macro is there so you can run a console app from QE and see the results.

[asmator]

Yes, I have done a "console Assembly & Link".  Regardless of how I run the programs (cmd, from qeditor, from Windows explorer) I always get the same results: my proc.exe hangs (and I am not able to kill it manually) and the original proc.exe runs perfectly.   When I mean it hangs I mean that I only get a black screen, nothing is even printed, like if no instruction has been executed. I tried to use a debugger and it also hangs trying to open the file. That is why I think it might be something to do with the PE, because the code seems the same in both programs.

Thanks

[jj2007]

Weird. Can you zip the exe and post it here? Thanks.

[asmator]

Find it attached. I included some screenshots of what happens.

Thanks.

[jj2007]

They work just fine. The problem seems to be your machine. Do you have an active antivirus that could intervene?

Btw I also launched it with OllyDbg, no problems.

[asmator]

Then it is definitely something with my machine... not sure what, though. It is certainly not the code, since it is too simple and it does not even execute the first instruction... So could be something related to the imported functions?  And actually, now I try to run demo1 (hello.exe) and the pre-compiled version still works and mine doesn't - if launched from Explorer it stays like in the photo attached, with a permanent "working" Windows icon . So something is messing with it.

I have compared again both files and overwrite all bytes in my version with the ones that work except for the compilation date in the PE header and any of the code, and it stills hangs. That is strange because I would not think the code has something to do, but some PE value. If using Olly, Olly itself hangs with my version when it works fine on the original (where is good old Sice in this times) - photo attached.

I have compared both codes and strangely, my compilation has many more bytes and instructions for some unknown reason (photo attached). So I could think it is something with the code, but however, one more detail to make my problem fuzzier... I have tested my version in my VM XP and it works!  So there is something funny between the code and my Win8. The only issue I might think is in the directions the code is using to call kernel32.dll, something that in Win XP would work fine but not in Win8.....

Any ideas?

[asmator]

jj2007, I think you are right.

After testing every possible change in the executables to isolate the portion that was not working, I got some inconsistencies (like identical programs with different compilation times and one works and the other doesn't). So, many tests after, I disable the antivirus and it seems to work.  ::)  And this is probably the reason why I could not kill the process - even though I could not find any handle taken by the antivirus. Now I have two questions:

- Why my compiller generates much more code to do such a simple thing? It seems there are a lot of instructions that are not really necessary, it does not seem to be translating the assembly directly.
- What can be the reason the antivirus breaks it? Maybe a sandbox that for some reason gets stuck?

Thanks

[GoneFishing]

edited


   

[TWell]

- Why my compiller generates much more code to do such a simple thing? It seems there are a lot of instructions that are not really necessary, it does not seem to be translating the assembly directly.

You are using masm32 RTL, not API directly.

[asmator]

- Why my compiller generates much more code to do such a simple thing? It seems there are a lot of instructions that are not really necessary, it does not seem to be translating the assembly directly.

You are using masm32 RTL, not API directly.

I will look into this to see how it works.

Thank you everyone for the help! That was awesome.

[jj2007]

One thing I see in diff_code.jpg is that "original" has a stack frame (push ebp ... leave) while "my version" doesn't have one.

[hutch--]

asmator,

The trick if you are having AV scanner problems is to either get a better one OR set up another user profile that you can perform normal development in without either the OS or an AV scanner interfering with what you write. Also make sure that you don't have any virus or trojan damage on your computer as this can effect how things work. It would do you no harm to download MalwareBytes, update the data files for it and do a detailed scan of your computer. If there is any damage you can delete the damaged files and if anything has been wrecked you should be able to repair it with the install disk if you have one for the OS version you use.

[asmator]

One thing I see in diff_code.jpg is that "original" has a stack frame (push ebp ... leave) while "my version" doesn't have one.

Mmm... and how do I configure this behaviour? Is it something coming from "masm32 RTL" somehow?

asmator,

The trick if you are having AV scanner problems is to either get a better one OR set up another user profile that you can perform normal development in without either the OS or an AV scanner interfering with what you write. Also make sure that you don't have any virus or trojan damage on your computer as this can effect how things work. It would do you no harm to download MalwareBytes, update the data files for it and do a detailed scan of your computer. If there is any damage you can delete the damaged files and if anything has been wrecked you should be able to repair it with the install disk if you have one for the OS version you use.

Thanks. I use Avast actually (the one blocking), and never had this kind of problem before. I have run MalwareBytes a few times during the past days and it reported nothing, thanks for the suggestion. I have contacted Avast to see why they are preventing the execution.

[jj2007]

One thing I see in diff_code.jpg is that "original" has a stack frame (push ebp ... leave) while "my version" doesn't have one.

Mmm... and how do I configure this behaviour? Is it something coming from "masm32 RTL" somehow?

The same source should never produce different code. All our assemblers (ML 6.14 ... 11.0, JWasm, AsmC) do exactly the same. If there is no stack frame, the source was different (see also OPTION PROLOGUE). That is why it is so weird...

I have contacted Avast to see why they are preventing the execution.

No chance, they won't even answer. Their crappy software has a built-in heuristic analyser that shouts foul if it doesn't find the typical footprints of C/C++ code. Solution is to mark your \masm32 and all its subfolders as "don't touch" in the AV settings. Which is not ideal if you plan to sell the software, of course, but for coding as a hobby it's perfectly OK.