My program calls SetWindowsHookEx to inject my DLL into a single target process. My DLL contains both a WH_GETMESSAGE and a WH_CALLWNDPROC hook:
hGetMessageProcHook = SetWindowsHookEx(WH_GETMESSAGE,
MyGetMsgProc,
hMyDLLModule,
dwTargetThreadId);
hCallWndProcHook = SetWindowsHookEx(WH_CALLWNDPROC,
MyCallWndProc,
hMyDLLModule,
dwTargetThreadId);
I never call UnhookWindowsHookEx. Windows unloads my DLL automatically, after my program terminates (cleanly or not), when the target app next pumps a Windows message. Both hooks are working well.
But on one machine running Windows Server 2016, Process Explorer shows that my DLL sometimes is unloaded without warning, of course my hook doesn't function any more. I have never seen this before. Is this some protection in Windows Server?
Related
I'm working on a DLL for a process that runs on Windows 10. The process has known termination issues that are not in my scope to address. One of those issues is that when the process terminates, I cannot update my own DLL because, according to Windows, that process has that DLL still loaded, even though the process appears nowhere in, for example, Process Explorer. So, my question is, is there a way to force Windows to release that DLL without having to restart Windows?
DLL (Dynamic Link Library) This Library Doesn't Show Up until the Program is running. If You Want to Change the Contents of DLL the Program Should Terminate.
If It Doesn't terminate try Closing it in the Task Manager [NOTE: The Program can be Running as an Background Process].
For full reference Check this Documentation out
-> https://learn.microsoft.com/en-us/troubleshoot/windows-client/deployment/dynamic-link-library
I've created a program that creates a thread, loads a DLL there (LoadLibrary), calls one function in this DLL and unloads it using FreeLibrary.
LoadLibrary and FreeLibrary do not return any error codes, but ProcessHacket2 shows that this DLL still exists in memory. I've verified that my code does not reference this library.
After some time my code repeats these actions and another instance of this DLL appears in the process memory.
If my code will repeats these actions again and again a new instance will remain in RAM. Allocated virtual memory will growth.
I cannot repeat this problem on my development machine and other test computers. Only on one specific server.
It looks like (libmysql.dll):
I want to know how the mechanism of debugger injection works. Why is "Image File Execution Options" so special?
I have two guesses.
CreateProcess will call an internal function that checks against the list of registry keys. If it is found, then it manipulates the arguments and calls the debugger exe instead.
There is some other service listening for CreateProcess calls and intercepts them. It kills the original call or message (if createprocess is a message or message-like), then it runs the new process as if the original caller called it.
My desire is to verify and update components before an application starts. I like the IFEO "feature" but i need to run the original process after the verification step so I need a way to run it without recursing into the updater. I hope that by learning more about the injection system I can get this system working.
This article explains how it works.
In Windows XP and 2003 the user-mode CreateProcess code reads the registry and, if required, launches the debugger instead.
In more recent versions of Windows this functionality has moved into kernel mode.
But neither case seems to involve a general interception mechanism for CreateProcess.
Apparently when I run some 32-bit apps I created using gtkD on Win64 systems with Symantec Endpoint Protection installed and network drives mapped, and try to bring up a file dialog, something in the runtime attempts to load SnacNp64.dll, a 64-bit DLL, into 32-bit address space. This DLL is a component of Symantec Endpoint Protection that's used for networking stuff, hence this error only happening under such a narrow set of circumstances.
When I run a program from a Win64 native console and try to load a file dialog, I get:
The image file C:\Program Files
(x86)\Symantec\Symantec Endpoint
Protection\SnacNp64.dll is valid, but
is for a machine type other than the
current machine. Select OK to
continue, or CANCEL to fail the DLL
load.
When I select cancel everything works fine, and the program seems to suffer no ill effects from the DLL failing to load. When I select ok, I get an access violation, presumably because gtkD tries to load a 64-bit DLL into a 32-bit program.
However, when I run from a Cygwin terminal instead of a native Win64 one, it seems that the Cygwin console catches the error and forces the DLL to be loaded, thus crashing my application.
This error does not seem to happen for other 32-bit GTK-based apps, such as GIMP, on the same machines.
Basically, how do I make absolutely sure that my 32-bit app never tries to load a 64-bit DLL under any circumstances?
How do you properly unload a DLL from all processes when the system-wide hook that loaded them gets unloaded?
From MSDN:
You can release a global hook
procedure by using
UnhookWindowsHookEx, but this function
does not free the DLL containing the
hook procedure. This is because global
hook procedures are called in the
process context of every application
in the desktop, causing an implicit
call to the LoadLibrary function for
all of those processes. Because a call
to the FreeLibrary function cannot be
made for another process, there is
then no way to free the DLL. The
system eventually frees the DLL after
all processes explicitly linked to the
DLL have either terminated or called
FreeLibrary and all processes that
called the hook procedure have resumed
processing outside the DLL.
So what I am looking for, is a method to detect when the hook is unhooked, and then call FreeLibrary from all the processes that were hooked. Are there any other ways to cause instant unloading of a DLL when the hook is unloaded?
Hook dll are unloaded in their message loop. Forcing them to pass in the message loop help to unload them.
Add this after your UnhookWindowsHookEx to force all message loops to wake up :
DWORD dwResult;
SendMessageTimeout(HWND_BROADCAST, WM_NULL, 0, 0, SMTO_ABORTIFHUNG|SMTO_NOTIMEOUTIFNOTHUNG, 1000, &dwResult);
However I still have the issue from time to time. I don't know where it's coming from. I suppose a locked process could prevent the dll to unload, but I have no proof of that.
In general you should use global windows hooking if FreeLibrary is not a required be called. If you do want to do this you can use DLL injection (see for example http://www.codeproject.com/KB/threads/winspy.aspx and http://www.codeproject.com/KB/system/hooksys.aspx) with respect of CreateRemoteThread and LoadLibrary technique. In the case you can do what you want in the remote process. You can combine both techniques.
If you want call FreeLibrary only to do an update of the DLL you can do this in another way. Every DLL which is loaded could be renamed (in cmd.exe for example) to a temporary name and you can call MoveFileEx with MOVEFILE_DELAY_UNTIL_REBOOT flag. Then you can already copy and use new version of the DLL. The old one DLL will be deleted at the next reboot of computer.