如何检查在调用CallwindowProc时window proc是否未损坏？

Question

I need to call API

CallWindowProc((WNDPROC)lpfnOldProc, hWnd, Message, wParam, lParam);

Now how can I make sure that lpfnOldProc still valid ?

Basically, lpfnOldProc is procedure in another dll and if that dll is unloaded then lpfnOldProc will still be pointing to something but not valid memory?

Are there some memory API's through which I can verify validity of lpfnOldProc ?

Answer 1

Don't worry. You're in a hook proc obviously. Now, even in your absence the program would crash if the original window proc was unloaded and called. It doesn't matter that you're now the caller instead of Windows.

A Window Proc should remain in memory as long as there are existing windows using it. The responsibility for this check lies fully with the code considering the unload, not the callers of the Window Proc (ie you). This responsibility can be summarized in one line: "Don't unload anything still in use."

Answer 2

You can't check. You can set up structured exception handling to catch the fault that will result of the DLL in question has gone away or been replaced by a copy of the Encyclopedia Brittanica mapped into memory.

Answer 3

Happened something similar in the pass, name two or more dll trying to override a window proc. Normally as part of the process shutdown, or a plugin unload, they try to restore the "oldWndProc", but since they are not aware of each other they may end up overriding a good pointer with an invalid pointer and then crash happens.

If you have access to the source code the best you can do is to have only one dll responsible for hooking a window proc, and then the rest can implement a kind of delegate, so when unloding it can be set to null, and the hooking dll can check and if it is null skip the call.

If you don't have access to the source code, perhaps because you are trying to make your dll work with an already very popular (and buggy) plugin, you may try to find a repeteable procedure so you can detect this case of corruption before it happens (check some of messages before your crash), and workaround it with a custom message notifying your wndproc.