.NET and ActiveX, using Thread.Abort()

There may be situations where one is forced to use ActiveX components within a .NET application. It is quite possible that you may overcome the overhead of Interops and Cross-thread marshalling that needs to happen in such cases (Note that ActiveX threads are STA, forcibly).

One thing to beware of is the handling of an exception when Thread.Abort() is called on the code which is currently being executed in the COM context, or by the ActiveX component.

It is always recommended that we catch the ThreadAbortException and then decide whether to safely ignore it or to perform a custom action, like alerting the user. Let's say for the sake of the discussion that we would like to just continue processing, assuming that the user has knowingly stopped the further processing of the thread.

Bad. Threads in COM contexts cannot be safely aborted, at least not without causing exception that are not handled by the .NET application or the CLR.

Here's some sample hypothetical code snippet:

try
{
// do some ActiveX stuff here
axComponent.doAction()
// Thread.Abort() is called before the next statement is executed
axComponent.SomeOtherAction()
}
catch(ThreadAbortException ex)
{
// ignore this
}
catch(Exception ex)
{
// the mother of all exceptions
// Surprisingly, this won't handle the exception being thrown.
}

---
Here's more information from various places:

The evils of Thread.Abort: http://www.interact-sw.co.uk/iangblog/2004/11/12/cancellation.

From http://msdn2.microsoft.com/en-us/library/74169f59.aspx:

"If a thread makes an unmanaged call into the operating system that has blocked the thread in unmanaged code, the runtime will not take control of it for System.Threading.Thread.Interrupt or System.Threading.Thread.Abort. In the case of System.Threading.Thread.Abort, the runtime marks the thread for Abort and takes control of it when it re-enters managed code. It is preferable for you to use managed blocking rather than unmanaged blocking."

---
Sometimes, it is just not possible. What do we do in such cases?

We would need to wait until the control returns to the managed context and then not do any further actions by just returning control back. This would mean that we will not call Thread.Abort() anymore, instead set a boolean variable so make sure that we don't proceed ahead.

So, let's add some extra information to the code snippet above and assume that we used to call Thread.Abort() in the Window closing event of a form. Here's the change based on what we have just discussed. New code in blue.

void Window_closing(...)
{
// was previously Thread.Abort()
_isClosing = true;
me.hide = true;
}

// next, use the boolean variable to stop further processing.

try
{
// do some ActiveX stuff here
if (!_isClosing)
axComponent.doAction()
// Thread.Abort() is not called now
// we will just not do anything if the form is to be closed.
if (!_isClosing)
axComponent.SomeOtherAction()
}
catch(ThreadAbortException ex)
{
// ignore this
}
catch(Exception ex)
{
// the mother of all exceptions
// There should be no need to handle any exceptions here.
}


One thing to note is that although we hide the window, the control will be chugging away in the background and only ends once it comes back into managed code and hits the boolean check for (!_isClosing). It's the only reliable way to make sure that the form is closed properly without throwing exception for the OS to handle.