albertocolom / elmah

Automatically exported from code.google.com/p/elmah
Apache License 2.0
0 stars 0 forks source link

WebServer crashes when mailbox not available #72

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?

if I use a smtpserver which is not availble in the <errormail> section
a exception raises on the webserver and Dr. Watson starts with 100% Cpu! 

here is the entry from the eventlog:

An unhandled exception occurred and the process was terminated.

Application ID: /LM/W3SVC/2083407965/Root/NachfolgeboerseWartung

Process ID: 2360

Exception: System.Net.Mail.SmtpFailedRecipientException

Message: Postfach nicht verfügbar. Die Serverantwort war: 5.1.1 
<office@madrian.at> relaying denied

StackTrace:    bei System.Net.Mail.SmtpTransport.SendMail(MailAddress 
sender, MailAddressCollection recipients, String deliveryNotify, 
SmtpFailedRecipientException& exception)
   bei System.Net.Mail.SmtpClient.Send(MailMessage message)
   bei Elmah.ErrorMailModule.SendMail(MailMessage mail)
   bei Elmah.ErrorMailModule.ReportError(Error error)
   bei Elmah.ErrorMailModule.ReportError(Object state)
   bei System.Threading._ThreadPoolWaitCallback.WaitCallback_Context
(Object state)
   bei System.Threading.ExecutionContext.runTryCode(Object userData)
   bei 
System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCle
anup(TryCode code, CleanupCode backoutCode, Object userData)
   bei System.Threading.ExecutionContext.RunInternal(ExecutionContext 
executionContext, ContextCallback callback, Object state)
   bei System.Threading.ExecutionContext.Run(ExecutionContext 
executionContext, ContextCallback callback, Object state)
   bei System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal
(_ThreadPoolWaitCallback tpWaitCallBack)
   bei System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object 
state)

Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie 

Original issue reported on code.google.com by off...@madrian.at on 30 Oct 2008 at 6:58

GoogleCodeExporter commented 8 years ago
If you set the async attribute to false on <errorMail> section then does 
WebServer 
still crash? I am assuming you're talking about the ASP.NET Development Web 
Server 
that ships with Visual Studio rather than IIS. Is that correct?

Original comment by azizatif on 31 Oct 2008 at 11:09

GoogleCodeExporter commented 8 years ago
I will try it with async=false but it is not on the develeopment server - it is 
also 
on the IIS 6 under Windows 2003

regards

Original comment by off...@madrian.at on 31 Oct 2008 at 12:36

GoogleCodeExporter commented 8 years ago
if async=false an exeption is rasied and an entry is in the eventlog but no 
Dr. Watson is starting (no crash)

robert

Original comment by off...@madrian.at on 5 Nov 2008 at 2:37

GoogleCodeExporter commented 8 years ago
Thanks for getting back on this. The crash happens because of a change in the 
default behavior for how unhandled exceptions are treated starting with .NET 
Framework 2.0. More specifically, unhandled exceptions that occur on a thread 
from 
the thread pool are no longer silently ignored but instead cause the 
application to 
terminate. That is probably what is happening in your case. By default, errors 
are 
mailed asynchronously by using a thread from the thread pool. The reason for 
this is 
to allow the request to terminate while the sending the mail happens in the 
background. If it takes time to send the mail then the request does not block. 
The 
failure to send mail however causes the application to terminate. Setting async 
to 
false for mails means that they are sent as part of the request processing and 
on 
the same thread. If an unhandled exception occurs then only the requst 
terminates in 
error and not the entire application. For ASP.NET, you can configure the CLR to 
behave like in .NET 1.x by adding the legacyUnhandledExceptionPolicy element 
and 
setting its enabled attribute to true. See the following articles and documents 
for 
more:

- Unhandled exceptions cause ASP.NET-based applications to unexpectedly quit in 
the .NET Framework 2.0
http://support.microsoft.com/kb/911816

- Exceptions in Managed Threads
http://msdn.microsoft.com/en-us/library/ms228965.aspx

Original comment by azizatif on 7 Nov 2008 at 11:39

GoogleCodeExporter commented 8 years ago

Original comment by azizatif on 7 Nov 2008 at 11:44

GoogleCodeExporter commented 8 years ago
Fixed in r463. Under .NET Framework 2.0, the SmtpException is now handled and 
traced 
instead (and only in the async case) so at least errors due to sending of mails 
does 
not cause the server to crash. Other (possibly critical) exceptions will still 
bubble up, however. You can pick up the change in the upcoming BETA 3.

Original comment by azizatif on 8 Nov 2008 at 12:13

GoogleCodeExporter commented 8 years ago
Fixed in r464 for .NET 1.x compilations.

Original comment by azizatif on 8 Nov 2008 at 12:18