32-bit Hooking Fails, 64-bit Hooking Works.

Feb 22, 2009 at 3:19 AM
My development environment is Windows Vista x64.  I have a virtual machine setup with Windows Vista x64 and another one setup for Windows Vista x86.

If I build the FileMon example for both x64 and Win32 (both Debug) and run them in their respective virtual machines the x64 FileMon works as expected while the Win32 FileMon tells me that it can't find the user defined managed entry point.  If I remotely debug the process from my primary Windows Vista x64 computer I can get some more details on it and it appears that it can't find the appropriate constructor for my IEntryPoint implementation.

One thing I did notice is that in the documentation you mention that IEntryPoint needs an Initialize function yet in the FileMon example you implement a Constructor in it's place.  The constructor does work so I have assumed that this is just an error in the documentation.

I have stepped through the code as much as I can but because the error is occuring in the remote process it's not as easy to debug over the network (no debugger is installed on the virtual machines, so I am using Visual Studio remote debugging features).  From the perspective of the FileMon process, it appears to be getting a failed return code from the injected thread.

The exact error (without debugging it) is:
System.ApplicationException Unknown error code (-1073741502): The user defined managed entry point failed in the target process. Make sure that EasyHook is registered in the GAC.  Refer to the event logs for more information. (Code: 13)

The event logs are empty and FileMonInject is in the GAC.  Since FileMon seems to work for everyone else the only thing I can think of is that it's either related to the fact that I'm compiling on x64 (even though I'm compiling for an x86 target) or it's a problem with Vista x86 (not Vista x64).

I can do some more debugging if it would help, just tell me where to look.
Feb 22, 2009 at 3:24 AM
I was mistaken, there is an entry in the Event Logs that reads:
[error]: System.Runtime.Serialization.SerializationException: Unable to find assembly 'EasyHook, Version=2.5.0.0, Culture=neutral, PublicKeyToken=4b580fca19d0b0c5'.

If I look at the GAC while the program is open (start > run > assembly) I can see EasyHook 2.5.0.0 listed with a matching Public Key to the above.
Coordinator
Feb 22, 2009 at 6:44 PM
Also for me it has been a long time since I did anything EasyHook related, so I can't exactly tell you what to do!

The best thing is always to create a dummy process and use the multi-debug feature of Visual Studio to debug the host and target simultaneously. Additionally you should directly link them to the easyhook source code project, so that you are able to set breakpoints in the managed injection loader, because this seems to be the point of failure. It is always helpful to do such debugging at EasyHook source code level and not just your application.
Jun 28, 2014 at 4:29 AM
Edited Jun 28, 2014 at 5:10 AM
Hello,

I've got exactly the same problem than you. I'm trying to hook Internet Explorer (for example) and i got this message :

System.ApplicationException Unknown error code (-1073741502): The user defined managed entry point failed in the target process. Make sure that EasyHook is registered in the GAC. Refer to the event logs for more information. (Code: 13)

I've tried everything, .NET 2.0 and 4.0 (even 3.5), manually register all DLL in gac, run as admin, etc... Nothing works :'(

Does anyone had a solution ? Something to do with "entry point" ? Maybe because it's a multi process application ?

EDIT : More info :
I found in the source the following line : (thread.c)

case 13: THROW(STATUS_DLL_INIT_FAILED, L"The user defined managed entry point failed in the target process. Make sure that EasyHook is registered in the GAC. Refer to event logs for more information.");

So, maybe the description is not correct and the problem is another one...
Coordinator
Jun 28, 2014 at 8:34 AM
Grab the latest 2.7 release, and try the FileInfo or ProcessMonitor examples, they should work fine. This version uses another method for loading .NET. It doesn't require using the GAC either.
Jun 28, 2014 at 8:47 AM
Yep, i've already tried that, same error ! :-/

Maybe it's because of my configuration, i'm running Windows 8.1 x64 .. IE is running under x86 ... but the same error is there.

Image