一个有关hook的问题

又加了些资料。。。XD case DLL_PROCESS_DETACH: 你用了这个case那么我猜测你的想法就是让dll在被卸载的时候执行。。。这种想法是完全无法实现的。。。 恩。。。要弄清楚这个问题你得知道DLL_PROCESS_DETACH这个消息是什么时候发出的。。。。 在调用该dll的进程退出时。。。进程加载的所有DLL都会有机会执行DLL_PROCESS_DETACH 但由于各DLL卸载顺序不同。。。所以在你的DLL被卸载之前。。。。USER32.dll和就很有可能已经被卸载了。。。（只是被从该进程空间卸载。。。它如果要执行自己的DLL_PROCESS_DETACH部分的话需要dll使用计数为0） 这个时候在你的dll的DLL_PROCESS_DETACH中执行MessageBox和UnhookWindowsHookEx函数一定会失败。。。应为这2个函数所依赖的user32.dll已经不在该进程的空间里了。。。 所以解决办法就是在user32.dll被卸载之前来执行这个操作。。。可以放在主程序的WM_CLOSE中通过调用你的dll中的导出函数来执行。。。这时候所有的dll都还没有被卸载 在Platform SDK中也提到了在DllMain中（其称之为the entry-point function）尽量不要使用kernel32.dll以外的任何dll提供的API。。。所以你会发现很多比较权威的书里都会说在 DLL_PROCESS_DETACH里就释放释放资源就行了。。。因为这些函数都是由kernel32.dll导出的。。。 [QUOTE]Because Kernel32.dll is guaranteed to be loaded in the process address space when the entry-point function is called, calling functions in Kernel32.dll does not result in the DLL being used before its initialization code has been executed. Therefore, the entry-point function can call functions in Kernel32.dll that do not load other DLLs. For example, DllMain can create synchronization objects such as critical sections and mutexes, and use TLS. Calling functions that require DLLs other than Kernel32.dll may result in problems that are difficult to diagnose. For example, calling User, Shell, and COM functions can cause access violation errors, because some functions load other system components. Conversely, calling functions such as these during termination can cause access violation errors because the corresponding component may already have been unloaded or uninitialized.[/QUOTE] 另外在NT4以上的操作系统中调用ntdll.dll中的函数也应该是可以的。。。它和Kernell32.dll一样是进程创建后就默认加载的。。。不过这东西好用的函数都没导出就是了。。。得自己定位。。。XD