Groups | Blog | Home
all groups > dotnet ado.net > january 2005 >

dotnet ado.net : Re: ThreadAbortException thrown on certain machines...


Gary Joy
1/31/2005 4:51:02 AM
My application uses ADO .NET to access SQL Server and when running on my
development machine will throw a SqlException if I try to do something bad
(e.g. SELECT from a table that does not exist).

However, when running the same application on another machine, although a
SqlException does seem to be thrown, it is a ThreadAbortException that gets
caught - completely killing the application.

Does anyone have any idea why there might be different behaviour on
different machines? The "ThreadAbortException" machine is does not have SQL
Server installed (my machine does) but both machines are accessing a SQL
Server database on a third machine.

Extreme Datasets
2/1/2005 4:11:01 PM
Hello Gary,

First, is this a multithreaded application?

In any case, if an unhandled exception occurs the thread will try to abort
by calling the Thread.Abort method which the clr will throw a
ThreadAbortException.

You can catch this and call the Thread.ResetAbort method to continue working.

Let me know if this helps
[quoted text, click to view]
Gary Joy
2/21/2005 7:31:08 AM
Thanks for posting and sorry for the delay in answering your questions.

1. It is not a multi-threaded application.
2. It is not an "unhandled" exception - that is the problem. The exception
should (and is, on other machines) be caught. For some reason it is throwing
a ThreadAbortException which when caught is automatically re-thrown.

I am aware of Thread.ResetAbort but am very reluctant to use it... I would
rather understand what is going on and address the underlying issue.

[quoted text, click to view]
Extreme Datasets
2/21/2005 7:35:02 PM
Hello Gary,

The ThreadAbortException is usually called by the clr when something that
cannot be handled is executed. The underlying problem is an unhandled error,
even if you may have the code in a Try, Catch block.

Maybe you could send me the code, environment specs, testing procedure and
perhaps a backup of the db so that i can attach to sql and simulate your
testing environment.

I find these issues intriguing and would like to assist in any way that i can.

thanks,
jeff
[quoted text, click to view]
Gary Joy
2/22/2005 2:09:03 AM
I have tried to reproduce the problem on three different machines (using the
same code and process) without success. Thanks for the offer but I can't send
you the code, I've tried creating a simple application to reproduce the
problem under the premise that maybe all SqlExecptions are being rethrown as
ThreadAbortExcpetions but that works fine on the troublesome mahcine.

What surprises me is that Visual Studio doesn't notice the
ThreadAbortExcpetion being thrown... it will stop when the original
SqlException is thrown but when the exception is caught it has "become" a
ThreadAbortException (without VS stopping again).

We are now working with MCS to resolve the issue. I will post the "solution"
here when we find it...

Gary Joy
3/1/2005 12:57:02 AM
I think that the behaviour you are describing applies to ASP .NET
applications only. I will try disabling the AV software anyway...

asdfasdf asdfasdf via DotNetMonster.com
3/1/2005 7:38:28 AM
Are you running any antivirus software on your machine? That could be the
culprit.

I have seen a similar problem on my iis processing a lengthy http request.
It took me a long time searching everywhere... but there's no solution to
be found for months. Then I stumbled upon and msdn article that was
somewhat related to my problem but not exactly.

As far as I know the ThreadAbortException happened when the AppDomain (ie:
your .net process) is reset and there are many reason why the AppDomain
could be reset (normally due to any files such as web.config machine.config
and changes to any aspx page or file changes/additions in the \bin
directory)... well i discovered the fix when i started monitoring the
"appdomain restart" performance counter and realized that my appdomain was
getting reset 20+ times a day even though we don't touch any of the .net
files for weeks)... as it turns out we had Symantec Antivirus running on
our server with "file system protection" turned on... this feature of the
antivirus... "touches" the files in the .net directories causing .NET to
reset during lengthy processes.... once i discovered this i just
completely unloaded the symantec antivirus and my length processes are
never reset or thread aborted again.

Be careful how you unload the antivirus... the 1st time i did it it
restarted itself again after 30 minutes (it's a feature of the antivirus)...

Here's the article in case you're interested... it didn't help me much the
1st time i read it. I just told me that antiviruses could be a culprit.

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q309337

michael

--
Gary Joy
3/15/2005 2:43:03 AM
Update - The behaviour described seems to be a result of attaching the Visual
Studio debugger. When running the same "test" using WinDbg the application
AddThis Social Bookmark Button