Scott Hanselman

ThreadAbortException woes

September 9, '05 Comments [7] Posted in ASP.NET | DasBlog | Bugs
Sponsored By

Hey readers, I'm starting to get this exception ALL the time on my site, and my ISP is starting to complain. It's also affecting uptime:

 System.Threading.ThreadAbortException: Thread was being aborted. at newtelligence.DasBlog.Web.Core.TemplateProcessor.ProcessTemplate(SharedBasePage page, Entry entry, String templateString, Control contentPlaceHolder, Macros macros) in C:\dev\DasBlog CE\source\newtelligence.DasBlog.Web.Core\TemplateProcessor.cs:line 118 at newtelligence.DasBlog.Web.Core.TemplateProcessor.ProcessTemplate(SharedBasePage page, String templateString, Control contentPlaceHolder, Macros macros) in C:\dev\DasBlog CE\source\newtelligence.DasBlog.Web.Core\TemplateProcessor.cs:line 61 at newtelligence.DasBlog.Web.Core.SharedBasePage.ProcessDayTemplate(DateTime day, Control ContentPlaceHolder) in C:\dev\DasBlog CE\source\newtelligence.DasBlog.Web.Core\SharedBasePage.cs:line 743 at newtelligence.DasBlog.Web.Core.Macros.get_Bodytext() in C:\dev\DasBlog CE\source\newtelligence.DasBlog.Web.Core\Macros.cs:line 1231 --- End of inner exception stack trace --- at System.Reflection.RuntimeMethodInfo.InternalInvoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean isBinderDefault, Assembly caller, Boolean verifyAccess) at System.Reflection.RuntimeMethodInfo.InternalInvoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean verifyAccess) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at System.Reflection.RuntimePropertyInfo.GetValue(Object obj, Object[] index) at newtelligence.DasBlog.Web.Core.TemplateProcessor.InvokeMacro(Object obj, String expression) in C:\dev\DasBlog CE\source\newtelligence.DasBlog.Web.Core\TemplateProcessor.cs:line 332 at newtelligence.DasBlog.Web.Core.TemplateProcessor.ProcessTemplate(SharedBasePage page, Entry entry, String templateString, Control contentPlaceHolder, Macros macros) in C:\dev\DasBlog CE\source\newtelligence.DasBlog.Web.Core\TemplateProcessor.cs:line 105
while processing .

I don't think it's dasBlog or the macro engine because:

A. Nothing has changed in this code in months
2. Most of what DasBlog does is in the Template Processor - like 90% - so if a thread were to abort, chances are it'd be happening in the code that runs 90% of the time.

That said, my ISP says that the site isn't recycling - they are basing this on the pid of w3wp.exe not changing. When ASP.NET "recycles" a site are they starting the AppDomain over or the whole process? I thought it was the process. Either way, you'd expect me to get another Application_Start event, and I'm not seeing that. I'm just seeing these Thread Aborts without app recycles.

Any ideas as I debug this?

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb
Saturday, 10 September 2005 03:29:28 UTC
Are there any Response.Redirects in that code? I know those cause ThreadAbortExceptions.
Saturday, 10 September 2005 03:50:36 UTC
I get the same error in one of my applications. It only happens at one client location. I cannot reproduce it, and the app uses the same framework that is in use in several other applications installed at many different clients without error. However, I do know that the ThreadAbortExceptions are occuring after a Response.Redirect(). I've got a base page that catches any otherwise unhandled exceptions using the Error event. So, I just threw a wrapper around my logging/e-mail notifications that looks like this:

Exception ex = Server.GetLastError().GetBaseException();
if ((ex is ThreadAbortException) == false)
{
// normal logging stuff
}

Hope this helps!
David
Saturday, 10 September 2005 04:56:49 UTC
Recycling bounces just the app domain. Does your code touch any files in your bin directory? If so, that can cause this problem. I had to learn this lesson the hard way, but that was clear back on 1.0, so things may be different now. Nevertheless, I still never touch anything in my bin dir from code.
Steve Johnson
Saturday, 10 September 2005 05:09:55 UTC
ASP.net calls Thread.Abort in Response.End (which is called from Response.Redirect), as well as if the page times out. Depending on the amount of traffic, and how long the pages are taking to render, there may be requests that are timing out. This might be especially true if bots are crawling the category pages (which are quite expensive as they are bounded only by category) while you're getting alot of other traffic. That might explain why you started getting it "all of a sudden". You may have crossed some threshold of historical entries that's aggravating the situation.

In both the Response.End and timeout cases, the inner exception is a HttpApplication.CancelModelException, which has a flag indicating if it was due to a timeout. So, you should be able to tell if it's one of those two scenarios.

Just some thoughts. I've had lots of fun with aborting threads in ASP.net.
Saturday, 10 September 2005 05:12:35 UTC
Hm...the timeout thing makes some sense...perhaps I've got a deadlock or overly aggressive locking?

0:000> !analyze -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************


FAULTING_IP:
+0
00000000 ?? ???

EXCEPTION_RECORD: ffffffff -- (.exr ffffffffffffffff)
ExceptionAddress: 00000000
ExceptionCode: 80000007 (Wake debugger)
ExceptionFlags: 00000000
NumberParameters: 0

BUGCHECK_STR: 80000007

DEFAULT_BUCKET_ID: APPLICATION_FAULT

PROCESS_NAME: w3wp.exe

ERROR_CODE: (NTSTATUS) 0x80000007 - {Kernel Debugger Awakened} the system debugger was awakened by an interrupt.

LAST_CONTROL_TRANSFER: from 77f43741 to 7ffe0304

STACK_TEXT:
0006fe58 77f43741 77e41817 00000160 00000000 SharedUserData!SystemCallStub+0x4
0006fe5c 77e41817 00000160 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc
0006fecc 77e4168f 00000160 ffffffff 00000000 kernel32!WaitForSingleObjectEx+0xac
0006fedc 5a3635ae 00000160 ffffffff 00000000 kernel32!WaitForSingleObject+0xf
0006feec 5a364d7d 00264e88 5a3a1d98 00000000 w3dt!WP_CONTEXT::RunMainThreadLoop+0xe
0006fef4 5a3a1d98 00000000 010013b4 5a3a5d54 w3dt!UlAtqStartListen+0x2d
0006ff00 5a3a5d54 010013ec 010013b4 010017af w3core!W3_SERVER::StartListen+0x8e
010012a0 72617453 00000074 6f727245 6f6c2072 w3core!UlW3Start+0xea
WARNING: Frame IP not in any known module. Following frames may be wrong.
010012b0 6e696461 33572067 72657320 65636976 0x72617453
010012b4 33572067 72657320 65636976 6c6c6420 0x6e696461
010012b8 72657320 65636976 6c6c6420 77252720 0x33572067
010012bc 65636976 6c6c6420 77252720 202e2773 0x72657320
010012c0 6c6c6420 77252720 202e2773 72724520 0x65636976
010012c4 77252720 202e2773 72724520 3d20726f 0x6c6c6420
01001314 6820202e 203d2072 000a7825 6f727245 ole32!CPropertyBagEx::Open+0x1d6
01001340 6820202e 203d2072 000a7825 6f727245 0x6820202e
01001344 203d2072 000a7825 6f727245 6e692072 0x6820202e
01001348 000a7825 6f727245 6e692072 496f4320 0x203d2072
0100134c 6f727245 6e692072 496f4320 6974696e 0xa7825
01001350 6e692072 496f4320 6974696e 7a696c61 0x6f727245
01001354 496f4320 6974696e 7a696c61 28784565 0x6e692072
01001358 6974696e 7a696c61 28784565 20202e29 0x496f4320
0100135c 7a696c61 28784565 20202e29 3d207268 0x6974696e
01001360 28784565 20202e29 3d207268 0a782520 0x7a696c61
01001364 20202e29 3d207268 0a782520 00000000 0x28784565
01001368 3d207268 0a782520 00000000 38415f5f 0x20202e29
0100136c 0a782520 00000000 38415f5f 31533944 0x3d207268
01001370 00000000 38415f5f 31533944 5f32345f 0xa782520


FOLLOWUP_IP:
w3dt!WP_CONTEXT::RunMainThreadLoop+e
5a3635ae 837e1400 cmp dword ptr [esi+0x14],0x0

SYMBOL_STACK_INDEX: 4

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: w3dt!WP_CONTEXT::RunMainThreadLoop+e

MODULE_NAME: w3dt

IMAGE_NAME: w3dt.dll

DEBUG_FLR_IMAGE_TIMESTAMP: 3e802556

STACK_COMMAND: .ecxr ; kb

FAILURE_BUCKET_ID: 80000007_w3dt!WP_CONTEXT::RunMainThreadLoop+e

BUCKET_ID: 80000007_w3dt!WP_CONTEXT::RunMainThreadLoop+e

Followup: MachineOwner
---------

Sunday, 11 September 2005 08:31:51 UTC
> A. Nothing has changed in this code in months

I agree with Mark: I think it's traffic related. Particularly if the code hasn't changed in a while and just magically started exhibiting this behavior.

IIS 6 cycles ASP.NET every 29 hours by default; could that be causing this, if the asp.net app happens to be in the middle of an operation at the time?

http://www.asp.net/faq/AspNetAndIIS6.aspx

"By default IIS 6.0 is configured to recycle its worker process every 29 hours. This is a bit aggressive for an application running ASP.NET and it is recommended that automatic worker process recycling is disabled. "

I *know* this caused some exceptions for us in load testing recently. Of course our server admin had inexplicably set this to 2 hours instead of the default 29..
Wednesday, 14 September 2005 19:42:11 UTC
While your debugging the latest dasBlog build I was wondering if any had seen this exception which seems to have appeared recently:

Error:
System.Web.HttpException: Invalid_Viewstate
Client IP: 212.55.246.172
Port: 57771
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
ViewState: "dDwtMTQzNDM3MTM3OTt0PDtsPGk8MD47PjtsPHQ8O2w8aTw5Pjs+O2w8dDw7bDxpPDE1PjtpPDMzPjtpPDc1Pjs+O2w8dDw7bDxpPDA+Oz47bDx0PHA8cDxsPGVudHJ5SWQ7PjtsPDUxYWMyNDZkLTliZDYtNDcwMy1iNzFhLTg5YTBkNWU2NWM1NDs+Pjs+O2w8aTwwPjs+O2w8dDw7bDxpPDM+O2k8NT47PjtsPHQ8cDxsPFZpc2libGU7PjtsPG88Zj47Pj47bDxpPDE+Oz47bDx0PHA8cDxsPFRleHQ7PjtsPENvbW1lbnRzIGFyZSBjbG9zZWQuOz4+Oz47Oz47Pj47dDw7bDxpPDA+O2k8MT47aTwyPjtpPDQ+O2k8NT47aTw2PjtpPDc+Oz47bDx0PDtsPGk8MD47PjtsPHQ8O2w8aTwwPjtpPDI+Oz47bDx0PHA8cDxsPFRleHQ7PjtsPE5hbWU7Pj47Pjs7Pjt0PHA8cDxsPEVycm9yTWVzc2FnZTs+O2w8WW91IG11c3QgZW50ZXIgeW91ciBuYW1lIC0gb3IgYXQgbGVhc3Qgc29tZSBuYW1lLjs+Pjs+Ozs+Oz4+Oz4+O3Q8O2w8aTwwPjs+O2w8dDw7bDxpPDA+O2k8Mj47PjtsPHQ8cDxwPGw8VGV4dDs+O2w8RS1tYWlsOz4+Oz47Oz47dDxwPHA8bDxFcnJvck1lc3NhZ2U7PjtsPFRoZSBlLW1haWwgYWRkcmVzcyBpcyBv
Http-Referer: http://www.ryanstevens.co.uk/CommentView,guid,51ac246d-9bd6-4703-b71a-89a0d5e65c54.aspx
Path: /CommentView.aspx. ---> System.FormatException: Invalid character in a Base-64 string.
at System.Convert.FromBase64String(String s)
at System.Web.UI.LosFormatter.Deserialize(String input)
at System.Web.UI.Page.LoadPageStateFromPersistenceMedium()
--- End of inner exception stack trace ---
at System.Web.UI.Page.LoadPageStateFromPersistenceMedium()
at System.Web.UI.Page.LoadPageViewState()
at System.Web.UI.Page.ProcessRequestMain()
while processing http://www.ryanstevens.co.uk/CommentView.aspx?guid=51ac246d-9bd6-4703-b71a-89a0d5e65c54.

It appears to happen on different pages but always complaining that the view state contains invalid characters.

Any ideas?
Ryan Stevens
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.