Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / Interop / September 2005

Tip: Looking for answers? Try searching our database.

App using legacy DLL not shutting down.

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
cmbardon@engmail.uwaterloo.ca - 14 Sep 2005 12:49 GMT
I'm trying to use a legacy C++ DLL in a .net application, and I'm
running into problems with the application not shutting down if any of
the methods on the DLL are invoked.  I've tried accessing the DLL
through both p/invoke, and directly through managed C++, and the
results are the same.  I start a windows forms application, call any
method on the DLL (all of which seem to work as expected), and then
close the main application form.  This should exit the application, and
does if there are no DLL calls.  Otherwise, the process simply does not
die (I have to manually kill it in the task manager).  Is there
something else that I need to do with interop to make sure that the Dll
actually unloads?
cmbardon@engmail.uwaterloo.ca - 14 Sep 2005 14:39 GMT
It appears that I've solved my own problem, but I'm not sure why the
solution was required.  The DLL in question had a global object that
controlled access to a COM resource.  The class looked something like
this:

class CComWrapper
{
    public:
    DWORD Init(BOOL fMultiThreaded)
    {
        HRESULT hRes = 0;
        if(fMultiThreaded)
        {
            hRes = CoInitializeEx(NULL, COINIT_MULTITHREADED);
        }
        m_obj.Init();
        return hRes;
    }
    ~CComWrapper() { m_obj.DeInit(); };

    CComObj m_obj;
};

CComWrapper ComObj;  //creates the global object

In one of the DLL methods, the CComWrapper object was initialized by
calling the init() method.  The COM object (CComObj) did its own
initialization in its Init() method, which seems to be where the
problem occurred.  In previous C++ apps, the object's destructor would
(presumably) run, and the COM object would be allowed to clean up any
outstanding resources/threads etc.  In the interop case however, it
looks like this method never ran.  My solution was to create a DLL
method that forced the COM object's DeInit() method to be called: once
I did this, my .net application shut down as expected.

What I'd like to know is if anyone can tell me why the .net application
didn't shut down without this call.  I have two ideas:

-The COM objects DeInit() method (called in the wrapper's destructor)
has never actually been called, and in the unmanaged world this just
constituted a leak.  In .net however, the CLR is keeping track of
threads created by unmanaged DLLs, and it isn't allowing an application
to close before killing all of its threads.

-The CLR is keeping the DLL loaded until the appliation has exited, but
the application is waiting for the DLL to unload before exiting,
causing a deadlock (or something similar).

Am I even close?  I'd really like to understand what's going on here.

Oh, and for the record, I had nothing to do with the way that the
legacy DLL was authored, and I know from looking at it that it could be
improved.  A complete redesign isn't really an option here, so I'm
stuck with what's there.  

Thanks for your replies!

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.