We're going to have to revisit the WaitWindow, because there is a Try/Catch within that method that starts at the top of the method and ends at the bottom of the method, and we're still not catching it, so it's being thrown either before the code enters the try or after it passes the catch.  So, it will need to be reworked to close the thread some other way than aborting it.

Here is a screencap of the exception window, and the details contained.

Thanks

Robin Giltner

The problem is that when a thread is aborted, it tears down any of the wrapping handles that .NET has in place... so, the AppDomain.ThreadException event doesn't fire (which is one of the ones that's handled by our UnhandledException method there in AppMain).  I'll bet it coming from the Waitwindow... we've had problems with it in the past.  It generally manifests on computers that are newer, just like you said, with either Hyper Threading, or dual-core, or multi-proc.  Although I haven't seen it in a while, so I thought we squashed it.  Does it give you the stack trace for the problem?  Id sure like to see the whole thing.

Sorry for the delay in response, I've been trying to write a sample app that exhibits the same behaviour but am unable to.  The application I'm attatching uses the same functions, methods, delegates and objects as our main app does, but this one doesn't seem to throw that error.

One big problem with diagnosing this Exception was that it only happens on the newest computers in the test lab, and then its very random.  Somtimes the exception gets throw, but most times the processes run without a hitch.  And since it isn't reproduceable on our development machines it's been very hard to track down.

Thanks.

Robin Giltner

Well, first of all, if you can give us the code you are executing to create the AbortThreadException we will try to reproduce it here and make sure there is not a bug in the WaitWindow class.

As for threads, this is a more length discussion.   UnhandledExceptions are exactly that, they catch everything that is not implicity handled.....except, for those thrown on another thread.  When an exception is thrown on another thread you may never see the error or you may see another unhandled exception error displayed that is not the actual exception that threw the wrench in the gears.  If you can catch the exception on the thread it was thrown and then pass it up, you can then see it on the main thread.  But if this is happening within the WaitWindow control I would like to try to reproduce it first if we can so that we can plug the whole within the WaitWindow dialog.

I am trying to figure out what all the UnhandledException Catches, and looking at the help file, it seems to catch, well everything.  The only problem I'm having, is I from time to time on certain computer, is a UnhandledException error, with a Thread was being aborted message, giving a

I tried adding another handler for any ThreadExceptions, but that doesn't seem to be catching anything at all.

I tried this with and without using a Delegate in the Sub Main procedure, but the ThreadAbortExceptions still generate windows unhandled exceptions.  If continue is pressed, the function finishes, the waitwindow goes away and everything seems to run fine.

Any idea on how/why to catch ThreadAbortExceptions, and why these pass by the general UnhandledException ?

Robin Giltner

-- sorry, really strugling with delegates, threads, event handlers and exceptions on this one