Issue: I am trying to inject TWO different DLLS in the SAME PROCESS. But my usecase is, I want to inject one DLL from a admin level process (a windows service), and I want to inject the another in admin-less access (from a simple Exe which runs at user level).
So, I am injecting one DLL through the madshi drivers, and I am injecting other DLL using your user level injection API.
But, when I do so, the process is not opening at all. It is getting stuck somewhere in the mad code hook library.
When I inject both the DLLS either through drivers alone or through user level injection API along, it works fine.
The issue seems to be appearing in the simultaneous injection of two DLLS using two different injection approach.
Are you aware about this issue? Is there any fix for this? Or a workaround? Please suggest.
Hmmmm AFAIK this specific issue has never been reported and is not on the list of bugs to be fixed. Can you elaborate a bit more about the user-level injection from the separate .exe? When is it calling InjectLibrary(), before the process is initialized or after? How is your other .exe getting process creation alerts in order to call InjectLibrary()?
We have written a small user level application which sits as the default app for few file extensions (which out product supports).
Whenever files of those extensions are double clicked, our application (being the default one) gets invoked.
Our job in this application is to dynamically figure out the correct application in which the file should open (say Adobe Reader, MS Paint, MS Office etc).
Withing our application we launch the required app (say the Adobe Reader) using windows 'ShellExecute' API, and then on that handle we call madshi's InjectLibrary function to inject our DLL.
At the machine level, We have one more workflow where in we inject another DLL into Adobe Reader but that is happening through madshi's drivers.
I'm curious, why use ShellExecuteEx() to create a process and inject with the returned process handle when you can simply use madCodeHook's CreateProcessEx() which is designed to do exactly what you're re-engineering. If you have a reason for this, have you tried swapping out ShellExecuteEx() for CreateProcess() to see if the issue goes away? ShellExecuteEx() is a little bit different under the hood and I've seen issues similar to processes becoming frozen/stuck, it may also depend on the flags you're using inside the SEI struct. If you read about the mask which allows for a process handle to be returned it states this on MSDN
It may not always work the way you're currently doing itSEE_MASK_NOCLOSEPROCESS (0x00000040)
Use to indicate that the hProcess member receives the process handle. This handle is typically used to allow an application to find out when a process created with ShellExecuteEx terminates. In some cases, such as when execution is satisfied through a DDE conversation, no handle will be returned. The calling application is responsible for closing the handle when it is no longer needed.