help me please, how can it be when such a code:
returns me -1 (ERROR_NOACCESS (000003E6))
but a have full admin rights!
the same problame is when i do like that
CreateFileMapping return handle, but MapViewOfFile returns -1
why is that?
push 0
push FILE_ATTRIBUTE_NORMAL
push CREATE_ALWAYS
push 0
push FILE_SHARE_READ
push GENERIC_WRITE
push offset sof
call CreateFile
returns me -1 (ERROR_NOACCESS (000003E6))
but a have full admin rights!
the same problame is when i do like that
xor esi, esi
push esi
push esi
push esi
push PAGE_READONLY
push esi
push fh
call CreateFileMapping
push esi
push esi
push esi
push FILE_MAP_READ
push eax
call MapViewOfFile
CreateFileMapping return handle, but MapViewOfFile returns -1
why is that?
Probably this...
Windows Server 2003 and Windows XP/2000: If CREATE_ALWAYS and FILE_ATTRIBUTE_NORMAL are specified, CreateFile fails and sets the last error to ERROR_ACCESS_DENIED if the file exists and has the FILE_ATTRIBUTE_HIDDEN or FILE_ATTRIBUTE_SYSTEM attribute. To avoid the error, specify the same attributes as the existing file.
if the file exists
but it does not
Well, without being able to test it I'm afraid you're on your own. Just as a test I would set the file sharing to read/write, it should not make a difference but who knows.
Donkey
Donkey
I uses same parameters to create many files in many od my apps and they always worked. Double-check the filename. Or -as implicitly sugested by donkey- post some binary here, so we can see it.
From the Platform SDK
FILE_SHARE_WRITE - If this flag is not specified, but the object has been opened for write access, the function fails.
So if you open/create it with GENERIC_WRITE, you seem to need (FILE_SHARE_READ OR FILE_SHARE_WRITE).
I know the SDK is pretty ambiguous but that's the way I see it... :lol:
FILE_SHARE_WRITE - If this flag is not specified, but the object has been opened for write access, the function fails.
So if you open/create it with GENERIC_WRITE, you seem to need (FILE_SHARE_READ OR FILE_SHARE_WRITE).
I know the SDK is pretty ambiguous but that's the way I see it... :lol:
From the Platform SDK
FILE_SHARE_WRITE - If this flag is not specified, but the object has been opened for write access, the function fails.
So if you open/create it with GENERIC_WRITE, you seem to need (FILE_SHARE_READ OR FILE_SHARE_WRITE).
I know the SDK is pretty ambiguous but that's the way I see it... :lol:
The FILE_SHARE flags are only for subsequent opens, that is the file is already open by your process and another asks for permission to open a handle. In most cases I set it to 0 when writing as I want exclusive access while I am updating a file. In any case, since you are probably using it to share information between processes (mapping the file) this is not an option for you as the secondary process must be capable of reading the data. Since this appears to be a security issue, ie access is denied, it does little to post any code as my system is probably set up differently than yours. You can verify that you have admin priviledges by calling ordinal 680 of Shell32.DLL (no parameters), a return value of TRUE (non-zero) indicates that you are an admin. The other question is do you have write permissions in the folder where you are creating the file ?
Donkey
i was trying to understand what is wrong and spend all day for this
here is correct code:
but when remove comment at line "sub esp, 10h" (i need that line to allocate some space in stack) then CreateFile say noaccess.
why can that be?
here is correct code:
.486
.model flat, stdcall
option casemap :none ; case sensitive
include kernel32.inc
includelib kernel32.lib
include windows.inc
.data
argv db "result.html",0
.code
start:
; sub esp, 10
push 0
push 0
push CREATE_ALWAYS
push 0
push 0
push GENERIC_WRITE
push offset argv
call CreateFile
add esp, 10h
push 0
call ExitProcess
end start
but when remove comment at line "sub esp, 10h" (i need that line to allocate some space in stack) then CreateFile say noaccess.
why can that be?
The sub esp,10 should have absolutely no affect at all on the CreateFile call. It happens before the first push and contrary to what you have said it does not "allocate space on the stack", it merely moves the stack pointer. The stack is allocated by the PE loader at load time and cannot be modified at run time, it generally defaults to 1MB but that is swithable in the linker. When you PUSH a value onto the stack the value of ESP is updated accordingly and since the CreateFile call uses the STDCALL convention it is corrected on exiting the function. In my opinion if you require that correction to ESP there is quite a bit about your application that you have opted not to show us here and so we cannot be of any help to you. All in all the add esp/sub esp combination does nothing but eat opcodes, it is not within the same scope as the API call.
Donkey
Donkey
10 is decimal 10, not 10h.
You've misaligned the stack from its DWORD boundary.
XP does not like misaligned stacks.
You've misaligned the stack from its DWORD boundary.
XP does not like misaligned stacks.
oh yeah, that's it..
sub esp, 4
works fine )
Donkey, i use that add/sub esp combination for local variables, like C++ compilator do
p.s.
i use w2k
sub esp, 4
works fine )
Donkey, i use that add/sub esp combination for local variables, like C++ compilator do
p.s.
i use w2k
I think what donkey was getting at, is that what compilers like C++ may make look like, is in fact only the adjustment of the stack register that is assigned to a pre-allocated portion of physical memory.
What's most important, is that such processes are understood at machine level, in order to offer greater understanding that will undoubtedly lead to more efficient programming practices no mater what language is used :)
What's most important, is that such processes are understood at machine level, in order to offer greater understanding that will undoubtedly lead to more efficient programming practices no mater what language is used :)