Thread.Abort in ASP.NET app Ursachen w3wp.exe

Question

Bitte zum Absturz nicht gesetzt doppelte Flagge auf diesem qustion - es geht nicht darum, „warum Thread auftritt“, es geht darum, „warum w3wp.exe Prozess endet nach ThreadAbortException ".

Lassen Sie uns sagen, dass wir eine einfache Web-Anwendung mit folgenden Codebeispiel haben:

protected void Page_Load(object sender, EventArgs e) 
{ 
    Response.Redirect("http://google.com"); 
} 

, die durch Tatsache bedeutet, wie etwas (siehe Is Response.End() considered harmful?):

protected void Page_Load(object sender, EventArgs e) 
{ 
    ...response write some data... 
    System.Threading.Thread.CurrentThread.Abort(); 
} 

Auf meinem Rechner (Windows 10 Pro + IIS) Dieser Code führt zur Beendigung des IIS-Pool-Prozesses mit dem Fehlercode 0x0 (Umleitung führt nicht durch). Auf anderen Rechnern (die NICHT Windows 10 sind) erzeugt dieser Code nur eine ThreadAborted-Exception, aber der Prozess läuft weiter (Redirect führt aus).

Kann jemand dieses Beispiel überprüfen und erklären, was vor sich geht?

UPDATE Hier einige Windows-Ereignisprotokolle zu diesem Problem.

log # 1

Eine nicht behandelte Ausnahme aufgetreten ist, und der Prozess beendet wurde.

Anwendungs-ID:/LM/W3SVC/1/ROOT/AS

Prozess-ID: 6700

Ausnahme: System.Threading.ThreadAbortException

Nachricht: Thread wurde abgebrochen.

Stacktrace: bei System.Web.HttpRuntime.ProcessRequestNotificationPrivate (IIS7WorkerRequest wr, Httpcontext context) bei System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper (IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags) bei System.Web.Hosting.PipelineRuntime.ProcessRequestNotification (IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)

log # 2

Faulting application name: w3wp.exe, version: 10.0.10240.16384, time stamp: 0x559f3dad 
Faulting module name: KERNELBASE.dll, version: 10.0.10240.16384, time stamp: 0x559f3b2a 
Exception code: 0xe0434352 
Fault offset: 0x000b3e28 
Faulting process id: 0x1a2c 
Faulting application start time: 0x01d0e4b1b3ed01cb 
Faulting application path: C:\WINDOWS\SysWOW64\inetsrv\w3wp.exe 
Faulting module path: C:\WINDOWS\SYSTEM32\KERNELBASE.dll 
Report Id: 23b5298d-3b36-49c7-a294-de9c864b703f 
Faulting package full name: 
Faulting package-relative application ID: 

Answer 1

Bisher habe ich die nur eine Lösung:

static class WebExtensions 
    { 
     public static void EndSafe(this HttpResponse response) 
     { 
      response.Flush(); 
      response.SuppressContent = true; 
      HttpContext.Current.ApplicationInstance.CompleteRequest(); 
     } 

     public static void RedirectSafe(this HttpResponse response, string url) 
     { 
      response.Redirect(url, false); 
      HttpContext.Current.ApplicationInstance.CompleteRequest(); 
     } 
    } 

Dies zwingt mich jedoch dazu, sicherzustellen, dass hinterher kein Code ausgeführt wird:

...some code 
response.RedirectSafe(url); 
return; //<-- important 
...some more code 

beachten, dass nur „Rückkehr“ in einigen Fällen nicht ausreichend ist (zum Beispiel mit rekursiven Aufrufen) und in einigen Fällen können Sie vermeiden müssen „Rückkehr“ (mit Try-finally Konstruktionen) mit

Answer 2

Ich stieß heute genau auf dieses Problem unter Windows 8.1, nach dem Neustart, um Windows Updates zu installieren.

Das Problem war, dass ich RyuJIT in der Registry, due to this issue, manuell deaktiviert hatte, indem Sie das DWORD useLegacyJit hinzufügen und es auf 1 setzen (siehe Method #3). Aber eines der Updates hat den Schlüssel UseRyuJIT am selben Ort erstellt und ebenfalls auf 1 gesetzt, und das hat ASP.NET furchtbar verwirrt.

Die Lösung war useLegacyJit auf 0 setzen und eine iisreset ausgeben. Danach ist alles gut in der Welt.

WinDbg !clrstack zeigte die folgenden Frames, wenn ich den w3wp.exe Dump debuggte. Vielleicht wird dies anderes mit dem gleichen Fehler helfen, die nach einer Lösung Googeln:

000000ef9892be98 00007ffa0e2d1fea [HelperMethodFrame: 000000ef9892be98] 
000000ef9892bf80 00007ff99d776588 System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr, IntPtr, IntPtr, Int32) 
000000ef9892df90 00007ff9fc172345 [FaultingExceptionFrame: 000000ef9892df90] 
000000ef9892e490 00007ff99d7796c0 System.Web.HttpRuntime.ProcessRequestNotificationPrivate(System.Web.Hosting.IIS7WorkerRequest, System.Web.HttpContext) 
000000ef9892e520 00007ff99d777377 System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr, IntPtr, IntPtr, Int32) 
000000ef9892e700 00007ff99d77655a System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr, IntPtr, IntPtr, Int32) 
000000ef9892e740 00007ff99d775c11 DomainNeutralILStubClass.IL_STUB_ReversePInvoke(Int64, Int64, Int64, Int32) 
000000ef9892ef58 00007ff9fc100b4e [InlinedCallFrame: 000000ef9892ef58] System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr, System.Web.RequestNotificationStatus ByRef) 
000000ef9892ef58 00007ff99d78cc1b [InlinedCallFrame: 000000ef9892ef58] System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr, System.Web.RequestNotificationStatus ByRef) 
000000ef9892ef30 00007ff99d78cc1b DomainNeutralILStubClass.IL_STUB_PInvoke 
000000ef9892f000 00007ff99d77756c System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr, IntPtr, IntPtr, Int32) 
000000ef9892f1e0 00007ff99d77655a System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr, IntPtr, IntPtr, Int32) 
000000ef9892f220 00007ff99d775c11 DomainNeutralILStubClass.IL_STUB_ReversePInvoke(Int64, Int64, Int64, Int32) 
000000ef9892f418 00007ff9fc100da3 [ContextTransitionFrame: 000000ef9892f418] 

Answer 3

ich das gleiche Problem auf Win7 SP1 erlebt habe. Web-App kompiliert targeting .net 4.5.2 und läuft auf .net 4.6. Und ich habe nicht mit dem useLegacyJit oder usyRyuJIT Registry-Flags.

Es stellte sich heraus, dass "32-Bit-Anwendungen aktivieren" in meiner App-Domäne unnötigerweise auf Aktiviert gesetzt war. Durch Deaktivieren wurde das Problem behoben.

Answer 4

Ich konnte das Problem auf Server 2008r2 mit .NET 4.6 installiert reproduzieren.

Ich vermute, es war das gleiche Problem, in dem der Rest von Ihnen läuft; ThreadAbortExceptions löscht den Anwendungspool im Ereignisprotokoll (obwohl eine beliebige nicht behandelte Exception das Problem in meinem Fall verursachen würde; aber das könnte nur ein globaler Ausnahme-Handler sein, der es abfängt und mit Response.End oder Redirect beendet). Der Dump Stacktrace entspricht auch dem in Ians Antwort.

Es wurde ein MS Connect-Ticket für das Problem geöffnet, und ein aktueller KB-Hotfix behebt das Problem für mich.

Connect Artikel: https://connect.microsoft.com/VisualStudio/feedback/details/1605438/disabling-ryujit-breaks-asp-net

KB Hotfix: https://support.microsoft.com/en-us/kb/3098786