This is neither a feature nor a bug. As the developer of the DLL, you will need to ensure that your DLL is designed to work with the application you are hooking into. It would not be possible for mIRC to cater for all of the situations that another developer creates in an external application. In this case, your DLL needs to make sure that once the subclass is removed, it returns control to mIRC to allow it to process any pending Windows messages, after which it would be safe to make mIRC unload the DLL. I am not sure what the best way to do this would be - someone else on the forum with more experience creating DLLs for mIRC might be able to help though.