COM-Interop, EAccessViolation 在我退出应用程序后

Question

i am having a problem with a ActiveX i am using via COM-Interop. it`s throwing an exception after i exit my Application and i am not sure if this is my fault or the fault of the ActiveX.

is the the correct way to initilize and release an ActiveX via COM-Interop?

Error Message

Sample Code which triggers the Exception

public void CreateInvoice()
    {
        String path = @"";
        FaktNT.OLESrvClass OLESrv = null;

        try
        {
            OLESrv = new FaktNT.OLESrvClass();
            if (OLESrv.MandantLogin2() == 0)
            {
                try
                {
                    //Do Stuff
                }
                catch (System.Exception ex)
                {
                    //Log Error
                    throw;
                }
                finally
                {
                    OLESrv.MandantLogout();
                }
            }
            else
            {
                 //Do Stuff
            };
        }
        finally
        {
            System.Runtime.InteropServices.Marshal.ReleaseComObject(OLESrv);
            OLESrv = null;
            GC.Collect();
        }
    }

Answer 1

You should not need to release the COM object manually using Marshal.ReleaseComObject(). This is done by .net automatically (depending on what you are doing to the reference counting in the native COM code of course).

I would also try to check if the problem originates on the native side (for example in a destructor, which is called when the object is garbage collected).

Is the COM dll generating any native threads, which may be running after the object was garbage collected?

Answer 2

This is not a .NET message, the component itself is trapping the access violation exception. Looks like it was written in Delphi, judging from the exception name. Making native code bomb on an AV doesn't usually require a lot of help. But sure, you may be using the component 'incorrectly'. You stubbed out too much code to really make an informed guess. Other than that making calls on it in a finally block after you caught all exceptions that it might raise is a Bad Idea.

Getting it to bomb on program exit instead of after the GC.Collect() call is not healthy either. Sure sign that you haven't managed to call ReleaseComObject and null all the interface references. That's common, better to leave it up to the garbage collector to do it right. Albeit that this message box is going to bomb the finalizer thread. Yes, you probably need the vendor's help if a thorough code review doesn't help.

Answer 3

i solved the problem now. it was in fact me misusing the COM-Object, i missed to call OLESrv.EngineClose() which closes the COM-Object cleanly.

somehow this little piece of important informationen didn`t make it into the vendors documentation...