Click or drag to resize

LocalHookCreateUnmanaged Method

Installs an unmanaged hook. After this you'll have to activate it by setting a proper ThreadACL. HookRuntimeInfo WON'T be supported! Refer to the native "LhBarrierXxx" APIs to access unmanaged hook runtime information.

Namespace:  EasyHook
Assembly:  EasyHook (in EasyHook.dll) Version: 2.7.6684.0 (2.7.6684.0)
Syntax
public static LocalHook CreateUnmanaged(
	IntPtr InTargetProc,
	IntPtr InNewProc,
	IntPtr InCallback
)

Parameters

InTargetProc
Type: SystemIntPtr
A target entry point that should be hooked.
InNewProc
Type: SystemIntPtr
A handler with the same signature as the original entry point that will be invoked for every call that has passed the Thread Deadlock Barrier and various integrity checks.
InCallback
Type: SystemIntPtr
An uninterpreted callback that will later be available through LhBarrierGetCallback().

Return Value

Type: LocalHook
A handle to the newly created hook.
Exceptions
ExceptionCondition
OutOfMemoryException Not enough memory available to complete the operation. On 64-Bit this may also indicate that no memory can be allocated within a 31-Bit boundary around the given entry point.
ArgumentException The given function pointer does not map to executable memory (valid machine code) or you passed null as delegate.
NotSupportedException The given entry point contains machine code that can not be hooked.
InsufficientMemoryException The maximum amount of hooks has been installed. This is currently set to MAX_HOOK_COUNT (1024).
Remarks

Note that not all entry points are hookable! In general methods like CreateFileW won't cause any trouble. But there may be methods that are not hookable because their entry point machine code is not eligable to be hooked. You should test all hooks on common environments like "Windows XP x86/x64 SP1/SP2/SP3" and "Windows Vista x86/x64 (SP1)". This is the only way to ensure that your application will work well on most machines.

Unmanaged hooks will require a native DLL which handles the requests. This way you will get a high-performance interface, because a switch from unmanaged to managed code seems to be rather time consuming without doing anything useful (at least nothing visible); so a hook omitting this switch will be handled one or two orders of magnitudes faster until finally your handler gains execution. But as a managed hook is still executed within at last 1000 nano-seconds, even the "slow" managed implementation will be fast enough in most cases. With C++.NET you would be able to provide such native high-speed hooks for frequently called API methods, while still using managed ones for usual API methods, within a single assembly! A pure unmanaged, empty hook executes in approx. 70 nano-seconds, which is incredible fast considering the thread deadlock barrier and thread ACL negotiation that are already included in this benchmark!

See Also