most likely the problem is in catching the WM_DESTROY. instead catch the WM_CLOSE perform the unsubclass there then PostMessage it to the original proc. using SendMessage causes your dll to wait for a return value and after sending WM_DESTROY back to mirc its no longer valid. If you replace the menu its usually safe to destroy the old handle as mirc will recieve the new handle in any menu messages sent to the procedure. i dont think mirc stores the handle globaly as the menu is most likely a resource. more likely it retrieves its handle through GetMenu when altering it such as adding items to command etc.
on newer versions of windows memory leaks can be freed upon termination of the process and/or thread wich caused the leak in the first place. this is not always true however and i would suggest destroying the old handle after replacing it. if for some reason mirc actually is storing the handle globally this could indeed cause a crash if you free it but i dont think thats the case. at any rate trial and error is most likely the best solution.
