First of all: You don't need to unhook in your hook dll, madCodeHook does that automatically when you call UninjectLibrary(). Your UnhookAPI() should have no effect, but it shouldn't harm, either.

From the callstack it seems to me that madCodeHook believes that one of your hook callback functions is still "in use". E.g. imagine you have hooked MessageBoxA(). Now imagine Chrome calls MessageBoxA(), your hook callback function calls MessageBoxANext() and the message box is still visible on screen. If you uninject your hook dll in this moment, and if madCodeHook followed your request immediately and unloaded your hook dll from Chrome, in the moment when the user closes the message box, the thread would try to return to your hook callback function, which is now a code section which is no longer even allocated (because your hook dll already got uploaded). As a result the thread would crash with an access violation.

Because of the above stability issue, madCodeHook keeps a record of which hook callback functions are currently in use. And uninjection is delayed until all callback functions are no longer in use. Usually this works fine. It's a very important feature to allow stable uninjection. However, sometimes this can result in uninjection getting stuck, because madCodeHook believes that a hook callback function is still in use. madCodeHook could be right, or it could be wrong. In rare situations this stability check can be overcautious. E.g. if the thread which called MessageBoxA() gets terminated while the message box is still on screen, madCodeHook doesn't notice this and still thinks that the hook callback function is still in use, although it no longer is. But this problem usually only occurs if threads get violently terminated (via TerminateThread), which is not a good thing to do, anyway.

Is it possible that one of your hooked APIs is really still "in use" in the moment when you try to uninject? Which APIs are you hooking?

- We created have a DLL, in which on DLL_PROCESS_ATTACH we have hooked RegisterHotKey() API and on DLL_PROCESS_DETTACH we have unhooked the same API using UnhookAPI() after which we have called FinalizeMadCode(). In our callback of this API we have simply called the nextHook which we got as a out parameter in HookAPI().- This Dll is then injected all the system-wide processes.- Now when we start chrome, it hangs in some dead-lock(same as mentioned in this thread).- And when we don't call Unhook API(as suggested above) we observed that chorme starts properly.- In all our implementation, where we have achieved hooking of API we have called UnhookAPI() before calling FinalizeMadCode() and it seems to be working in all other condition except for this one.

Question :Now just want to know if is it absolutely safe to not call UnhookAPI() before calling FinalizeMadCode() and it is for sure that after calling FinalizeMadCode() our Callback function for the hooked API will never be called?

Yes, it is safe to not call UnhookAPI(). If you look at all the madCodeHook demos, none of them call UnhookAPI() in DLL_PROCESS_DETACH. The only reason UnhookAPI() exists at all is if you want to uninstall an API hook in the middle of something. UnhookAPI() should not be called in DLL_PROCESS_DETACH.

FinalizeMadCHook() should remove all API hooks, so afterwards your hook callback function should no longer be called. Of course it's possible that some thread is still "inside" of your hook callback function from an earlier API call.