Quantcast
Channel: Common Language Runtime Internals and Architecture forum
Viewing all articles
Browse latest Browse all 1710

Application.ThreadException does not fire when aborting thread.

$
0
0

Hello,

I have a WinForm app which launches some extra windows (tools - kind of "plugins" to provide some specific functionality to the user when requested) in separate threads. Sometimes a tool becomes unresponsive and as a last resort action thw main app tries to get rid of a problem by aborting tool's thread.

A proper SetUnhandledExceptionMode (UnhandledExceptionMode.CatchException) is set along with Application.ThreadException handler. Application.ThreadException is set separately on each tool's thread.

Proper scenario looks like this:

1) Tool's thread is aborted by thread.Abort() from some other thread (or main app thread)

2) Application.ThreadException gets called (error is logged there). Handler lets the execution continue, but ThreadAbortException cannot be stopped which leads to step 3.

3) Tool's thread is aborted and tool's window gets closed. Main app is still running. All other tools remain open and intact.

From time to time things go wrong and the scenario looks different:

a) Tool's thread is aborted by thread.Abort() from some other thread (or main app thread)

b) Application.ThreadException is NOT called. No error is logged - just nothing happens here.

c) Instead of aborting tool's thread CurrentDomain.UnhandledException handler is called which inevitably leads to application shutdown which is not something I would like to happen.

My question is - why sometimes things go wrong? The good scenario happens most of the time. Let's say over 80% everything goes well an tool thread is killed successfully whth no harm to the main App. Is this a .NET bug that sometimes Application.ThreadException is not raised and CurrentDomain.UnhandledException is raised instead?

From my short research I was able to observe that it might depend on what tool's thread is executing when Abort is called. There seem to be sections of code deep under the hood (CLR internals? native code?) which are not dealing with asyngronous thread.Abort() signal. If its true than Application.ThreadException along with SetUnhandledExceptionMode seems to be useless because it is not possible to use it reliably.

I got stuck with this - it shoud work but sometimes it does not. All answeres and suggestions are appreciaded.

PS. I knot that thread.Abort() is evil. As I say - this is the last resort action to continue work and get rid of tools which become unstable/unresponsive (that was also the reason to run tools in separate thread instead making them intrinsic with main App). It does not happen often, however I'd like to see it working rock solid when neccessary.

--

Wishes

Marek


Viewing all articles
Browse latest Browse all 1710

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>