Hello, we are getting these exceptions nearly each day on some of our Portals. Below are the entries from our Log Viewer. We were having an issue with this causing the application pool to crash and our worker process would restart. This would cause all or our 4.x sites to have to reload in cache and would result in a major slowdown for a period of time. We are running a Windows 2003 Standard box if that helps as well.

We read the article after doing a lot of searching on this type of crash and created the UnhandledExceptionModule.dll file that Microsoft has suggested. Read the article Unhandled exceptions cause ASP.NET-based applications to unexpectedly quit in the .NET Framework 2.0 if you like.

After doing so we are able to see the error log in our Windows Event Viewer, but the worker process is still restarting. Seems like we are very close to figuring out what it could be, but not quite yet. If we turn of the scheduler we could probably eliminate the error, but we’d like to keep the schedules.

Any clue as to what could be causing this issue? We’ve researched quite a bit without finding a solid reason.

Log Viewer errors:

Last exception was of type Scheduler Event Failure

5^th  error:

THREAD ID: 8
TYPE: DotNetNuke.Services.Search.SearchEngineScheduler
EXCEPTION: Thread was being aborted.
RESCHEDULED FOR: 1/1/0001 1:00:00 AM
SOURCE: STARTED_FROM_BEGIN_REQUEST
ACTIVE THREADS: -1
FREE THREADS: 2
READER TIMEOUTS: 0
WRITER TIMEOUTS: 0
IN PROGRESS: 0
IN QUEUE: 2
Server Name: XXXX

All were listed as Scheduler Exception in the Log Viewer

4^th error

AssemblyVersion: -1
PortalID: -1
PortalName:
UserID: -1
UserName:
ActiveTabID: -1
ActiveTabName:
RawURL:
AbsoluteURL:
AbsoluteURLReferrer:
UserAgent:
DefaultDataProvider:
ExceptionGUID:
InnerException: Thread was being aborted.
FileName:
FileLineNumber: -1
FileColumnNumber: -1
Method:
StackTrace:
Message: System.Threading.ThreadAbortException: Thread was being aborted. at DotNetNuke.Services.Scheduling.DNNScheduling.Scheduler.CoreScheduler.WorkStarted(SchedulerClient& objSchedulerClient) at DotNetNuke.Services.Scheduling.SchedulerClient.Started() at DotNetNuke.Services.Scheduling.DNNScheduling.ProcessGroup.Run(ScheduleHistoryItem objScheduleHistoryItem)
Source:
Server Name: XXXX

3^rd error

AssemblyVersion: -1
PortalID: -1
PortalName:
UserID: -1
UserName:
ActiveTabID: -1
ActiveTabName:
RawURL:
AbsoluteURL:
AbsoluteURLReferrer:
UserAgent:
DefaultDataProvider:
ExceptionGUID:
InnerException: Thread was being aborted.
FileName:
FileLineNumber: -1
FileColumnNumber: -1
Method:
StackTrace:
Message: System.Threading.ThreadAbortException: Thread was being aborted. at DotNetNuke.Services.Scheduling.DNNScheduling.ProcessGroup.AddQueueUserWorkItem(ScheduleItem s) at DotNetNuke.Services.Scheduling.DNNScheduling.Scheduler.CoreScheduler.FireEvents(Boolean Asynchronous) at DotNetNuke.Services.Scheduling.DNNScheduling.Scheduler.CoreScheduler.Start()
Source:
Server Name: XXXX

2^nd error

AssemblyVersion: -1
PortalID: -1
PortalName:
UserID: -1
UserName:
ActiveTabID: -1
ActiveTabName:
RawURL:
AbsoluteURL:
AbsoluteURLReferrer:
UserAgent:
DefaultDataProvider:
ExceptionGUID:
InnerException: Thread was being aborted.
FileName:
FileLineNumber: -1
FileColumnNumber: -1
Method:
StackTrace:
Message: System.Threading.ThreadAbortException: Thread was being aborted. at System.Threading.ReaderWriterLock.AcquireWriterLockInternal(Int32 millisecondsTimeout) at DotNetNuke.Services.Scheduling.DNNScheduling.Scheduler.CoreScheduler.RemoveFromScheduleQueue(ScheduleItem objScheduleItem) at DotNetNuke.Services.Scheduling.DNNScheduling.Scheduler.CoreScheduler.WorkStarted(SchedulerClient& objSchedulerClient)
Source:
Server Name: XXXX

1^st error

AssemblyVersion: -1
PortalID: -1
PortalName:
UserID: -1
UserName:
ActiveTabID: -1
ActiveTabName:
RawURL:
AbsoluteURL:
AbsoluteURLReferrer:
UserAgent:
DefaultDataProvider:
ExceptionGUID:
InnerException: Thread was being aborted.
FileName:
FileLineNumber: -1
FileColumnNumber: -1
Method:
StackTrace:
Message: System.Threading.ThreadAbortException: Thread was being aborted. at System.Threading.Thread.SleepInternal(Int32 millisecondsTimeout) at DotNetNuke.Services.Scheduling.DNNScheduling.ProcessGroup.AddQueueUserWorkItem(ScheduleItem s)
Source:
Server Name: XXXX

Microsoft Event Viewer

Event Type:            Error
Event Source:           ASP.NET 2.0.50727.0
Event Category:       None
Event ID: 0
Date:                        2/27/2007
Time:                       11:36:12 PM
User:                        N/A
Computer:                XXXX
Description:
The description for Event ID ( 0 ) in Source ( ASP.NET 2.0.50727.0 ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event:

UnhandledException logged by UnhandledExceptionModule.dll:

appId=/LM/W3SVC/6953/ROOT

type=System.CannotUnloadAppDomainException

message=Error while unloading appdomain. (Exception from HRESULT: 0x80131015)

stack=
   at System.AppDomain.Unload(AppDomain domain)
   at System.Web.HttpRuntime.ReleaseResourcesAndUnloadAppDomain(Object state)
   at System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(Object state)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)

I realized I did not put the times on the Log Viewer Exceptions from the Portal but they started at  11:35:55 PM right before the UnhandledException in the MS Event Log.

This was the only thing I could see that led up to this event, and we have gotten these nearly every day. Right before we get this message in our MS Event Log we have one of our Portals with scheduler exception each time timestamped before it. We were running one module that we found would throw an UnhandledException and we have put the UnhandledExceptionModule.dll and that did help the worker process from recycling, but have not found any other smoking gun. We had put up the details on it here http://www.sheldonrcohen.com/Default.aspx?tabid=53&mid=368&ctl=ViewEntry&EntryID=69 as well.

So what else could be causing our worker process to recycle and how can we track it down I guess. Is it possible that the Scheduler could still be causing our worker process to recycle? If we were to turn off the schedules for a few days that might be the best way to say yes or no to this it sounds like.