mIRC Homepage
Posted By: Artalus Removing subclass in UnloadDll causes crash - 14/02/17 03:15 PM
Hello everyone! Developing a small autocompletion tool for mIRC I've encountered a problem. At dll loading (/dll plugin.dll Start) I subclass the current channel window with my own WndProc. When I later remove this subclass in UnloadDll, direct call "/dll -u plugin.dll" causes immediate termination of mIRC. However if I remove the subclass in some other function before unloading dll (/dll plugin.dll Stop; /dll -u plugin.dll), everything is fine.

It happens only if I subclass the chat window; subclassing main mIRC window works fine. Also, once I subclass anything else, WinApi's GetLastError() starts flooding with 6 "invalid handle" and 126 "module not found" errors.

For some reason there are also two possible stack traces:
First one in debug mode:
Code:
>	0fa45551()	Unknown
 	[Frames below may be incorrect and/or missing]	
 	comctl32.dll!_CallNextSubclassProc@20()	Unknown
 	comctl32.dll!_MasterSubclassProc@16()	Unknown
 	user32.dll!76466238()	Unknown
 	user32.dll!764668ea()	Unknown
 	user32.dll!764678b0()	Unknown
 	user32.dll!76467d31()	Unknown
 	user32.dll!76467dfa()	Unknown
 	mIRC.exe!014a7f9f()	Unknown
 	mIRC.exe!014ae0e9()	Unknown
 	mIRC.exe!0158ec7c()	Unknown
 	kernel32.dll!@BaseThreadInitThunk@12()	Unknown
 	ntdll.dll!___RtlUserThreadStart@8()	Unknown
 	ntdll.dll!__RtlUserThreadStart@8()	Unknown


And the other in release mode:
Code:
	0f187cd5()	Unknown
 	[Frames below may be incorrect and/or missing]	
 	user32.dll!76466238()	Unknown
 	msctf.dll!ATL::CComPtr<struct IBackingStoreHolder>::CComPtr<struct IBackingStoreHolder>(struct IBackingStoreHolder *)	Unknown
 	msctf.dll!CicBridge::OnSysKeyboardProc(unsigned int,long)	Unknown
Posted By: Wims Re: Removing subclass in UnloadDll causes crash - 14/02/17 03:18 PM
Please provide the source code of the dll
Dll source example

The crash is caused even at unloading this simplest dll.
Quote:
At dll loading (/dll plugin.dll Start) I subclass the current channel window with my own WndProc. When I later remove this subclass in UnloadDll, direct call "/dll -u plugin.dll" causes immediate termination of mIRC. However if I remove the subclass in some other function before unloading dll (/dll plugin.dll Stop; /dll -u plugin.dll), everything is fine.

This means that Windows is sending messages related the subclass when you unload it. You will need to follow the steps you have described: remove the subclass first, return control to mIRC to allow it to process any Windows messages, and then unload the DLL.
So you mean that this is more of a feature than a bug? Is there a way then to somehow unload dll from the dll itself after a small timeout? Like, on "/dll plugin.dll Stop" the Stop() function would fill the char* data with "/wait 500; /dll -u plugin.dll".
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.
© mIRC Discussion Forums