Thread.Abort() vs. Unmanaged Code

  • Thread starter Thread starter Christian Kesselheim via .NET 247
  • Start date Start date
C

Christian Kesselheim via .NET 247

Hi!

Quite recently, I've been facing the situation of having to wrapup a (buggy) third-party activex control in .NET in order toexpose its functionality via http webservices. After someunpleasant experiments involving AppDomain's, Thread.Abort(),W32 TerminateThread(), I had everything working exactly the wayI wanted it (clean AppDomain unload in case of an segfaults,etc), except for the rare case in which the OCX itself decidedto go for some endless loop and my thread never returned fromunmanaged code.

After spending some time investigating different newsgroups, etc,it occured to me that there really was no way of terminating athread within unmanaged code in the current version of the .NETframework (1.1). Nevertheless, since I'm not willing (nor able)to throw in the towel yet, I'm still hunting for the bestpossible solution to my particular problem.

Do you think wrapping the nasty OCX into another instance ofSystem.Diagnostics.Process, handling all communication via .NETRemoting and invoking Process.Kill when necessary would meet myneeds, perhaps?

Thnx in advance. Regards,

Chris
 
Chris,

I don't know an answer to your question, just a suggestion

The ActiveX component probably has its own thread behind the scenes (of
COM)? Then maybe there is a way to get the thread handle for the ocx
component, and later try to abort the thread using some api (com api?
win32?).

Another itchy thing I once had with an ActiveX control is the following. The
ActiveX control fired an error-event as the result of calling a method. The
thread that called the method never returned from that call, although the
error handler I attached got executed. The ActiveX control was written in
VB, that might have had something to with it. Anyway, you could check if
your control is firing any events and check if these help to a solution (so
that your component doesn't crash anymore).

HTH,
---
Tom Tempelaere


message Hi!

Quite recently, I've been facing the situation of having to wrap up a
(buggy) third-party activex control in .NET in order to expose its
functionality via http webservices. After some unpleasant experiments
involving AppDomain's, Thread.Abort(), W32 TerminateThread(), I had
everything working exactly the way I wanted it (clean AppDomain unload in
case of an segfaults, etc), except for the rare case in which the OCX itself
decided to go for some endless loop and my thread never returned from
unmanaged code.

After spending some time investigating different newsgroups, etc, it occured
to me that there really was no way of terminating a thread within unmanaged
code in the current version of the .NET framework (1.1). Nevertheless, since
I'm not willing (nor able) to throw in the towel yet, I'm still hunting for
the best possible solution to my particular problem.

Do you think wrapping the nasty OCX into another instance of
System.Diagnostics.Process, handling all communication via .NET Remoting and
invoking Process.Kill when necessary would meet my needs, perhaps?

Thnx in advance. Regards,

Chris
 
If you really need to kill the control and all its threads then your idea is
a good one. That allows you to use the isolation provided by the win32 OS
itself to prevent corruption of the .net process your own code runs in. If
you want to kill a thread in an unclean manner (e.g. using Win32's
TerminateThread from within .net) there are all kinds of problems that you
will run into if the process itself keeps running, so KillProcess is a
preferred mechanism.

message Hi!

Quite recently, I've been facing the situation of having to wrap up a
(buggy) third-party activex control in .NET in order to expose its
functionality via http webservices. After some unpleasant experiments
involving AppDomain's, Thread.Abort(), W32 TerminateThread(), I had
everything working exactly the way I wanted it (clean AppDomain unload in
case of an segfaults, etc), except for the rare case in which the OCX itself
decided to go for some endless loop and my thread never returned from
unmanaged code.

After spending some time investigating different newsgroups, etc, it occured
to me that there really was no way of terminating a thread within unmanaged
code in the current version of the .NET framework (1.1). Nevertheless, since
I'm not willing (nor able) to throw in the towel yet, I'm still hunting for
the best possible solution to my particular problem.

Do you think wrapping the nasty OCX into another instance of
System.Diagnostics.Process, handling all communication via .NET Remoting and
invoking Process.Kill when necessary would meet my needs, perhaps?

Thnx in advance. Regards,

Chris
 
Back
Top