Index
> Windows > WIN7 64-bit CreateProcess problem |
| Author |
|
|
shutdownall 19 Aug 2014, 20:00
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 !  |
|||
19 Aug 2014, 20:00 |
|
|
shutdownall 19 Aug 2014, 23:26
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. 
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. |
|||
|
19 Aug 2014, 23:26 |
|
|
revolution 19 Aug 2014, 23:52
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.
|
|||
|
19 Aug 2014, 23:52 |
|
|
l_inc 20 Aug 2014, 00:35
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 |
|||
|
20 Aug 2014, 00:35 |
|
|
shutdownall 20 Aug 2014, 10:22
l_inc wrote: shutdownall 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.  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. |
|||
|
20 Aug 2014, 10:22 |
|
|
l_inc 20 Aug 2014, 10:54
shutdownall
Quote: And it is not the age of a machine than the age and type of the OS. 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 |
|||
|
20 Aug 2014, 10:54 |
|
|
l_inc 20 Aug 2014, 11:37
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 |
|||
|
20 Aug 2014, 11:37 |
|
|
shutdownall 01 Sep 2014, 17:25
l_inc wrote: shutdownall 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.
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 ? |
|||
|
01 Sep 2014, 17:25 |
|
|
l_inc 01 Sep 2014, 19:17
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 |
|||
|
01 Sep 2014, 19:17 |
|
|
shutdownall 01 Sep 2014, 21:48
Thanks again, will check that out.
|
|||
|
01 Sep 2014, 21:48 |
|
< Last Thread | Next Thread > |
Forum Rules:
|