mIRC Home    About    Download    Register    News    Help

Print Thread
DLL stays locked after unload #267004 19/03/20 02:58 PM
Joined: Dec 2015
Posts: 142
Dazuz Offline OP
Vogon poet
OP Offline
Vogon poet
Joined: Dec 2015
Posts: 142
I was doing some tests, and noticed that mIRC wouldn't let go of one test DLL, even after /dll -u. $dll(0) returns 0, but the file stays locked.

I've never encountered it before with anything else, so it probably has something to do with DllExport and VB.NET combination. I'd still assume this is not intended behaviour.

[Linked Image from i.imgur.com]

The only function the DLL has is HelloWorld, which returns "HelloWorld".

Code
Imports System.Runtime.InteropServices
Imports System.Text
Public Class HelloWorld
    <DllExport(CallingConvention.StdCall)>
    Public Shared Function HelloWorld(ByVal mWnd As IntPtr, ByVal aWnd As IntPtr, ByVal data As StringBuilder, ByVal parms As StringBuilder, ByVal show As Boolean, ByVal nopause As Boolean) As Integer
        data.Clear()
        data.Append("Hello World!")
        Return 3
    End Function
End Class

Re: DLL stays locked after unload [Re: Dazuz] #267005 19/03/20 05:05 PM
Joined: Dec 2002
Posts: 4,736
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,736
Thanks for your bug report. See here for my reply to the same question in a previous thread.

Re: DLL stays locked after unload [Re: Khaled] #267007 19/03/20 06:22 PM
Joined: Aug 2003
Posts: 278
P
Protopia Offline
Fjord artisan
Offline
Fjord artisan
P
Joined: Aug 2003
Posts: 278
I am not a C++ developer and nor do I have access to mIRC's code base, but here is my analysis of possible causes.

FreeLibrary unloads the library if and only if the reference count becomes zero. At this stage I am assuming that there is not a bug in Windows whereby the DLL is not unloaded despite the reference count being zero, so we have to assume that the reason that it is not unloaded is because the reference count is NON-ZERO. So the question then becomes why it is non-zero? Possible causes:

1. Internal mIRC code is loading the DLL more than once. I consider this to be very unlikely as if so it would be likely to cause all DLLs to remain locked.

2. It is an issue of unmanaged code dynamically loading managed code. I suspect that mIRC's code predates the concept of managed code by at least a decade, but it is possible that managed code automatically creates a reference to itself. Further research might come up with examples and fixes in other projects.

3. It could be an issue of the Hello World code - for example, FreeLibrary makes a call to the DLL to allow it to clean up - I don't see any code to handle this call (though it might be done under the covers by .NET) but perhaps this is the cause. Or perhaps something else in the code.

4. Dlls are loaded by mIRC scripts. You have not posted the script you are using to load the Hello World dll nor the output it produces. It could be something in your script which is causing the reference count to be > 0.

I am not sure whether this will help at all, but it is all I can add.

Re: DLL stays locked after unload [Re: Khaled] #267008 19/03/20 06:51 PM
Joined: Dec 2015
Posts: 142
Dazuz Offline OP
Vogon poet
OP Offline
Vogon poet
Joined: Dec 2015
Posts: 142
Oh, damn.

Re: DLL stays locked after unload [Re: Protopia] #267011 20/03/20 08:12 AM
Joined: Aug 2003
Posts: 278
P
Protopia Offline
Fjord artisan
Offline
Fjord artisan
P
Joined: Aug 2003
Posts: 278
Originally Posted by Protopia
I am not a C++ developer and nor do I have access to mIRC's code base, but here is my analysis of possible causes.

5. During development (but not in production) Visual Studio can hook into the DLL for debugging / tracing etc.

Re: DLL stays locked after unload [Re: Protopia] #267012 20/03/20 12:53 PM
Joined: Dec 2015
Posts: 142
Dazuz Offline OP
Vogon poet
OP Offline
Vogon poet
Joined: Dec 2015
Posts: 142
It was a release build in a sandbox.

It could just be some DllExport/VB:NET oddity, I've never encountered it before. Just wanted to see if the combination worked, and it did.