Subclassing and Hooking with Visual Basic

Caveats

With every other hook I have discussed thus far, I have warned about strongly considering performance when writing the filter functions. You do not have to take performance into consideration when using this hook, however, because this hook is a tool used for debugging purposes. You most likely would not want to release debugging code in the final release of your product.

I’m sure someone out there will find a legitimate reason for keeping a WH_DEBUG hook in the final release of your application. In this case, I would place performance at the forefront when designing this hook’s filter function, because this hook is called once for every hook that you install in your system, plus for every system-wide hook. If your WH_DEBUG hook is a system-wide hook, you intercept calls made to every hook in every thread running in the system. That is a great deal of overhead for an application. In cases such as this, I would force the code to fall through and immediately call CallNextHookEx whenever you encounter a call to a target hook which you do not care about.

Here are a couple of things to remember:

• The WH_DEBUG hook is called once for every filter function that is installed in a filter function chain.

• If you install a thread-specific WH_DEBUG hook and it starts picking up calls to hooks that you have not installed, these extra hook calls are caused by another application installing a system-wide hook.

• Using OutputDebugString and the DBMon utility are far better than writing trace ...