flat assembler
Message board for the users of flat assembler.

Index > Windows > WIN7 64-bit CreateProcess problem

Author
Thread Post new topic Reply to topic
shutdownall



Joined: 02 Apr 2010
Posts: 518
Location: Munich
shutdownall
Hi folks,

when running my specialised FASMW version for 8 bit computers (Z80 version) there is a problem when running under 64bit WIN7 version and gives this exception:

Code:
Faulting application name: FASMW-ZX (2).exe, version: 0.95.11.0, time stamp: 0x53f0c483
Faulting module name: FASMW-ZX (2).exe, version: 0.95.11.0, time stamp: 0x53f0c483
Exception code: 0xc0000005
Fault offset: 0x00027c85
Faulting process id: 0x1e14
Faulting application start time: 0x01cfbbd5cfec8aed
Faulting application path: C:\FASMW-ZX\FASMW-ZX (2).exe
Faulting module path: C:\FASMW-ZX\FASMW-ZX (2).exe
Report Id: 2609b51d-27c9-11e4-a086-00249b0c1257
    


I think it is related to CreateProcess functions I call for starting other programs. Maybe this hint helps from Microsoft for activation compatibility mode:
http://windows.microsoft.com/en-us/windows/make-older-programs-run#1TC=windows-7

But I hope there is maybe a hint how to deal with 64 bit environment and security descriptors.

This is my call which works fine under WIN7 32 bit but gives above exception when running under WIN7 enterprise 64 bit under a different account than administrator:

Code:
  pinfo PROCESS_INFORMATION
  sinfo STARTUPINFO
  mov     [sinfo.cb],sizeof.STARTUPINFO
  mov     [sinfo.dwFlags],0
  invoke CreateProcess,NULL,emulator_name,NULL,NULL,FALSE,NORMAL_PRIORITY_CLASS,NULL,NULL,sinfo,pinfo
    


emulator_name is a full path to the program to execute.
pinfo is uninitialized I think, sinfo like in the example.

I am absolutely not sure about how to use sinfo and pinfo correct - it just worked. So any hint about better usage would be great.

Thanks ! Very Happy
Post 19 Aug 2014, 20:00
View user's profile Send private message Send e-mail Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17254
Location: In your JS exploiting you and your system
revolution
I'd suggest you use a debugger. There are too many "I think"s in there. Better to be sure rather than assume, so as not to be looking in the wrong place.
Post 19 Aug 2014, 20:05
View user's profile Send private message Visit poster's website Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 518
Location: Munich
shutdownall
Nope - doesn't help.
I don't have this WIN7 64 bit to test myself.
It is one guy using it with this special FASMW version.

Anyway debugging would be a bit to hard.

It's not about the "I think"s - if you know how to use security descriptors you may help - if you don't know you probably can not help. Wink

Run as administrator helps but this is a workaround to solve.

So the question is very clear - how to use security descriptors in WIN7 - especially 64 bit environment. To use NULL instead of descriptors is probably to simple and the source for the error. It is definetely a security issue.
Post 19 Aug 2014, 23:26
View user's profile Send private message Send e-mail Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17254
Location: In your JS exploiting you and your system
revolution
For creating a process there is no need to be an administrator. And using NULL for all the security structures is standard procedure for almost all existing programs out there unless you need to run it with some different (i.e. more restricted) privileges. If it runs on Win32 then there should be no reason it won't run unmodified under Win64 unless you are doing something unusual like not checking return codes and simply assuming everything works as hoped. My guess would be that either the program is not found or has a malformed exe header and the returned handle is not valid.
Post 19 Aug 2014, 23:52
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
shutdownall
You put code (fasmz80b.inc and FASMZX81.INC) into a non-executable .bss section started in fasm.inc. Your mod has probably never been run on modern machines... well younger than 10 years old. Otherwise someone would have definitely come across this issue.

_________________
Faith is a superposition of knowledge and fallacy
Post 20 Aug 2014, 00:35
View user's profile Send private message Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 518
Location: Munich
shutdownall
l_inc wrote:
shutdownall
You put code (fasmz80b.inc and FASMZX81.INC) into a non-executable .bss section started in fasm.inc. Your mod has probably never been run on modern machines... well younger than 10 years old. Otherwise someone would have definitely come across this issue.


You are probably right in that and I will test it soon. Thanks for your hints.
And it is not the age of a machine than the age and type of the OS.
It runs fine under WIN7 32 bit. I never tested it under 64 bit or WIN 8.
It perfectly runs under WIN XP. Razz But WIN7 32 bit is also fine.

@revolution

Thanks for your comment. So if security descriptors are never or very rarely used, what are they really for ? Is it really that unimportant ? I thought it must be a security issue but never thought that maybe code is put in a non executable segment. It's long time ago I did this and it just worked.

So I am not a good WIN developer I think, I like to concentrate more at 8 and 16 bit CPUs. That makes fun, too. Wink
Post 20 Aug 2014, 10:22
View user's profile Send private message Send e-mail Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
shutdownall
Quote:
And it is not the age of a machine than the age and type of the OS.
It runs fine under WIN7 32 bit.

That is strange actually. Most probably you have DEP explicitly disabled in your system which is a security issue. I have a 9 years old machine, that was running WinXP SP3 some time ago. The machine supports NX and DEP was disallowing to execute non-executable data. Now it runs Win7 32 bit (after a fair amount of effort) and obviously DEP still prevents non-executable data from running.
Quote:
So if security descriptors are never or very rarely used, what are they really for ?

Those allow you to specify what users or user groups would have access to the process object. E.g. if you have multiple users logged on in parallel on your system, then an access control list would allow you to specify that only users from the administrator group can successfully obtain a handle to your process by calling OpenProcess. I think that makes it pretty much clear, why this feature is only rarely used.
On the other hand a similar feature (called capabilities rather than access control lists) is very often used in microkernel OSes, where access rights specification is the basis of their security mechanisms.

_________________
Faith is a superposition of knowledge and fallacy
Post 20 Aug 2014, 10:54
View user's profile Send private message Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
shutdownall
Sorry. I totally forgot, that DEP is by default set to OptIn. Thus for non-executableness to apply, a program should declare itself to be compatible with DEP. This is done with nx flag (that seems to remain not documented in fasm) using the format directive. I don't have access to a 64 bit OS now, but probably those started to OptOut this behaviour by default.

_________________
Faith is a superposition of knowledge and fallacy
Post 20 Aug 2014, 11:37
View user's profile Send private message Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 518
Location: Munich
shutdownall
l_inc wrote:
shutdownall
You put code (fasmz80b.inc and FASMZX81.INC) into a non-executable .bss section started in fasm.inc. Your mod has probably never been run on modern machines... well younger than 10 years old. Otherwise someone would have definitely come across this issue.


So I now got deeper into this as I have time for to do.
I took a look and there was a include of FASM.INC and I placed my includes after that file. I was not aware that there was opened a new section. Anyway I am not very familiar with sections in detail or WIN application programming in general - it was more a modification of a out-of-the-box source code application FASM. Wink

So it was this code before (which throws exceptions under 64 bit):
Code:
include 'fasm.inc'
include 'fasmz80b.inc'
include 'FASMZX81.INC'
    


The first line was the original (main) code include.
I now changed it to:

Code:
include 'fasmz80b.inc'
include 'FASMZX81.INC'
include 'fasm.inc'
    


Is it really that simple ? Very Happy
Post 01 Sep 2014, 17:25
View user's profile Send private message Send e-mail Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
shutdownall
It is as simple, but still not correct. Code sections normally should not be and are not writable, which is also true for the fasm's ".text" section. However you have at least one variable (wav_bitprec) located in-between you code fragments that you are writing to. This will again cause access violations, and this time on any machine and system. Best practice is to avoid putting data into a code section, even if the data is read-only.

_________________
Faith is a superposition of knowledge and fallacy
Post 01 Sep 2014, 19:17
View user's profile Send private message Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 518
Location: Munich
shutdownall
Thanks again, will check that out.
Post 01 Sep 2014, 21:48
View user's profile Send private message Send e-mail Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.