News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

weird error keeps bugging me

Started by gelatine1, October 05, 2015, 08:55:26 PM

Previous topic - Next topic

gelatine1

Hello, I'm still getting a similar problem as described in http://masm32.com/board/index.php?topic=4620.0 but I'll start a new discussion here because that post might contain lots of information which might not all be as useful... (if thats allowed)

Below is my code that gets assembled. But when I try to open the resulting executable i get the following error popup: "Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item.". Weird. But this even gets weirder when I comment the line "jnz @F" in the following code the program does compile again and it is able to get executed too.


.386
.model flat,stdcall
option casemap:none


include \masm32\include\windows.inc
include \masm32\include\kernel32.inc
includelib \masm32\lib\kernel32.lib
include \masm32\include\user32.inc
includelib \masm32\lib\user32.lib
include \masm32\include\gdi32.inc
includelib \masm32\lib\gdi32.lib

ReSizeGLScene proto :DWORD,:DWORD

.code
start:
invoke ReSizeGLScene,512,512
invoke ExitProcess, eax


ReSizeGLScene proc wid:DWORD,hei:DWORD
cmp hei,0
jnz @F
inc hei
@@:
xor eax,eax
ret
ReSizeGLScene endp
end start


This stuff gets even weirder when I replace the code in ReSizeGLScene with the following code:


ReSizeGLScene proc wid:DWORD,hei:DWORD
cmp hei,0
nop
nop ;dummy commands
inc hei
@@:
xor eax,eax
ret
ReSizeGLScene endp


Then the resulting executable works too. And then when I open that file in Ollydbg and edit the binary value of nop nop= 90 90h to 75 03h = jnz short $+3 (or $+5 or somehing, simply said its similar to the jnz @F from before). and that does RUN without errors ???

I dont understand why my program is not working at all and I can't continue programming when I am not able to let that run. anyone who can help me please?

Thanks in advance




jj2007

What do you see in Olly?

ReSizeGLScene proc wid:DWORD,hei:DWORD
cmp hei,0
jnz @F
inc hei


Changing arguments is possible but considered bad programming practice. What do you pass in the real application? Not 512, I suppose? If you pass a pointer, and you change it in place, it will crash.

GoneFishing

Hi,
Perhaps the answer is in your own words from first post :
QuoteBy the way, the content of glwindow.asm is probably not even correct yet (but it 'compiles') and its just useless for now

It's useless to catch bugs for now . Find the first OGL tut : create a window and initialize OGL and try it . 
Search for NeHe Lesson1 code or just look into the attachment
For detailed explanation google for NeHeTutorials_A4_Book.pdf

gelatine1

Quote from: jj2007 on October 05, 2015, 09:38:54 PM
What do you see in Olly?

ReSizeGLScene proc wid:DWORD,hei:DWORD
cmp hei,0
jnz @F
inc hei


Changing arguments is possible but considered bad programming practice. What do you pass in the real application? Not 512, I suppose? If you pass a pointer, and you change it in place, it will crash.

In the real application i pass wid and hei represent the width and height of a window so I do pass a number such as 512. So you're suggesting that I should pass a pointer to the function and use the value pointed to by those pointers?

Quote from: GoneFishing on October 06, 2015, 12:12:12 AM
Hi,
Perhaps the answer is in your own words from first post :
QuoteBy the way, the content of glwindow.asm is probably not even correct yet (but it 'compiles') and its just useless for now

It's useless to catch bugs for now . Find the first OGL tut : create a window and initialize OGL and try it . 
Search for NeHe Lesson1 code or just look into the attachment
For detailed explanation google for NeHeTutorials_A4_Book.pdf

I used exactly that OpenGL tutorial and I wrote the whole thing from tutorial 1 in masm. When I wanted to test it out it gave the error. And then I decided to truncate the program to track down the erroneous part. I believe there are no actual mistakes in this program (except that it has not much of use now.)

GoneFishing


jj2007

Quote from: gelatine1 on October 06, 2015, 02:34:26 AM
ReSizeGLScene proc wid:DWORD,hei:DWORD
cmp hei,0
jnz @F
inc hei


In the real application i pass wid and hei represent the width and height of a window so I do pass a number such as 512. So you're suggesting that I should pass a pointer to the function and use the value pointed to by those pointers?

You are passing hei as an argument on the stack. If it's 0, you inc the stack, that's all. Nothing is returned, so your app will continue with zero height...

rrr314159

@gelatine1,

I don't get any errors running your code. You can increment hei as shown, and it will get the right value (if it was 0, it becomes 1) but only within the proc. When you return, the value you passed is unchanged (if you sent it a variable like "HeightinMainRoutine"). But since you're sending it "512" evidently you don't want to return the changed value anyway. Evidently, you're going to use hei only in the ReSizeGLScene proc; it can't be zero, so if it is, inc it to 1. On my machine, that works fine.

So there's something wrong in your environment, or you're doing something wrong running it ..? I'm using JWasm, if you have ML, maybe it's another ML bug ..? The code is fine, if a little non-standard
I am NaN ;)

gelatine1

Quote from: jj2007 on October 06, 2015, 03:50:32 AM
You are passing hei as an argument on the stack. If it's 0, you inc the stack, that's all. Nothing is returned, so your app will continue with zero height...

according to what ive seen the inc hei instruction gets translated to inc [ebp+C] where ebp is set to esp right after the proc is called and thus no stack pointers or other pointers are altered ?

Quote from: rrr314159 on October 06, 2015, 06:37:21 AM
@gelatine1,

I don't get any errors running your code. You can increment hei as shown, and it will get the right value (if it was 0, it becomes 1) but only within the proc. When you return, the value you passed is unchanged (if you sent it a variable like "HeightinMainRoutine"). But since you're sending it "512" evidently you don't want to return the changed value anyway. Evidently, you're going to use hei only in the ReSizeGLScene proc; it can't be zero, so if it is, inc it to 1. On my machine, that works fine.

So there's something wrong in your environment, or you're doing something wrong running it ..? I'm using JWasm, if you have ML, maybe it's another ML bug ..? The code is fine, if a little non-standard

Yes I am using ML and it is possible that there is something wrong in my environment, Ive set it up some time ago and i dont reallu remember why things are like it is now. One thing that I thought is suspicious is that my C:\masm32\lib (i installed the masm32 folder directly onto the C: drive)
is empty. All the lib files are inside C:\masm32\include though. Also the ml.exe file is found in C:\masm32\bin (in case that would make any difference)

I use a very simple and short .bat file to assemble my program. It looks like this:


ml /c /Zd /coff glwindow.asm
Link /SUBSYSTEM:WINDOWS glwindow.obj
pause


I am not sure about the flags of ml and Link that I use there (like why i use those and why i dont use some other possibilities). I place this .bat file in the same folder as the .asm file and clicking it simply assembles the program.

Can you tell me any mistakes in the environment ? or do you need more details ?

Thanks in advance

rrr314159

ml.exe belongs in bin, but dunno why the lib files weren't in lib dir. I see from your posted code you put them back where they belong, good idea.

We normally don't use /coff; JWasm defaults to OMF, probably ml does too. I'm no expert on this (others here know everything there is to know about it) but definitely suggest, try it without that option, and/or try it with /omf.

Link is fine, as long as your entry point works and the .exe has the name you want (which is evidently the case). And, you could try JWasm - takes a few minutes and of course you can switch back easily. BTW if you type "\masm32\bin\ml.exe /?" at the command line, and similar for link, it will show you all the options.

Again, I'm not the expert; but if removing /coff doesn't do it, still I'm sure the problem has a very easy fix. If your linker demands COFF format, maybe you need a different linker. Someone else knows exactly what to do about this ...
I am NaN ;)

gelatine1

omf is not recognized. and Ill try it out with JWasm. Thanks for the replies  :t

D:\dev\asm\OpenGL\glwindow>ml /c /Zd /coff /omf glwindow.asm
Microsoft (R) Macro Assembler Version 6.14.8444
Copyright (C) Microsoft Corp 1981-1997.  All rights reserved.

MASM : warning A4018: invalid command-line option : /omf
MASM : fatal error A1017: missing source filename

gelatine1

Alright so now I have tried JWasm. First of all I wanted to try one of the samples. I didn't change any of the given sample win32_1.asm and I used the following bat file to assemble the program


JWasm -coff Win32_1.ASM
link Win32_1.obj /libpath:C:\masm32\lib\ kernel32.lib
pause


and guess what..... I got exactly the same error message popping up  :dazzled: :icon_eek:

adeyblue

You can use something like ProcessMonitor to generate a log of file and module accesses the program is trying to do. It lists the error codes too so you can see what is failing and for what reason.

rrr314159

I have MASM 10 and it does have the /omf option; I assume, so does 6.15? But you can't use both omf and coff options! They're mutually incompatible. And, if you run JWasm with no options, it will do omf format. So I still think that might be the problem. But ... if it were surely someone else would have said so; I'm pretty sure adeyblue (and many others) knows more about it than I do. So I recommend (still) try it with omf (for instance, run JWasm with no options, or ML with only omf, no /coff) and if it doesn't help, sorry for wasting your time :icon_rolleyes:
I am NaN ;)

gelatine1

Quote from: adeyblue on October 07, 2015, 12:15:41 AM
You can use something like ProcessMonitor to generate a log of file and module accesses the program is trying to do. It lists the error codes too so you can see what is failing and for what reason.

I downloaded the program and I set some filters and I found out that the program creates this error. I am not sure what to do next with it. I also added the stack and the process list. maybe something happens in ntdll (whatever that is ?). I also removed the -coff flag.

See images below
http://postimg.org/image/c08q9hodh/
http://postimg.org/image/l6r0wrtlx/
http://postimg.org/image/rzrdt1kf9/
http://postimg.org/image/ek8yhc1b9/

gelatine1

Hi,
Thanks everyone who tried helping me out :icon_exclaim:. The solution to my problem was: .............


UNINSTALLING MY ANTIVIRUS. (forgive me I'm angry on my pc because I had already tried deactivating in and that didnt help out)

Greetings