flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Windows > 64Bit DLL & DLL_PROCESS_ATTACH

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
jochenvnltn



Joined: 15 Jul 2011
Posts: 60

fasmnewbie wrote:

jochenvnltn wrote:

fasmnewbie wrote:
Try to simplify your DLLMain proc to basic initialization task only. Calling MessageBox and / or ExitProcess will call another DLLs. Replace ExiitProcess with ret. You probably need dummy fixups too.



nope.. that wasn't the problem .. Smile



That's exactly the problem.

1) Calling ExitProcess at the start of a DLL initialization will render all other subsequent modules in your DLL inaccessible / invisible due to sudden exit of the entire DLL. Just use ret.

2) Calling other complicated modules such as MessageBox will clobber your EAX (=TRUE), which is supposed to be the return value of DLLEntryPoint/DllMain.

3) Microsoft strongly advised against calling other libraries in the DLLMain unnecessarily because they might be unsafe.

From https://msdn.microsoft.com/en-us/library/windows/desktop/dn633971(v=vs.85).aspx#general_best_practices

Things to avoid in DLLMain:

- Call LoadLibrary or LoadLibraryEx (either directly or indirectly). This can cause a deadlock or a crash.
- Call GetStringTypeA, GetStringTypeEx, or GetStringTypeW (either directly or indirectly). This can cause a deadlock or a crash.
- Synchronize with other threads. This can cause a deadlock.
- Acquire a synchronization object that is owned by code that is waiting to acquire the loader lock. This can cause a deadlock.
Initialize COM threads by using CoInitializeEx. Under certain conditions, this function can call LoadLibraryEx.
- Call the registry functions. These functions are implemented in Advapi32.dll. If Advapi32.dll is not initialized before your DLL, the DLL can access uninitialized memory and cause the process to crash.
- Call CreateProcess. Creating a process can load another DLL.
- Call ExitThread. Exiting a thread during DLL detach can cause the loader lock to be acquired again, causing a deadlock or a crash.
- Call CreateThread. Creating a thread can work if you do not synchronize with other threads, but it is risky.
- Create a named pipe or other named object (Windows 2000 only). In Windows 2000, named objects are provided by the Terminal Services DLL. If this DLL is not initialized, calls to the DLL can cause the process to crash.
- Use the memory management function from the dynamic C Run-Time (CRT). If the CRT DLL is not initialized, calls to these functions can cause the process to crash.
- Call functions in User32.dll or Gdi32.dll. Some functions load another DLL, which may not be initialized.
- Use managed code.

It wasn't the problem because it was NOT the reason why the DLL did not work. ExitProcess was not needed, but had nothing to do with the not working DLL. Everything else you sum up here has also nothing to do with the reason why the DLL was not working. I got the DLL working as posted in the update.
Post 04 Dec 2017, 09:01
View user's profile Send private message MSN Messenger Reply with quote
jochenvnltn



Joined: 15 Jul 2011
Posts: 60
Again .. to clarify why the DLL was not working


Code:

format PE64 GUI 4.0 DLL
entry DllEntryPoint

include 'win64ax.inc'

proc DllEntryPoint hinstDLL:QWORD,fdwReason:QWORD,lpvReserved:QWORD


.if rdx = DLL_PROCESS_ATTACH; <----- (this was the reason the DLL did not work)

         invoke MessageBox,NULL,szText,szTitle,MB_OK
        .endif

endp


szText db '64Bit DLL!!',0
szTitle db 'Success',0

section '.idata' import data readable writeable
library user32,'user32.dll',kernel32,'kernel32.dll'

include 'api\kernel32.inc'
include 'api\user32.inc'

data        fixups
end         data
                   


Post 04 Dec 2017, 09:15
View user's profile Send private message MSN Messenger Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 891
But revolution is right; Microsoft themselves say it. You should not use MessageBox from a .dll's EntryPoint because if it gets loaded by an app that doesn't import user32 it will crash. The only safe functions are those in kernel32 excluding those mentioned in the list (e.g. synchronization APIs are bad).

Just because it works for you doesn't mean it's good coding practice or that it will work in the future. It's a ticking time bomb. Microsoft write specs for a reason.
Post 06 Dec 2017, 18:11
View user's profile Send private message Reply with quote
jochenvnltn



Joined: 15 Jul 2011
Posts: 60

Furs wrote:
But revolution is right; Microsoft themselves say it. You should not use MessageBox from a .dll's EntryPoint because if it gets loaded by an app that doesn't import user32 it will crash. The only safe functions are those in kernel32 excluding those mentioned in the list (e.g. synchronization APIs are bad).

Just because it works for you doesn't mean it's good coding practice or that it will work in the future. It's a ticking time bomb. Microsoft write specs for a reason.



I case you haven't noticed by now, the example dll was just a test! Why would i create a DLL that only shows a MessageBox ??
Post 06 Dec 2017, 19:47
View user's profile Send private message MSN Messenger Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 891
Well I don't know why it didn't work, but that's because I hate using those "high level" macros and prefer to just code in raw asm (I mean, since I'm doing assembly anyway). And I didn't mean to imply that it was the problem or wasn't a test -- I just thought that you ignored what he said because you thought he was speaking nonsense, based on your tone.

But if you already knew that, then you could've just said it and that it's just a test when he replied. Anyway at least you got it solved. Wink

Also, I meant fasmnewbie, not revolution, sorry for the confusion. Razz
Post 06 Dec 2017, 20:51
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15303
Location: Bigweld Industries

Furs wrote:
Well I don't know why it didn't work ...

The reason it didn't "work" is because the first four caller parameters are not placed on the stack (the stack has the space reserved but it is not initialised with anything), those parameters are only in the registers. So before a procedure tries to use one of the first four caller parameters from the stack it must save it on the stack first; or alternatively use the register value directly without going to the stack.
Post 06 Dec 2017, 21:41
View user's profile Send private message Visit poster's website Reply with quote
jochenvnltn



Joined: 15 Jul 2011
Posts: 60

Furs wrote:
Well I don't know why it didn't work, but that's because I hate using those "high level" macros and prefer to just code in raw asm (I mean, since I'm doing assembly anyway). And I didn't mean to imply that it was the problem or wasn't a test -- I just thought that you ignored what he said because you thought he was speaking nonsense, based on your tone.

But if you already knew that, then you could've just said it and that it's just a test when he replied. Anyway at least you got it solved. Wink

Also, I meant fasmnewbie, not revolution, sorry for the confusion. Razz

Well you could have read the whole tread before commenting .. I think everything from the problem to the solution was very well explained
Post 06 Dec 2017, 22:33
View user's profile Send private message MSN Messenger Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< 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


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.