Notifications from DllMain Process and Thread Attach/Detach reasons

[markallyn]

Hello Everyone,

I would like to know if there is a strategy for notifying users when a Dll is called to announce the state of the Dll prior to the actual called function running.  Put differently, when a Process or Thread attaches or detaches what sort of code could be written that would tell the invoking party that the Dll is in one or another condition.

I have played around a bit with a simple printf but this drives legacy_stdio_definitions.lib crazy (see following) .  I have also tried to put a messagebox into the same code, but in this case the dll "cycles" and returns to the announcing messagebox after running the target dll function. 

DllMain proc instance:QWORD,reason:QWORD,unused:QWORD
   cmp      reason, 1            ;"1" is reason for dll_process_attach
   je      attach
   attach:
         mov   r12, instance
         mov hInstance, r12
         mov   rcx, msg1
         call   printf
         jmp   fin   
   
    fin:
    mov rax, TRUE                         
   ret

DllMain endp

Any strategy you folks might suggest would be appreciated.  I've not found anything on the site or the internet that is helpful.  I hope this isn't a silly question.  I fear I have a tendency in that regard.

Mark Allyn

[hutch--]

Mark,

The DLL main (entry point) is to configure the DLL, its not the place for other dynamic code. Dynamic code occurs in the exported functions that you write.

[jj2007]

I use this and never had problems:

Code Select Expand

LibMain proc instance, reason, unused ; Dynamic-Link Library Entry-Point Function
  PrintLine Str$("\nLibMain: reason=%i *********************", reason)
  or eax, -1 ; non-zero
  ret
LibMain endp

[markallyn]

Good evening Hutch and JJ,

Hutch:  Yes, you're right, I know.  But, I had seen something in a Richter book re Windows OS that led me to think that one might be able to create a thread after DLL_PROCESS_ATTACH and so I decided to experiment. 

JJ:  I think I tried something like what you wrote and I think I messed up because it didn't work.  Maybe I'll fool around (this is quite literally what I do in general) and try again.

But, I take Hutch's point and my fooling around will be very brief indeed.

Regards,
Mark

[TimoVJL]

OutputDebugString in handy for dll.
DbgView is handy for that.

[markallyn]

Hutch,

In my earlier post to this thread I neglected to thank you for your posting of "the anatomy of a working 64 bit masm dll" posted on July 24, 2016.  It was very helpful.  There are few examples of dll assembly code apart from Iczelion's 32 bit version in his tutorial 17 of which I am aware.  Thanks again.

Mark