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 ...
Get Subclassing and Hooking with Visual Basic now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.